|
|
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-07 14:21:34
Michael Fawcett wrote:
> On Sat, Sep 6, 2008 at 11:13 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
>> 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 "",
>
> What exactly do you mean zero control?
You can't change the in any way the implementation defined aspect of
("") includes that differs from the (<>) includes. For example some
compilers let you specify to treat ("") the same as (<>). Or to specify
the ("") searched path independent of the (<>) searched paths.
> What kind of control are you looking for? Order of searched include paths?
In the case of my use case I needed a way to remove "searching relative
to the including file directory" aspect of ("") includes. This is
because the library includes headers as (include "a.h") which *never*
gets around to searching extra include paths I specify because it always
finds the one in the including dir first.
>> 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.
>
> I think I understand what you are describing, which version?
All of them. Or rather msvc6, msvc7, msvc8, and msvc9. Although I've
used msvc1 long ago, I don't remember if it had the same "limitation" ;-)
> Order of
> include paths works just fine with their compilers for me since 2003
> unless I am misunderstanding you.
You misunderstood. Specifying the search paths works. But removing the
local including dir from the search path is impossible.
> I frequently simply put a patched
> directory of boost above my main boost install and it always picks up
> the patched header files first.
That would be because AFAIK all Boost headers start with "boost/..." and
don't reference local includes. But moving to preferring ("") will
likely encourage library authors to rely on what is essentially
non-portable compiler behavior. The use of (<>) includes is technically
also non-portable but is currently universally portable or can be made
that way.
-- -- 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