[Tdg] compile time string length

[Rama Hoetzlein]

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
>  
>