This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Anonymous Namespaces
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Chris Lattner <sabre at nondot dot org>, gcc at gcc dot gnu dot org, Kevin Atkinson <kevina at gnu dot org>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: 11 Feb 2004 16:42:56 +0100
- Subject: Re: Anonymous Namespaces
- Organization: Integrable Solutions
- References: <Pine.LNX.4.44.0401311352500.4151-100000@nondot.org><m3llnn6fmi.fsf@uniton.integrable-solutions.net><orhdxxwsjl.fsf@livre.redhat.lsd.ic.unicamp.br>
Alexandre Oliva <aoliva@redhat.com> writes:
| I'm sorry to resurrect this thread, but I'm missing one bit here, and
| I could use some enlightenment.
|
| On Jan 31, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
|
| > Chris Lattner <sabre@nondot.org> writes:
|
| > | Yes, we use the GCC "3.4" parser, so if it does, we do. We also don't
| > | support export yet. Regardless, if export was implemented, and an entity
| > | was not involved with an exported template, it should still be marked as
| > | internal.
|
| > You can't have that information availabale at parsing time. You'd
| > need to postpone the tramsutation to link time. The reason is that,
| > the instantiation of exported template can trigger instantiation in
| > chains and those usually implies name lookup -- which will happen at
| > sort of "link time" when the different translation units are being
| > combined together.
|
| So, let's consider two alternatives about the name defined within an
| anonymous namespace: either it's a template, or it's a non-template.
I don't think the discrimination is based on being a template or non
template.
| Here's my reasoning. Please point out any flaws in it:
|
| - If it's not a template, then the reference to the symbol is either
| template-independent (so it's bound at parse time, and we can
| determine immediately that the name can't be marked as local to the
| translation unit), or it's referenced for being a template argument
| passed to the exported template (in which case we know it can't be
| used as an argument to the exported template in another translation
| unit, because you can't reference the name in another unit, so you
| can't get to that particular exported template instantiation, so the
| name can remain local to the translation unit as well)
I don't follow. Argument dependent name lookup may hit a
non-template, template-independent name at instantiation time.
Basically, export + argument dependent name lookup implies merged
contexts from different translation units. And because instantiation
happens after parsing, you don't have full information to make the
right decision. The example I gave in this thread illustrates the
point. The bottom line is that with export, a program is viewed as a
whole.
[...]
| Still, it seems to me that we *can* determine whether a symbol in an
| anonymous namespace might be referenced from other translation units,
| without having to look at any other translation units, or having to
| wait until link time. What am I missing?
Given -sufficient- information, we can determine but your analyzis
overlooks argument dependent name lookup.
-- Gaby