Subject: Re: [boost] a new library Global Object Manager submission interest check
From: George Georgiev (george.georgiev.sf_at_[hidden])
Date: 2014-06-08 11:47:40
> 1. It needs to provide the same facilities as C++ Modules on older compilers
in a way which falls through to C++ Modules on newer compilers.
I have tested the implementation on several gcc and msvc compilers - and it
works. It does not depend on any resent c++ improvements - and outperform
the static initialization pattern even in its thread unsafe form.
> 2. It needs to work correctly as shared libraries are dynamically loaded
This is something that I need to evaluate and add some tests, but I believe
> 3. On top of that base you need thread ordering support such that the DAG
can coordinate multiple threads during bootstrap and shutdown.
I am not sure what this means exactly, Could you please elaborate. Usually
what I do is adding my thread pools and other multi-thread related object
to the GlobalObjectManager - this way it indirectly helps for the bootstrap
and shutdown, but this is without any implicit knowledge about their
multi-thread nature (it is not needed).
> 4. It needs to integrate well with debug tools like valgrind e.g. correctly
get valgrind to account for true resource leaks versus fire and forget
This is done. It works also well with mcvs _CrtDumpMemoryLeaks()
On Sun, Jun 8, 2014 at 7:57 AM, Niall Douglas <s_sourceforge_at_[hidden]>
> On 7 Jun 2014 at 15:28, George Georgiev wrote:
> > I have code that deals with problems related to initialization of global
> > objects (singletons).
> As do we all :)
> > 1. Multi-threading - problems occurring in some singleton patterns based
> > the fact that local for a function or method static variables are not
> > initialized in a thread safe manner
> Fixed in C++ 11, but MSVC is lagging on this.
> > 2. Initialization order - there is no multi-platform/multi-compiler
> > standard way to control the global objects initialization order
> Partially fixed in proposed C++ Modules for C++ 17.
> > 3. Static linking of global objects code without need - some patterns
> > result in global objects to be linked in the final executable, even if
> > are provided from static libraries and the code that uses them is not in
> Huge improvements on this coming in MSVC soon actually. It's always a
> battle though.
> > 4. Capability for easy replacement of a global implementation object
> with a
> > mock object
> Mmm, I've always wished you could have easy random exception throws
> for testing without lots of extra macro based plumbing. Hard without
> modifying the compiler though.
> > I was struggling with shutdown issues in complex c++ application for
> > in several different projects. With the solution I come up a few years
> > I have no issues in any project I have used it.
> I had a system for building a thread aware static global init and
> deinit DAG nearly two decades ago. It worked beautifully, and I have
> always wished something like it were standard in C++.
> > Please let me know if this is something of interest to the boost
> Definitely yes, but probably not in the form you have already
> implemented. Here's what I'd need to see for me to feel positive:
> 1. It needs to provide the same facilities as C++ Modules on older
> compilers in a way which falls through to C++ Modules on newer
> 2. It needs to work correctly as shared libraries are dynamically
> loaded and unloaded.
> 3. On top of that base you need thread ordering support such that the
> DAG can coordinate multiple threads during bootstrap and shutdown.
> 4. It needs to integrate well with debug tools like valgrind e.g.
> correctly get valgrind to account for true resource leaks versus fire
> and forget allocations.
> If you can do all that I'll volunteer to peer review manage it right
> ned Productions Limited Consulting
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk