This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Anonymous Namespaces
On Feb 13, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
> | Yes. Ok, so my use of `typedefs' wasn't entirely appropriate, since I
> | was considering template typename arguments as equivalent to
> | typedefs.
> Yes. That view won't work because argument dependent name lookup does
> not consider "associated namespaces/classes of typedefs". And even if
> it did, it will just contribute more scopes to explore (not remove any).
> | 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.
> I don't understand what you call "visible" in this case.
By visible I meant a publicly-visible symbol, as opposed to a symbol
whose name isn't accessible to other object files at link time. Note
that I'm not talking of C++ concepts here, but of the mapping onto
object file concepts.
I apologize for having used a term that has a meaning in C++. I tried
to avoid such terms, but this one slipped in.
> At instantiation time, you typecheck constructs in the template body
> (which usually will be in a different translation than the one that
> requested the instantiation). Such template can (and will) contain
> function call that weren't resolved at the template definition time.
Ah, yes, function calls aren't subject to parse-time binding. Ok, I
see I have to revise my initial reasoning.
Function names are subject not only to regular name lookup rules, but
also to Koenig lookup, which significantly extends the amount of
``damage'' an unknown template argument can impose on our ability to
decide whether a name in an anonymous namespace can be implemented as
a symbol that is not, erhm, .global (visible, accessible, terms
related with linkage are all taken by the language definition, GRRR!
:-)
So, if we have a function call whose arguments are template dependent,
we may have to make .global *all* functions in anonymous namespaces
that might be viable candidates for such calls.
But, AFAICT, this scenario only occurs when exported templates are
used, no?
> (just like for ordinary functions) then you could make those decisions
> without having to know what may happen latter. As currently defined,
> (exported) template instantiations still depend on the context of
> instantiation which makes "early" decisions very premature/wrong.
Indeed.
Along the same lines... If an exported template references another
template that is not exported, is implicit instantiation of this other
template required? I don't remember any such requirements, and I
could see reasons to do it both ways, but it appears to me that
imposing the requirement that an exported template won't cause
implicit instantiation of other non-exported templates referenced in
it, while it could be a major pain for people using such exported
templates, it would greatly simplify the process of deciding whether
symbols in anonymous namespaces could be made non-.global. Or so it
seems to me.
Thanks for your enlightenment,
--
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