incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: <rw/_defs.h included last?
Date Mon, 23 Jun 2008 05:03:12 GMT
Martin Sebor wrote:
>Eric Lemings wrote:
>> Consider the following:
>>  
>> 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
>> 
>> 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


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message