[MOAB-dev] iMesh and enum types

[Jed Brown]

On Wed 2009-03-04 22:52, Tim Tautges wrote:
> Because languages don't generally guarantee how many bytes an enum will  
> have.

That's correct and I hadn't thought about this because I use the same
compiler suite to build libraries and to build my code (many libraries
won't work correctly otherwise).  However, the C and C++ standards say
that an enum type must be large enough to hold all the enumeration
constants and cannot be larger than 'int' unless required (C99 does not
allow members larger than can fit in 'int', C++ says the enum must not
be larger than 'int' unless there are members that cannot fit in 'int').
This implies that a constant could be added at the end of each
enumeration, e.g.

  iBase_TYPE_INVALID = MAX_INT

to guarantee that the enum is not smaller than 'int', thus giving you
ABI compatibility between compiler suites.  I like this better because
it gives you some extra type checking, but it's not a big deal.

> Now, you being a smart guy, you'll point out that int doesn't  
> necessarily have a deterministic size either.  What these should really  
> be is long (if we wanted ultimate determinism, we'd use int_32 or  
> somesuch, but I think that would harm compatibility with fortran).

ABI compatibility only makes sense on the same architecture and all
compilers on a system should produce binaries where sizeof(int) is
consistent, not doing so would cause many more problems (like the
standard libraries being broken).  Since the header is identical, this
isn't an issue of ABI compatibility between implementations, just an
issue of compatibility between languages and compiler suites, for which
my assumption above applies.

Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20090305/d8ffc397/attachment.pgp>