This is the mail archive of the 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]

Re: Static linkage and anonymous namespace

>   But why can't we just make the definitions have internal linkage if
> they're in an anonymous namespace?  Why do we need to introduce the
> TREE_PRIVATE bit?  In other words, at some point the compiler decides
> whether to make things have internal or external linkage.  Why doesn't
> it just use the DECL_CONTEXT (recursively looking at parent contexts)
> to see what linkage the thing should get?

Good questions. As far as I can tell, there are two reasons:

1. Not all members of an anonymous namespace can have internal
   linkage. Specifically, foo in

     extern "C" foo(){}

   can be called from other translation units. This is because of the
   way anonymous namespaces and C linkage are defined. Maybe this is
   really a defect, maybe this is intentional.

2. Some members of named namespaces also get this internal linkage.

   namespace {
     struct Foo{};

   we get this on

   void print(Foo&){}
   std::vector<Foo> vfoo;

   Other translations can't use these objects/functions, since they
   can't provide the parameters. Not making them internal means to
   risk linkage problems again, if some other translation unit has the
   same sequence of tokens.

   I started computing whether an object is related to anonymous
   namespaces, i.e. analyze template parameters and argument types.  I
   then realized that I reimplemented the mangling algorithm.

So, I think the current patch does exactly what it is supposed to do:
all assembler names that contain the supposedly unique anonymous
namespace name should have internal linkage.

Maybe the implementation of that is messy; I'll take advise on how to
improve it.


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