incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: remove_reference
Date Fri, 13 Jun 2008 08:03:47 GMT
Travis Vitek wrote:
>  
> 
> Eric Lemings wrote:
>> Hmm.  So what's the benefit in providing internal type traits
>> at all?  Seems to me that they only serve to slow down compile
>> times.  Why not just break the public type traits into internal
>> headers and include them all from the <type_traits> header?
>> Or do we have some plans for the internal type traits that I'm
>> unaware of?
>>
> 
> It is my understanding that the internal traits exist to avoid namespace
> pollution. Say we wanted to optimize std::uninitialized_fill<> for pod
> types. If we used std::is_pod<>, then the user would be able to use that
> type and possibly others without including <type_traits>.
> 
> Honestly, I don't see this as a great benefit, but it is something that
> has been important to the implementation in the past.

Namespace pollution causes portability problems because of
the underspecified contents of standard library headers.
stdcxx goes to great lengths to avoid introducing symbols
into the std namespace unless required by the standard. For
example, while most other implementations expose the contents
of <cstdio> via <iostream>, stdcxx does not. Similarly, while
a number of other implementations expose the contents of (at
least) <ios> when <complex> or <string> are #included, stdcxx
goes to a lot of trouble to avoid it. The benefit in this
in this is that software that uses stdcxx is more likely to
be readily portable to other implementations of other C++
standard library than would otherwise be the case.

> 
> As for the argument of slowing down compile times, there has been some
> bickering about this in the past; should we put comments in the headers
> or should we be splitting up large headers into multiple small ones and
> should we coalesce multiple headers into one. I don't buy it unless
> someone has a reasonable testcase as evidence. 

There is no doubt (and plenty of evidence exists) that template
metaprogramming puts much more stress on today's compilers that
the ordinary kind, and whole books have been written about the
costs of unrestrained header inclusion (e.g., Large Scale C++
Software Design by John Lakos). Compiler features such as
#pragma once have been implemented to deal with the header
problem. If we you believe these problems have been solved
I'd like to see evidence to that effect :)

Martin

Mime
View raw message