help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anonymous namespace implications - footprints


From: kobi . cohenarazi
Subject: Re: Anonymous namespace implications - footprints
Date: 18 Jun 2006 17:47:04 -0700
User-agent: G2/0.2

Thanks Paul,

Paul Pluzhnikov wrote:
> kobi.cohenarazi@gmail.com writes:
>
>
> AFAICT this has noting to do with optimizer, and it's not really
> of any interest to anyone, except a few people building for extremely
> memory-constrained embedded systems (who generally stay away from C++
> anyway).
But some use C++ for embedded. Bjorne + Sutter do think that C++ good
for embedded, (minus exceptions). Me 2. If you know what you're doing,
and how to use c++, you're good.

>
>
> So there is a 5% size difference, big deal.
Yes. Big deal. The point is why exporting somthing that is not used
anyway.
Why use anonymuos namespace? Only because of templates. Thats it. The
increase of footprints doesnt justified deprecating static. Thats my
point. Right, many apps dont mind, but since anonymous namespace has
external linkeage and it is exported (like you pointed below nm/readelf
-S), it increase the footprints. I say, if thats the case, and if
compilers put it in the export table, and there is increase of the size
... leave static , dont take it from us. If the compiler can optimize
it and remove these symbols, that would be great. For example, if the
compiler/linker can understand that these anonymous symbol (which is
mangaled like you pointed) is not used in any template (which requires
external linkeage), so remove it from the table. Thats it. It should be
simple, since anonymous namespace are used only in the same compilation
unit.

Kobi.

>
> If you *look* where that difference came from (with "nm" or "readelf -S"),
> you'll discover that anonymous namespace isn't actually anonymous;
> its name is just a randomly-generated string of 40+ characters [1],
> and you pay that price for each exposed symbol.
>
> If this anounts to any significant overhead in your program, you
> probably have too many "global functions", which are too short;
> or too many global data.
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]