From dev-return-8048-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Sat Jun 28 23:02:26 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 14108 invoked from network); 28 Jun 2008 23:02:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Jun 2008 23:02:25 -0000 Received: (qmail 7947 invoked by uid 500); 28 Jun 2008 23:02:27 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 7921 invoked by uid 500); 28 Jun 2008 23:02:27 -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 7910 invoked by uid 99); 28 Jun 2008 23:02:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jun 2008 16:02:27 -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 74.125.46.31 as permitted sender) Received: from [74.125.46.31] (HELO yw-out-2324.google.com) (74.125.46.31) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jun 2008 23:01:36 +0000 Received: by yw-out-2324.google.com with SMTP id 5so588460ywb.53 for ; Sat, 28 Jun 2008 16:01:55 -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 :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:sender; bh=kjcGh6cLM3DSk8wWUP4uUxJce3du8+vhkwPCuX/w/z0=; b=FoXR+o+OuL/ilJXBTOetv6QsiBcpda7KPuz5Gaw/WpPcJ94qkj1lgYyvjDjGIyucP4 s5OezYPoxFFXImUD3zQLWyz4l5fMj6I4BANUfDlc9qvqkAGiLRAteVYgKiBc5HjN6zlY 4I6DClDd+9T0EeXtO7yHZEnOJEOyLkKxB23/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding:sender; b=HaoMpvsEqInFeD+VhKKLVDFvHbgDR7QcIx35sSvaYRPdMz0wIgeKvW9G60XCBdW2gR UQVH5jEP3w/tB5BiTnxwUwm+qzNJX0fFiAqNt2EIaq1sPoVLvJTZFxvyU8Uh5S0y6quj c3EJ3Ka4qGJ0kDmIdsIoE+8nVY5KM3ocPfx3Q= Received: by 10.151.106.7 with SMTP id i7mr5157657ybm.176.1214694114394; Sat, 28 Jun 2008 16:01:54 -0700 (PDT) Received: from localhost.localdomain ( [71.229.200.170]) by mx.google.com with ESMTPS id x72sm4329357pyg.26.2008.06.28.16.01.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Jun 2008 16:01:53 -0700 (PDT) Message-ID: <4866C2DF.7060303@roguewave.com> Date: Sat, 28 Jun 2008 17:01:51 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: Empty member initializers References: <48510FE0.3090809@roguewave.com> 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: >> >>> Travis Vitek wrote: >>> >>>> Eric Lemings wrote: >>>> >>>> How about member templates? Are these unilaterally supported by all >>>> compilers now? >>>> >>> From below... >>> >>> _RWSTD_NO_INLINE_MEMBER_TEMPLATES /* not used at all */ >> Well there's an INLINE_MEMBER_TEMPLATES.cpp check and then there's a >> separate MEMBER_TEMPLATES.cpp check. I assume they check different >> things. :) > > Yes, I realize this. The former checks that inline member templates are > supported. The latter checks that member templates can be defined > outside the body of the class. > > AFAICT, inline member templates are used in library code without guards, > so you can safely assume support for 4.2.x and later. > > If you want anything further than that [i.e. member templates defined > outside the body of the class, member template overloads, ...], you have > to look to see what all of the supported compilers allow. If one or more > of the currently supported compilers defines _RWSTD_NO_MEMBER_TEMPLATES, > then you will likely have to work around the issue in any new code. If > none of them define it, then some decision will have to be made if it is > safe to assume support for other compilers or not. Starting with 4.3.0, I think we can safely assume full support for member templates and remove all workarounds involving the macros as well as the macros (and the config test) themselves. The only thing I'd double-check before doing this cleanup is string when using HP aCC 3 because of an extern template bug. I don't even think there is a compiler that we target with 4.2.x that doesn't support member templates in any form. IIRC, the last one that had trouble with member templates (their out-of-line definitions) was MSVC 6. Martin