This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Anonymous Namespaces
On Feb 12, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
> | On Feb 11, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> |
> | > Alexandre Oliva <aoliva@redhat.com> writes:
> |
> | > | 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,
> |
> | How? I can only see it do so by means of typedefs, and this is the
> | case we'd catch by the transitive closure case I mentioned. Am I
> | still missing anything?
> Did you look at the example I gave?
Yes. Ok, so my use of `typedefs' wasn't entirely appropriate, since I
was considering template typename arguments as equivalent to
typedefs. If you consider them as such, you can still decide
precisely which versions of gunc() to export or not, even if n::func()
was exported, because the type arguments passed to n::func have to be
visible in order for an external entity to reference them.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer