Sean Farrow wrote:

Hi: What advanced features of c++ does boost use, I'm thinking features that can cause problems with different c++ compilers.

By experience, *anything* may cause a problem with some compiler. Note, too, that much of what was "advanced", say, 5 years ago, may not be so now. And Boost is a large code base. Probably everything except non-trivial exception specifications (and export?) is used somewhere.

I'm evaluating the boost trunk with codegear c++ 2009, and would like to know what to look out for! What is the best compiler for standard complience on win32?

Comeau, on whatever platform. In an ideal world, that should extend to any compiler having the EDG front-end, except that, in the world we have, many vendors (see e.g. Intel) manage to screw it up in the most creative ways (perhaps they shouldn't be given access to the front-end source code :-)) About Codegear, what I'd like to verify isn't if it's up to the most esoteric constructs (something which keeps me far away from Boost more often than I'd like) but to what extent it is *usable in the real world*. To give an example: back in days of VC++6, one could take the following: template< typename T, std::size_t n > std::size_t count( T (&)[ n ] ) { return n ; } VC++6 wasn't even able to parse it; Borland C++ had no problems with it. Given that this is something pretty trivial, one couldn't conclude that VC++ was a shame, and that Borland C++ was at least worth further examination. However, Borland had some bugs (such as deducing template types as const-qualified) which made it pretty much unusable, and it had an incredible tendency to break after minor, innocent code changes. VC++6, OTOH, supported a much smaller fraction of the language, so that you had often to write more workarounds than "real code", but once the code was in place it didn't have that tendency to break at each and every change. This fact, a bit paradoxically, made it in practice much more usable than the --more conforming, on paper-- Borland C++. -- Genny