This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Our docs about --enable/--disable-visibility


On 11/02/2011 03:50 PM, Vincenzo Innocente wrote:
On 1 Nov, 2011, at 8:09 PM, Jason Merrill wrote:

On 10/31/2011 06:41 AM, Vincenzo Innocente wrote:
The problem is that "default" means "force external visibility", not "use user visibility".
The default for the standard library, yes. The standard library should have external visibility by default.

Perhaps you want something like -fvisibility-inlines-hidden that also applies to .

In principle the fix for PR30066 should allow that when the function templates are explicitely inlined.
The point is that many std functions are NOT explicitely declared inline and therefore are not affected by -fvisibility-inlines-hidden.

I want to stress that my concern in not about the public standard interfaces, more about implementation details
such as :__introsort_loop, _move_median_first, the back-tree implementation behind std:map etc.
At the moment they can even be specialized and "pre-empted" by the user in a different shared library
(see discussion inhttp://sourceware.org/bugzilla/show_bug.cgi?id=12919) and I'm not really sure that this was the intention.

Declaring all those implementation functions inline and eventually moving them in a separate (not default visible) namespace other than "std" may be a suitable long term solution.

vincenzo
I just wanted to signal that I have started working on separating debug functions from normal functions like we have debug containers and normal containers. To make this task easier regarding the implied modification in namespace management I had already starting moving all implementation details in a dedicated namespace.

For the moment it is std::__detail, I hope visibility attribute on std namespace is not applied to nested namespace, if so I could change it. I will go back to this task as soon as my work on hashtable is achieved.

François


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