From dev-return-7851-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Fri Jun 13 09:50:15 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 94046 invoked from network); 13 Jun 2008 09:50:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jun 2008 09:50:14 -0000 Received: (qmail 76233 invoked by uid 500); 13 Jun 2008 09:50:17 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 76213 invoked by uid 500); 13 Jun 2008 09:50:17 -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 76200 invoked by uid 99); 13 Jun 2008 09:50:17 -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 02:50:17 -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 09:49:25 +0000 Received: by fg-out-1718.google.com with SMTP id 16so3010035fgg.23 for ; Fri, 13 Jun 2008 02:49:41 -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=MZJN53lMYB60uoRfQJPLtan+TXDZzHuWQd3zS63zw/o=; b=QniBXas72il8JEyORdNw9Hcqhk1IqWK6iB7su2psrmJJxcUVV05XX+So/0MjquWKq2 pX3J+QPMQBIZmIV/L5uHMW5yP5peJZUht92kFcpoI3MmMHqUqsVD8lPnLJUKAfnY28P+ z+9oHIbm3GQ9qw3Bo/EP3e0LTUvG++/zDPsck= 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=SGTcTOKD2Vd/kMdtszIQvnpGh42eSEGYZY5zedGYJ0IvKSTuvddVvBjM79S+C0AsXD 4Kmgshk0/ycP02bt+58Y4QEQ4lszO20Qb2vaTSY8jksBhsJMTMAp5YF2ty4eRQPPeHj/ 3f1VlqH8wYU+aumr+ThkbpQrTdnssUygpP6Ws= Received: by 10.86.60.14 with SMTP id i14mr3631921fga.75.1213350581822; Fri, 13 Jun 2008 02:49:41 -0700 (PDT) Received: from ?194.254.174.206? ( [194.254.174.206]) by mx.google.com with ESMTPS id e20sm5150028fga.1.2008.06.13.02.49.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Jun 2008 02:49:40 -0700 (PDT) Message-ID: <485242B1.7090102@roguewave.com> Date: Fri, 13 Jun 2008 02:49:37 -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: <485229E3.1050107@roguewave.com> <7BDB2168BEAEF14C98F1901FD2DE6438026E9796@epmsa009.minsk.epam.com> In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE6438026E9796@epmsa009.minsk.epam.com> 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 Farid Zaripov wrote: >> -----Original Message----- >> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor >> Sent: Friday, June 13, 2008 11:04 AM >> To: dev@stdcxx.apache.org >> Subject: Re: remove_reference >> >> 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. > > This things are good in most cases, except one: the most > implementations > expose the contents of via , but stdcxx doesn't. So the > users > have to #include manually along with programmers > assumes, that #include should be enough. In the result there > are > number or errors like "hex is not a member of std", for example when > testing > boost with stdcxx. Most of this errors are fixed in boost after I > creating the issue > ticket, but they are appearing in new code! The last one in file, added > to the svn > by 4 march 2008: http://svn.boost.org/trac/boost/ticket/2004. Yes, this has been a common source of errors despite the standard being quite clear on which header these manipulators are declared in. There are also users who expect them to be declared in and/or . I am sympathetic to the first use case but less so to the second. IMO, the right way to solve the problem is to open an issue against the standard to require that the manipulators be declared also in . Martin