From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 720 invoked by alias); 16 Nov 2009 03:34:31 -0000 Received: (qmail 704 invoked by uid 22791); 16 Nov 2009 03:34:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.150) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Nov 2009 03:33:37 +0000 Received: by ey-out-1920.google.com with SMTP id 4so1496336eyg.46 for ; Sun, 15 Nov 2009 19:33:35 -0800 (PST) Received: by 10.213.2.67 with SMTP id 3mr1622486ebi.77.1258342415405; Sun, 15 Nov 2009 19:33:35 -0800 (PST) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 5sm3784671eyf.6.2009.11.15.19.33.32 (version=SSLv3 cipher=RC4-MD5); Sun, 15 Nov 2009 19:33:33 -0800 (PST) Message-ID: <4B00CBB8.4070603@gmail.com> Date: Mon, 16 Nov 2009 03:37:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Danny Smith CC: Dave Korn , Benjamin Kosnik , libstdc++@gcc.gnu.org, GCC Patches , "Aaron W. LaFramboise (GCC)" , Kai Tietz Subject: Re: Libstdc++ as DLL on windows, alternative approach [was Re: cygwin patch review] References: <20091019092452.2e271791@mcgee.artheist.org> <4AFC8EC3.10502@gmail.com> <9c03c2dd0911151923p3eeb0d3fi54434c911ae8a6ce@mail.gmail.com> In-Reply-To: <9c03c2dd0911151923p3eeb0d3fi54434c911ae8a6ce@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00754.txt.bz2 Danny Smith wrote: > On Fri, Nov 13, 2009 at 11:40 AM, Dave Korn wrote: >> Benjamin Kosnik wrote: >>> From older mail thread: >> Likewise. I had to take some time away from this to do other stuff, but >> I've gotten back to it this week. >> >>> No. There is already visibility markup on libstdc++ headers for this. >>> You can just put the attribute visibility bits on namespace std, and be >>> done with it. >>> >>> Here, from include/bits/c++config.h: >>> >>> # define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X >>> _GLIBCXX_VISIBILITY_ATTR(default) > >> * libstdc++-v3/include/bits/c++config (_GLIBCXX_VISIBILITY_ATTR): On >> platforms that don't support visibility, allow them to declare a macro >> _GLIBCXX_PSEUDO_VISIBILITY that is applied in place of visibility. >> > > I like the idea but the name _GLIBCXX_PSEUDO_VISIBILITY is a bit > strange to me (and probably others with psuedo-dyslexia). > Why not _GLIBCXX_TARGET_VISIBILITY_ATTR or (more generically) > _GLIBCXX_TARGET_ACCESSIBILITY_ATTR that defaults to > _GLIBCXX_VISIBILITY_ATTR. Well, the rationale is "because it's not visibility, but it's something that stands in its place". So, I chose "pseudo"-visibility because it's not visibility but it's like visibility. I don't mind renaming it, but not to anything like TARGET_VISIBILITY please, because it just isn't visibility. It's not really even accessibility either, because after all those functions are just as 'accessible' at link time regardless of whether they were marked up as _dllimport or not at compiletime, it only changes whether they'll need to be auto-imported or not. What it really is is "An arbitrary tag of any kind at all, that can be applied to the namespaces in the C++ library, differently according to whether or not those namespaces are intended to be visible or not, but it doesn't actually necessarily have to do visibility stuff to those namespaces in practice, particularly on platforms that don't support visibility". Got a third suggestion? cheers, DaveK