On Thu, Aug 13, 2015 at 07:56:47PM +0300, Mikhail Maltsev wrote: > 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).
In general that seems valid though in these particular cases I don't think the compiler could eliminate many members because most of them are virtual functions, and pointers to objects of there type escape the TU. > > 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 interesting > 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... I can't think of one, and that seems to contradict the style guide you linked? > >> 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). I'm wary of it being easy to write code that works with it defined one way but not the other. Trev > > -- > Regards, > Mikhail Maltsev
