RE: [Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why Syste m Includes?

[Baptiste L. <gai...@fr...>]

Quoting "Summerwill, Bob" <BSu...@eu...>:

> >> I'd also like to tone this down a bit.  In fact, the difference
> >> between <header> and "header" is system-dependent
> >>   <http://www.eskimo.com/~scs/C-faq/q10.8.html>.  
> >> But it still seems to me that <cppunit/foo> is the correct choice
> in
> >> this case.  Other "3rd party" libs, like Qt and Gtk use <>-style
> includes.
> 
> Thanks for the reference.  I was about to ask if you could elaborate on
> the
> difference between the two types of #includes.  It had always been my
> understanding that <> tried the include paths, and that "" tried the
> same directory as the file doing the include, then did the standard
> search -
> but I (incorrectly) thought that this behaviour was guaranteed.
> 
> Out of interest, does anyone know which compilers don't implement this
> "normal" behaviour?  I know that GCC and MSVC++ are both "standard"
> in this respect.

  Actually the standard behavior ( quoted form search file in 'parent' file ) 
must be rather standard because RogueWave is using it in Thread++.

  That FAQ also omit another weird behavior of the quoted form (at least for 
VC++) that lead to no end of trouble when you are using "../". The quoted form 
search the parent file directory, but also the grand-parent file directory, ...

  For example:

  Content of file /1.cpp:
  #include "sub/2.h"

  Content of file /sub/2.h:
  #include "3.h"

  Content of file /3.h:
  <no more include>

  Compiling /1.cpp will succeed in spite of the fact that 3.h is not in the sub 
directory, because 3.h is in the directory of the grand-parent including file : 
1.cpp include sub/2.h which include 3.h (at least according to VC++ rules).

  This lead to the fact that the include might work in a given context and not 
in another one. That is why I said that "../" should not be used. You can 
easily forget one level of ".." and have it working because of the location of 
some including files.

  I think acceptable forms for CppUnit would be (I take 
cppunit/extensions/HelperMacros.h as an example again):

#include <cppunit/Portability.h>
#include <cppunit/extensions/AutoRegisterSuite.h>
#include <cppunit/extensions/TestSuiteBuilder.h>
#include <string>

-- or --  
#include <cppunit/Portability.h>
#include "AutoRegisterSuite.h"
#include "TestSuiteBuilder.h"
#include <string>

While the second form lead to file include filename resolution (the 
preprocessor look straight at the right place, that is the current directory), 
it is less safer than the first form (which is unambigous). The second form 
also implies that you have a stable include directory structure (it depends on 
the location of the current file), which is not our case.

So let's stick to what we are doing for now.

Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French