This is the mail archive of the gcc-patches@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: [PATCH 2/2] replace several uses of the anon namespace with GCC_FINAL


On 08/12/2015 11:36 PM, Trevor Saunders wrote:
> In many places gcc puts classes in the anon namespace so the compiler can tell
> they do not get inheritted from to enable better devirtualization.
C++ does not allow class members to have static linkage, so there is no way to
tell the compiler that a member function will not be called from another
translation unit except for placing it into an anonymous namespace. AFAIK this
affects inliner decisions rather significantly (i.e. devirtualization is not
the only reason).

> are they actually all that common?  I think gcc is the only C++ with
> which I'm familiar that uses them much.
LLVM is an example of another large project, which uses anonymous namespaces
extensively: http://llvm.org/docs/CodingStandards.html#anonymous-namespaces

BTW, I noticed that LLVM developers put small inline functions into anon.
namespaces (instead of just declaring them static). I wonder, whether it is just a
matter of style or there is some other, more important reason...

>> The problem is you can't get to stuff in the anonymous namespace easily in
>> the debugger.  There was talk of fixing that, but I don't think it ever went
>> forward on the gdb side.
I think, a possible solution is to define a macro which expands to "namespace {"
during normal build and expands to nothing in some sort of "debug build" (for
example, when ENABLE_CHECKING is defined).

-- 
Regards,
    Mikhail Maltsev


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