Re: [boost] Mixed use of "include" directives with quoted vs. angle-bracketed params, causing havoc

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