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