cppunit-devel

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

[Summerwill, B. <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.


Cheers,
Bob

-----Original Message-----
From: Steve M. Robbins [mailto:ste...@vi...]
Sent: 28 September 2001 03:17
To: CppUnit Development
Subject: Re: [Cppunit-devel] Re: [cppunit - Open Discussion] RE: Why
System Includes?


On Thu, Sep 27, 2001 at 11:00:40AM -0400, Steve M. Robbins wrote:
> On Thu, Sep 27, 2001 at 07:43:57AM -0700, no...@so... wrote:

> > For the cpp file it is ok. #include <filename> states that include path
indicate
> > with /I option are search first, then those of the environment variable.
> 
> Careful -- you're getting into system-dependent behaviour here!
> I've never met a C compiler that used an environment variable to change
> the header include path!

I take this back.  GCC does pay attention to some environment variables.
On the other hand, I've never seen them in use.


> All the headers in include/cppunit *must* include the other headers
> using <cppunit/...> notation.

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.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants


_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

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