Re: [boost] Review: Config system

From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-08-29 06:52:13

>On a different topic discussed here, unknown compiler versions
>should be assumed to be fully compliant.  If they aren't,
>people will complain here, and we will know thusly that a new
>version of some compiler has appeared and we can make appropriate
>corrections.

I think that's about 2:1 in favour of a more pessimistic approach so far
(assuming that future compiler versions have all the defects of the current
version).

> - I'd like the header file names for the compiler configuration
>better reflect the *compiler*.  In particular:

OK

> - For the platforms, the header file names should reflect the
>operating system.  In particular:

OK, but for some reason I found "macos" particularly hard to read. 
Whatever - this could just me me :-)

> - I'm missing a select_cpu_config.hpp (to switch between x86, SPARC,
>Alpha, whatever).  For example, Solaris runs on x86 and SPARC, and
>those two CPUs have different endianess (boost/limits.hpp likes to
>know).   Linux runs on a whole bunch of CPUs.   BSD also.

Sure, but we don't really have any cpu specific config options at present -
and I don't really see the need to add lots of empty files :-)

It's easy enough to add though if there is demand.

> - cstdint.hpp must be properly merged with the current cstdint.hpp,
>which has a "ULL" fix.

Yep, I'm asssuming that when the cvs branches get joined, cvs will take
care of that.

> - suffix.hpp:  Please remove BOOST_NMEMBER_TEMPLATES now, it's
>no longer referenced in the boost sources and it's in "will be
>removed soon" state since ages.

Yep.

> - suffix.hpp:  Please move EDG stuff to compiler/edg.hpp;
>individual compiler config files should include edg.hpp if
>they're EDG-based. (SGI, Alpha cxx, Comeau, Intel).

OK, I wasn't sure which compilers were EDG based, thanks for the list.

> - Is this same approach also applicable to Unix-like
>platforms, i.e. should they include a platform/unix.hpp?
>Then the Unix stuff in suffix.hpp could be removed.  Sounds
>more orthogonal to me.

That's probably not a bad idea - particularly as more POSIX feature tests
are likely to be added in future.

> - Could we merge intel_icl.hpp and intel_icc.hpp?  They're
>the same compiler on different platforms, effectively. 

Probably - lets try it and see if anything breaks I guess.

> - Regarding <stdint.h>:  Please read my detailed comments
>at the beginning of boost/stdint.h why I had serious trouble
>with Linux' <stdint.h>.

I'm still not sure that I completely understand the issue - does this code
work with non-gcc compilers on linux or not? What are the remaining issues
if any?  Your comments in stdint.h basically just say "don't use this
header", which is fair enough - it often conflicts with <inttypes.h> or
<sys/types.h> as well as a partial <stdint.h>, but what about cstdint.hpp -
shouldn't that work now (with BOOST_HAS_STDINT_H defined)?  The version I
have on Suse linux looks complete to me - what have I missed?

<other comments skipped>

Thanks, for looking through that, I appreciate the comments.

- John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/