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 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


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