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!
