On Tue, Jun 9, 2009 at 9:57 PM, John Phillips<phillips@mps.ohio-state.edu> wrote:
Zachary Turner wrote:
I agree that it would need to be automated. But the script itself should be very trivial, I'd be willing to try it myself. And perhaps the best approach is what I mentioned in a previous post, to force the programmer to explicitly define BOOST_USE_PRAGMA_ONCE before including a boost header file. This would solve the problem of having to modify every header when new compilers were released. And since by default it would be undefined, an out-of-the-box boost installation would work exactly as it does now. I'll work on this a bit later today perhaps, and try to post some benchmarks for for compiling boost itself, and for compiling a commercial product which uses boost. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have a dim memory that there used to be some libraries that did not have include guards, and would fail without them because of recursive use of headers. Is that still true, or am I hallucinating about it?
Pretty much anything that uses Boost.Preprocessor with file iteration. And of course, Boost.Preprocessor itself. Also, IIRC, some libraries do not use boost.preprocessor directly, but implement some crude form of file iteration directly (which will also break). HTH, -- gpd