Weak symbols and inline

[Paul Smith]

On Fri, 2014-02-28 at 08:54 +0100, Marc Glisse wrote:
> > Do you have a reference to the standard on this?
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59894#c1

I found a reference yesterday too, thanks.  It's odd that virtually all
the examples I've found online for replacing global operator new/delete
show using inline.  And, it definitely doesn't fail on any of the
compilers I have access to.  But good to know nonetheless!


On Thu, 2014-02-27 at 21:02 +0000, Jonathan Wakely wrote:
> > The function I'm inlining is actually global operator new.  It's not
> > legal to declare it static or in a namespace.
> 
> You're asking how to violate the One Definition Rule, which isn't
> legal either :-)

Yeah... it wasn't clear to me how the global operator new exception to
the ODR applied (allowing the user to override global operator
new/delete).  I guess I'm allowed to override, but only with one
definition.

Can I move out of the clouds of standards-compliance and into the mud of
implementations? :-).  Speaking specifically about GCC/binutils on
GNU/Linux, although at some point I'll need to address Windows MSVC and
MacOSX Clang/LLVM as well (not here, although I welcome pointers).

I'm creating a shared library from a large existing C++ codebase.  The
interface to the shared library is well-designed using abstract classes
and factories, and correct handling of memory.

In my shared library I want to use an alternate memory manager, and so I
want to override global operator new/delete.

However, I don't want my memory manager to "leak out" into the
executable using the shared library; I want the executable (also written
in C++) to be able to define its own memory management (or get the
system new/delete by default) without impacting my library and vice
versa.


I build all my code with -fvisibility=hidden, then mark the factory
functions as __attribute__((visibility("default"))).  Of course I didn't
mark the global operator new/delete as "default".

However, even though I didn't mark them that way, running nm on the .so
shows them as public symbols ("T").  I'm assuming that these functions
are handled specially so that the visibility=hidden default doesn't
apply to them?  I get a compiler error if I try to force them with
__attribute__.

So then I tried to use inline versions of global new/delete.  If I
further add __attribute__((force_inline)) then it APPEARS to do what I'd
like: none of my objects are exporting global new/delete.

Of course this is a bit hackish, and more concerning it means that if I
forget to include the header with the inline definitions into any of my
translation units then I silently get the wrong ones.


Is there a better supported, more "approved" way to handle this
requirement?

Would the standard-conforming answer be modifying all classes to declare
their own new/delete instead of relying on global new/delete, maybe by
introducing a common base class for everything?  That's just not
feasible for me at the moment: there are thousands of classes,
templates, etc. etc.  I need something less invasive.

Cheers!