Re: [boost] a new library Global Object Manager submission interest check

Subject: Re: [boost] a new library Global Object Manager submission interest check
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-06-08 10:57:32

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 on
> 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 they
> are provided from static libraries and the code that uses them is not in use

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 years
> in several different projects. With the solution I come up a few years ago
> 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 community.

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 
compilers.

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 
now.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/