Date: 2001-07-13 17:46:28
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> > > Many compilers have options which control the #include policy. I
> > think it is
> > > possible to find a common #include policy subset which is
> > by all
> > > or nearly all compilers.
> > I don't think this is true. The "parent directory" policy
> > here is a classic example. Some compilers base it off the source
> > files directory and some base it off the file that does the
> > #include. These policies are not compatible, and I know of no
> > compiler that lets you tweak this behavior in any way.
> CodeWarrior is one example.
> > Yes, I understand the theoretical fragility. My point is that in
> > practice you never have problems with this. The "..." form is
> > reserved for files in the same directory
> In that case #include "boost/iterator_adaptors.hpp" would be
If I were "playing nice with a specific compilers semantics" then
yes. I guess I see your point, though. It's theoretically possible
that by not following these precise rules the Boost headers may cause
ODR violations unintentionally.
> > while the <...> is used for
> > all other files, and the physical directory lay out shall thus
> > prevent any theoretical fragility.
> Ignoring the relative #include issue above for a moment, couldn't
> rely on a combination of the in-practice directory layout
> the in-practice compiler #include policies? If not, how do
people /begin/ to
> write portable C++?
When it comes to this specific issue, I have no idea ;). It really
seems that we'll be damned no matter which we decide to use.
Frankly, I don't understand why there's two forms of include to begin
with, but if there must be why they aren't more precisely defined.
As it is it seems like the only portable means of doing #includes is
to use a macro to fix the style at compile time. Of course this
leaves you with the problem of how you manage to define the macro,
which can just lead to a circular problem.
> I think I have done it in the past by getting lucky ;-)
*laughs* Yes, I'd agree.
> > > Hmm. I guess I'm saying that portability to a theoretical
> > > standard-conforming compiler is impossible, so it pays to look
> > what
> > > compilers actually do and try to do something that they can all
> > support.
> > You can't look at all compilers, unfortunately. However, the
> > gave should be more portable then anything else, even with our
> > set of compilers supported by Boost. In other words, the rules I
> > gave will work with all the supported compilers, will probably
> > with any other compilers (excepting the relative path includes),
> > will work nicer with the policies of more build tools when it
> > to determining dependencies.
> Okay; I will assume you've done a quick survey and accept your
> about portability and supported compilers without question.
I didn't do a survey, but the standard strictly states that the "..."
form will behave as the <...> form if it fails to find the header
with the alternate policy. So the "..." form should simply always
work, making the rules I laid out about as portable as you can get
(excepting your point about relative includes and possible ODR
violations from various "parent" rules).
> It seems to me
> that the last point (other build tools) is the only one that has a
> bearing on "..." vs. <...>, though. Am I correct? If so, I would
> focus the discussion on that, since other people have made strong
> in the other direction. We need a good clear list of the pros and
I'm only familiar with one build tool for which this applies, so I
can't volunteer to define pros and cons. I also guess that so long
as Boost.Build works with the <...> form currently used by Boost that
given the other arguments this may be "good enough" since we simply
can't have a portable solution. :( I don't think anyone's had real
problems with it in practice, so worrying about the theory may be
unwarranted iif we can't resolve all theoretical portability problems
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk