This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/61113] New: Mark private methods hidden automatically
- From: "jpakkane at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 08 May 2014 14:19:35 +0000
- Subject: [Bug c++/61113] New: Mark private methods hidden automatically
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61113
Bug ID: 61113
Summary: Mark private methods hidden automatically
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Suppose you compile a class defined like this using -fvisibility=hidden:
class __attribute__ ((visibility("default"))) Thing final {
public:
void publicFunc();
private:
void privateFunc();
};
Dumping the .so file with nm -C -D gives this:
0000000000001626 T Thing::publicFunc()
000000000000166c T Thing::privateFunc()
That is, both the private and public methods are exported in the symbol table.
The latter is wasteful because private methods can only be called from within
the class and those methods are always in the same .so (or maybe there are
pathological cases why someone might want to split class implementation over
multiple .so files, but it seems unlikely).
This also inhibits compiler optimizations as described on the Gcc visibility
wiki page.
You can hide the method manually by declaring it like this:
void __attribute__ ((visibility("hidden"))) privateFunc();
If your code base is big, this a lot of work to do manually. Therefore it would
be nice if there was a way to hide private methods automatically. Alternatives
include a compiler flag such as -fvisibility-private-hidden or a heuristic that
tags private methods hidden if -fvisibility=hidden is specified on the command
line and the method's visibility has not been specified explicitly (so that
people can expose their private methods if they really want to).