Boost logo

Boost :

Subject: Re: [boost] Mixed use of "include" directives with quoted vs. angle-bracketed params, causing havoc
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-09-07 12:11:33


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? What kind of control are you
looking for? Order of searched include paths?

> 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? Order of
include paths works just fine with their compilers for me since 2003
unless I am misunderstanding you. I frequently simply put a patched
directory of boost above my main boost install and it always picks up
the patched header files first.

Now, isn't there a slight performance and semantic difference that
should lead to using "" and not <>? Doesn't <> mean search compiler
dependent search path for file, then search user supplied paths in
order supplied, and "" means search user supplied path in order
supplied, then fall back to compiler dependent path?

If so, "" should clearly win.

--Michael Fawcett


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