Boost logo

Boost :

Subject: Re: [boost] Mixed use of "include" directives with quoted vs. angle-bracketed params, causing havoc
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-09-06 23:13:04


David Abrahams wrote:
> on Sat Sep 06 2008, "Victor Vojtech Terber" <victor-AT-terber.de> wrote:
>
>> I have multiple Boost versions installed in different file locations. I
>> occasionally ran into problems with mixed-up Boost headers. This was due to
>> Boost's use of both quoted and bracketed syntax of the include directive to
>> include its headers.
>>
>> The standard allows for different results for resolving the include directive
>> depending on the chosen form. In particular the angle-bracketed form is narrower
>> than the quoted one (see chapters 16.2.2 and 3). So the point in the file system
>> from where the file will actually be included may legally differ, based on the
>> form of the include directive.
>>
>> I don't mind which alternative Boost uses. But in my opinion it should be
>> consistent inside Boost headers, shouldn't it? With some file system layouts it
>> gets very inconvenient to pre-determine by simple set-up of compiler or
>> environment variables which version will get used. I also fail to see any
>> obvious downside of a unification.
>
> Me neither, except that in very rare cases it could break some peoples'
> builds when they upgrade. The biggest obstacle, IIRC, was that we had a
> hard time coming to an agreement about which convention to use.
> However, I may have been the only one holding out for <> and since I
> realized that other libraries were using "" I never use <> anymore.

I was also holding out for <>. And recently become ardently in favor of
<>. For the simple reason that some compilers [0] have essentially zero
control of what the "" includes do. I ran into problems with a library
that uses "", but I needed to 'patch' some of the library files. Might
not sound like a big problem but since the library is one that gets
updated continuously I get it directly from their SVN repo. Which means
that the common way of patching, by literally changing the source code,
is problematic in that it introduces extra management steps. My
preferred approach is of course to add my patched includes at the front
of the include path. But that solution doesn't work since the files in
the lib get included first because of the fixed behavior of "" includes
(of including relative to the including file first).

[0] The compiler I'm referring to is msvc.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk