2013/8/22 Nicholas Nethercote <[email protected]>: > Hi, > > |jsid| is a struct in debug builds and an integral type in opt builds. > From jspubtd.h: > > /* > * In release builds, jsid is defined to be an integral type. This > * prevents many bugs from being caught at compile time. E.g.: > * > * jsid id = ... > * if (id) // error > * ... > * > * size_t n = id; // error > * > * To catch more errors, jsid is given a struct type in C++ debug builds. > * Struct assignment and (in C++) operator== allow correct code to be mostly > * oblivious to the change. This feature can be explicitly disabled in debug > * builds by defining JS_NO_JSVAL_JSID_STRUCT_TYPES. > */ > # if defined(DEBUG) && !defined(JS_NO_JSVAL_JSID_STRUCT_TYPES) > # define JS_USE_JSID_STRUCT_TYPES > # endif > > # ifdef JS_USE_JSID_STRUCT_TYPES > struct jsid > { > size_t asBits; > bool operator==(jsid rhs) const { return asBits == rhs.asBits; } > bool operator!=(jsid rhs) const { return asBits != rhs.asBits; } > }; > # define JSID_BITS(id) (id.asBits) > # else /* defined(JS_USE_JSID_STRUCT_TYPES) */ > typedef ptrdiff_t jsid; > # define JSID_BITS(id) (id) > # endif /* defined(JS_USE_JSID_STRUCT_TYPES) */ > > > I'm wondering if this whole game is even necessary. Could we use the > struct version in opt builds as well? The only reason I can think not > to is if some compilers do not optimize a struct containing a single > integer as well as they would a naked integer.
Perhaps in the old days it enabled C typechecking to find more errors? At any rate, we're definitely already screwed on compilers than don't properly optimized those kinds of structs. (See Value!) -- Regards, Benjamin _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
