Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-06 10:45:59

"John Maddock" <john_at_[hidden]> writes:

>> This causes a problem for standards-compliant compilers because,
>> depending on where you enter the cycle, some template's declaration
>> will not be seen before it is used. For example, entering at
>> is_scalar.hpp (which happens when you include optional.hpp) causes the
>> definition of is_class<> to be seen before the declaration of
>> is_scalar<>, but the former uses the later.
>> The problem was introduced in the change from 1.32 to 1.33, when
>> is_abstract.hpp started being #included by is_convertible.hpp.
>> For reasons I still don't fully understand, this doesn't always
>> actually cause a problem. I think it has to do with the mysterious
>> BOOST_NO_IS_ABSTRACT macro; my understanding of the intricacies of
>> Boost configuration is very limited. The place I ran into this was
>> using an EDG-based front end to parse the preprocessed output of Sun
>> CC 5.7 on solaris-sparc; input is "#include <boost/optional.hpp>";
>> using Boost 1.33.0 or 1.33.1. I can't repro on linux or with gcc, nor
>> with the latest CVS version of Boost.
>> But regardless, the cycle is still present in the latest CVS, and
>> cyclic header dependencies are usually a bug.
> This has come up before: For any given specific compiler (the ones we know
> about and support in Boost.Config) the dependency graph is not cyclic, but
> is different from compiler to compiler.
> However, when using a front end about which we know nothing, it's possible
> to have a configuration setup that fools the code into doing the wrong
> thing. Anyway, I'll change the config so that not setting
> BOOST_NO_IS_ABSTRACT always takes a non-cyclic path.

I think it should be possible to arrange things so that even a naive
look at what-includes-what won't produce this sort of confusion, and
that would probably be worth it in the long run.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at