[Tdg] compile time string length

[Alex Norman]

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