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-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. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

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