Our docs about --enable/--disable-visibility

[François Dumont]

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