[Tdg] compile time string length

[Alex Norman]

getters could easily be replaced by the enum via compiler optimization.
I still think that events should have a getEventType and getEventGroup.

the point in the enum is so that we can use it in a switch statement.. so I
guess in that case you wouldn't want to use a class method, you'd just want to
do something like

switch(e->getEventType){
	case mint::Midi::NoteOn::eventType:
	...
}

you can use whatever you want to hash, the whole point in having a registration
process was to take a descriptive, human readable string and turn it into an id
for more efficient lookup.

even if variable is static and const, it has to be set to a specific value at
compile time to be used in a switch statement.. so we cannot do
static const int A::eventID = hash("test")
switch(blah){
	case A::eventID:
}

-Alex

On  0, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
> I tend to agree about moc'ing, i'm not in favor of it.
> 
> But this goes back to the question, what is the return type on the base 
> class Event::GetEventType () function? As I understand it you are 
> proposing there is no Event::GetEventType function, right.. That each 
> group has its own seperate enum space and we provide a function that 
> hashes the group and enum type for a derived event class. If you're 
> still thinking of an enum GetEventType function in the base Event class, 
> I don't see how this could work. Also, doesn't having a getter fuction 
> defeat the point of having static enums - efficieny. The getter hash 
> function would need to be called on every event on every callback to 
> hash a string with an enum.
> 
> Isn't there a way to hash the value with templates if you use a static 
> const char*, rather than std::string?
> 
> template < const char* C >
> struct Hash {
>    static const int value = (int) (C[0] + C[1] + C[2] + C[3]);  // 
> something like this, i think (maybe recursive template)
> }
> template < const char* C, int N >
> struct Hash {
>    static const int value = (Hash < C >::value << 3) + N;
> }
> 
> class MouseDownEvent {
>    static const int eventID = Hash < "mouse", (int) MouseDownEnum 
> >::value;  
> }
> 
> Or we just say, event groups names must be at least 4 chars.
> 
> R
> 
> Alex Norman wrote:
> 
> >honestly, I think we're getting ahead of ourselves.  I think we should 
> >simply
> >use strings for groups and enums for event types, use getters to grab the 
> >data,
> >and pass the whole event to hashing functions so that we can easily change 
> >our
> >approach later if it becomes an issue.  We should also have class/static 
> >getters
> >or at least const, public variables for this data so that we can do 
> >comparisons
> >without actually caring what the actual representation is.
> >I'm with you on the separate preprocessor thing (ie moc), I don't like 
> >that.
> >Having another application generate a header file to create compile time 
> >ids
> >seems like it is getting ahead of ourselves, it, while simpler than the 
> >separate
> >preproc, is still lame.
> >
> >-Alex
> >
> >On  0, Wesley Smith <wesley.hoke at gmail.com> wrote:
> > 
> >
> >>Ok,
> >>Here's what I currently think about this.  I don't think the C++
> >>preprocessor can look at individual characters of a string at all.
> >>Strings aren't inherent types in C++ because they're arrays and
> >>std::string is an object.  I haven't been able to locate the technical
> >>documentation on this, but I have a pretty good hunch that this means
> >>the preprocessor won't touch 'em.  So, it's time to re-evaluate.
> >>
> >>Some properties we seem to have agreed upon w/r/t enums and strings:
> >>
> >>1) We want calculations that generate the enums-string pairs to be 
> >>compile time
> >>2) We wan't to avoid being arbitrary
> >>3) We want to avoid typing alot when there is a pattern that should
> >>clearly be handled by the compiler somehow
> >>4) We don't want this to be overly complex
> >>
> >>Given the requirements above, I don't think we can meet all of them.
> >>I think we can only meet 3, so we need to weigh the tradeoffs of what
> >>we can do
> >>
> >>A) Arbitrarily partition the integers according to
> >>subsytem/group/event.  This option is straightforward but error prone
> >>and not very extensible.  The biggest problems with this system will
> >>be user created events and how they get assigned a numeric value
> >>
> >>B) Have some kind of preprocessor that runs over the code before
> >>compilation like QT.  I personally don't like this option as it adds
> >>an extra step every single time you reompile and generates alot of
> >>extra files and just feels very messy and awkward.  I would rather try
> >>and find a solution within the confines of C++.
> >>
> >>C) Name events this way: unsigned long long ll ='abcdefgh'; with 64
> >>bits per subsystem per group and per event.  This will restrict names
> >>to a fixed size which might be awkward though and generating the
> >>string will require compile-time bit munging.
> >>
> >>D) Have a separate, tiny application that does the run-time
> >>enum-string hashing and generates a header file for compiling with the
> >>rest of the app.  This seems like a pretty good compromise to me since
> >>everything will be automatic and you only have to recompile when a new
> >>event is added.  For core mint events, we could have a fixed file that
> >>is generated and distributed with a particular version of the library
> >>and for the user and for user events, they would add to their own
> >>"userEventEnum.h"  When they add an event they would just recompile
> >>EventGenerate which would take the list of event stirngs and build a
> >>header file with a table of enums and strings.
> >>
> >>what do ya'll think?
> >>
> >>wes
> >>_______________________________________________
> >>Tdg mailing list
> >>Tdg at mat.ucsb.edu
> >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> >>   
> >>
> >_______________________________________________
> >Tdg mailing list
> >Tdg at mat.ucsb.edu
> >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> > 
> >
> 
> _______________________________________________
> Tdg mailing list
> Tdg at mat.ucsb.edu
> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg