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

John Maddock wrote:

So that's +1 for <> from me too.

+1 from me as original poster also. A bit grepping suggests that the angle-bracketed form is used much more widely than the quoted one inside Boost. But there is a catch: In many places "include SOMEMACRO" is used, which often (mostly?) expands into quoted parameters. An example is macro "BOOST_PP_STRINGIZE" used with "include" at over a dozen locations inside MPL (this actually blew up my configuration in the first place). A nice example is also BOOST_COMPILER_CONFIG and friends. While in file boost\config\user.hpp its use is proposed with angle brackets, the actual defines in boost\config\select_compiler_config.hpp are quoted. As I'm new to the Boost devel process: Should I (or anyone else) enter a ticket, or doesn't that make sense before further discussion occurred?

John Maddock wrote:

if you use

#include <somename.hpp>

and "somename" happens to be a macro then it gets macro expanded

With what "compiler"? -- Genny

On Sat, Sep 6, 2008 at 11:13 PM, Rene Rivera <grafikrobot@gmail.com> 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

On Sun, Sep 7, 2008 at 12:37 PM, Victor V. Terber <victor@terber.de> wrote:

Michael Fawcett wrote:

...

Now, isn't there a slight performance and semantic difference? Semantic difference: With quotes you search an implementation defined path first, only then search the (also implementation-defined) paths you would have searched with angled bracket.

...

performance Not generally predictable, as it depends where the files are actually placed. But the maximum number of places to look at is guaranteed to be equal or less with angled brackets than with quotes.

I think that means for libraries it makes more sense to use angle brackets. Boost headers don't rely on any such thing as a "current directory", they require the boost path in the include search path, therefore, the semantics (and maybe performance?) favor angle brackets.

...

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? No, that is not guaranteed. It's wholly implementation-defined (according to the standard, paragraph 16.2.3). That may (or may not) involve e.g. concepts like "current directory", "any directories in the call graph" etc. As it says: "implementation-defined".

Thanks for the reference, I didn't have a copy handy at home (only at work). --Michael Fawcett

On Sun, Sep 7, 2008 at 1:42 PM, John Maddock <john@johnmaddock.co.uk> wrote:

No, while this is all implementation defined, on every compiler I've used <> will always search paths supplied with -I directives before system paths. One could argue that "" is less efficient because it *may* search paths relative to the current file before looking at -I paths. But frankly any argument on efficiency grounds is likely to be fallacious: all strictly IMO of course!

I agree with your opinion, thanks for the info! --Michael Fawcett

On Sun, Sep 7, 2008 at 2:21 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

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.

Ah, now I see the problem. I misunderstood.

You misunderstood. Specifying the search paths works. But removing the local including dir from the search path is impossible.

Indeed.

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.

So it sounds like libraries should prefer <>, and the only time "" should be used is in project specific headers (i.e. won't be reused). But then often times project specific code ends up being generalized into a library at a later date, at which point it should be <>, so shouldn't you just always use <> then? --Michael Fawcett