Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C8D4EE.6FB09F49"
Subject: RE: <rw/_defs.h included last?
Date: Sun, 22 Jun 2008 23:03:12 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49465BCF@exchmail01.Blue.Roguewave.Com>
Thread-Topic: <rw/_defs.h included last?
Thread-Index: AcjUutA2fCZeBMYvRcSWqjIyd0EdtQALuxve
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3872@exchmail01.Blue.Roguewave.Com>
 <485ED79C.1080605@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

------_=_NextPart_001_01C8D4EE.6FB09F49
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Martin Sebor wrote:
>Eric Lemings wrote:
>> Consider the following:
>> =20
>> file $TOPDIR/include/memory:
>> ...
>>  30 #ifndef _RWSTD_MEMORY_INCLUDED
>>  31 #define _RWSTD_MEMORY_INCLUDED
>>  32
>>  33 #include <rw/_allocator.h>
>>  34 #include <rw/_autoptr.h>
>>  35 #include <rw/_iterbase.h>
>>  36 #include <rw/_pair.h>
>>  37 #include <rw/_rawiter.h>
>>  38 #include <rw/_specialized.h>
>>  39 #include <rw/_defs.h>
>>  40
>>  41 #endif   // _RWSTD_MEMORY_INCLUDED
>>=20
>> Any idea why <rw/_defs.h> is included last?  I've noticed this in a
>> couple other standard headers also.
>
>As opposed to being first, or in the middle? What would be the
>rationale?
>
>The (undocumented) style for #include directives in stdcxx goes
>something like this:
>
>In all library headers:
>
>1. standard headers (C++, including stdcxx own, C, or POSIX are
>    never included (there are a shrinking number of exceptions to
>    this rule)

So, as an example, if one of us needed to use =
std::integral_constant<T,V> in some header, the definition of that type =
would need to be moved to some private header and included from both =
places to avoid including <type_traits>. I can buy this as it fits with =
the unnecessary namespace polution problem that keeps coming up.

>
>2. include directives are in alphabetical order, with rw/_defs.h
>    being last (it still ends up getting included first, indirectly,
>    by the first header); the exception here is when a stdcxx config
>    macro needs to be tested before the first #include directive

Okay, and what is the rationale for including rw/_defs.h last? If it =
provides defines that are needed by the current file, why not just put =
it in the list in alphabetical order like the others?

>
>3. each #include directive in every standard header is guarded with
>    a preprocessor conditional testing the XXX_INCLUDED macro for
>    the corresponding header for compile-time efficiency
>

I'm assuming that you're talking about this kind of thing...

  #ifndef _RWSTD_RW_ALGOBASE_H_INCLUDED
  #  include <rw/_algobase.h>
  #endif   // _RWSTD_RW_ALGOBASE_H_INCLUDED

  #ifndef _RWSTD_RW_ITERBASE_H_INCLUDED
  #  include <rw/_iterbase.h>
  #endif   // _RWSTD_RW_ITERBASE_H_INCLUDED

I looked in a handful of standard headers and didn't see this model =
anywhere. I do see it in many of the private headers, but it is not =
being used consistently.

Do we have any evidence that shows this 'optimization' is actually =
improving compile times?

>In library sources:
>
>1. sets of C++, C, POSIX, and stdcxx-private headers are included
>    in separate blocks of their own, in alphabetical order within
>    each block
>2. C headers are included using the xxx.h form (as opposed to the
>    cxxx form) for better portability
>
>Martin


------_=_NextPart_001_01C8D4EE.6FB09F49--