This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Anonymous Namespaces


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]