Michael Fawcett wrote:
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?
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