[Teem-users] Fwd: changes in gage

[Gordon K. <gk...@cs...>]

hi,

I'm going to have to make some changes in the way that gage refers to 
the quantities it can query in volumes, in order to support rendering 
of non-scalar fields.  But doing so will cause a more basic change.  
Tell me (soon) what you think I should do.

Right now, gage uses an unsigned int to represent the "query", the list 
of all things that may be measured in a volume.  In the query, there is 
one bit turned on per quantity of interest, formed like this:

   query = (1<<gageSclGradVec) | (1<<gageSclGradMag)

or:

   query = GAGE_SCL_GRADVEC_BIT | GAGE_SCL_GRADMAG_BIT

This has worked great, for all the same reasons that other APIs use 
bitflags.

Now, the problem is that some gageKinds, especially the tensor kind 
(tenGageKind) will have to answer more than 32 different queries, at 
which point I've run out of bits.

So how do you think should gage represent queries?  I could use 64-bit 
ints, but seems both a little two exotic, as well as being only a 
short-term solution (still a hard limit on the number of quantities).

What other object is easy to pass around as an argument to functions, 
doesn't require its own allocation/destruction functions, and also 
supports convenient construction of the query (as convenient as doing 
bit-wise or's)?  If I use a short, fixed-length array of uchars (length 
fixed at compile time), as basically a longer set of bitflags, how 
should I support setting and testing the bits?

Speak, teem users!

Gordon