From dev-return-7847-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Fri Jun 13 08:04:21 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 36435 invoked from network); 13 Jun 2008 08:04:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jun 2008 08:04:21 -0000 Received: (qmail 53618 invoked by uid 500); 13 Jun 2008 08:04:23 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 53603 invoked by uid 500); 13 Jun 2008 08:04:23 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 53592 invoked by uid 99); 13 Jun 2008 08:04:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jun 2008 01:04:23 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates 72.14.220.159 as permitted sender) Received: from [72.14.220.159] (HELO fg-out-1718.google.com) (72.14.220.159) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jun 2008 08:03:33 +0000 Received: by fg-out-1718.google.com with SMTP id 16so2988996fgg.23 for ; Fri, 13 Jun 2008 01:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding:sender; bh=QWZ9Gjwm0Hnhdupic4SkRAhlpM0RBuTlnbi5XMIRcAI=; b=DDkan3bAnYeTVjResXtFq2ml2jvMD4UxwL80SZnr9cTTdqW/bHg+Tft63cFyT8MrRR 2xcEoK+sM3EcCEpkDXOAaVUH9IODViUiRFd9sHArNjFGiLYU65h4fWA51EX5r5iL8+CG S5B0ZYXz/PGmFzdDjFLe/M3sPoPuXP9mY9VmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:sender; b=NJXSBTBuDA4u39j5C+bzYu3a4L7Bv6ug/1spe/QC3PTVMWM6sYLStM67zKk6QK1hRb lcPJbntlsiB7hMD9Vz1aB/lmW4Cs9U2lwqUYq4I9HQ+NE4j2BS5IlqaD7mkqj0wtyKPZ ov144Z9/qQO1MIt+mifMt/dueonrb/5uKfPhk= Received: by 10.86.100.19 with SMTP id x19mr3547911fgb.34.1213344230003; Fri, 13 Jun 2008 01:03:50 -0700 (PDT) Received: from ?194.254.174.206? ( [194.254.174.206]) by mx.google.com with ESMTPS id 4sm4431753fgg.9.2008.06.13.01.03.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jun 2008 01:03:48 -0700 (PDT) Message-ID: <485229E3.1050107@roguewave.com> Date: Fri, 13 Jun 2008 01:03:47 -0700 From: Martin Sebor User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: remove_reference References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Martin Sebor X-Virus-Checked: Checked by ClamAV on apache.org 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 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 . > > 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 via , stdcxx does not. Similarly, while a number of other implementations expose the contents of (at least) when or 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