Re: Typed constants

Ian Osgood wrote:
> It also occurs to me that we could use another method for defining
> constants.  Many of the protocol struct-wrapped parameters can take
> "special" values. For example, most places an XCBTIMESTAMP is required,
> people will want to use CurrentTime.  Currently this requires an enum
> containing CurrentTime and a local definition;
> 
>   XCBTIMESTAMP now = { XCBCurrentTime };
> 
> to be type-correct. It would be nicer if we could export this kind of
> constant from the library directly. This would be a proto construct like:
> 
>   <const name="CurrentTime" type="TIMESTAMP"><value>0</value></const>
> 
> expanding in header mode to:
> 
>   extern const XCBTIMESTAMP XCBCurrentTime;
> 
> and in source mode to:
> 
>   const XCBTIMESTAMP XCBCurrentTime = { 0 };
> 
> Would this be hard to do? Does this have a downside I'm missing?

This seems like a good idea to me.  However, #define does have the
advantage of inlining the constant values, which "extern const"
references won't do.  Furthermore, these constants will increase the
disk and memory size of libXCB, even for those constants a given program
doesn't use.  Type safety seems like a win, but our current approaches
to type safety don't cost us any speed.

How about defining the constants as "static const" in the header file
instead?  The compiler can throw away unreferenced static const values
because no external references can exist that it doesn't know about.
This will avoid adding all the constants to the size of libXCB, and make
programs using these constants bigger by only the size of the constants
they use (albeit potentially repeated, but inlining constants seems like
a feature), and permit inlining.

For that matter, as Yet Another thing we could do if the XSLT calculated
the size of data structures, we could have a heuristic threshold for
when we use "static const" and when we use "extern const".  However, if
we ever changed this heuristic and stopped providing any external const
values we previously provided, we'd break the ABI; thus, this seems like
a fragile solution, and we should really just pick one of the two and go
with it.

- Josh Triplett

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xcb mailing list
Xcb-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@xxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xcb