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)
Message-ID: <485FA971.4040905@roguewave.com>
Date: Mon, 23 Jun 2008 07:47:29 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: <rw/_defs.h included last?
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3872@exchmail01.Blue.Roguewave.Com>
 <485ED79C.1080605@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49465BCF@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49465BCF@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Travis Vitek wrote:
> Martin Sebor wrote:
[...]
>> 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.

Right. Although it should be balanced against the cost of
#including a whole header for just a single definition.
That's why we have headers such as <rw/_algobase.h> or
<rw/_iterbase.h>: to group the most commonly needed sets
of definitions and not a separate header for each of the
definitions in these headers.

> 
>> 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?

It used to be first. IIRC, the idea behind including it last
was to make it more likely for things to break if the #include
directive was missing. I'm not sure how well well thought out
it was. If it's causing trouble and going back to how it used
to be way back when makes more sense (i.e., eliminates the
exceptional case) I have no problem with it.

> 
>> 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.

I thought I had implemented it this way but it looks like
I misremembered.

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

I haven't done any benchmarking with stdcxx but what's in
stdcxx now was done based on a user request:
   http://issues.apache.org/jira/browse/STDCXX-213

Other than that, as I already said in another thread, there
is plenty of evidence out there that #include directives can
have a dramatic impact on compile times. That's why many
modern compilers provide this optimization either via special
purpose mechanisms like #pragma once or even automatically.

> 
>> 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
>