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-11 16:36:26

On 11 Jun 2014 at 9:53, George Georgiev wrote:

> > I think it could be done using macros. Think __LINE__ and you're
> > heading the right way to emulating the ordering support in C++
> > Modules.
> 
> Can you give me some code examples - a boost library that already does it?

Apologies, I have made a mistake. I had thought that static data is 
initialised in declaration order of the C++ Module interface file 
which overrode the C++98 ordering of per-compiland, but looking at 
N3347 I see no mention of that. It only says that module partitions 
ought to be initialised on the order of import. If one kept one 
source file per module,
one could therefore enforce static data initialisation ordering, 
otherwise one is back to square one.

Furthermore N4047 says nothing about initialisation order at all 
other than it is invariant to the code i.e. random i.e. same as now.

You can forget about my wish for an emulation of C++ Modules. You 
cannot emulate no provision. Sorry for wasting your time.

> > Not really. Data initialisation ordering gets complex very quickly,
> > because it's semantically identical to booting an OS.
> >
> > This is why a really good solution would mirror best in practice with
> > OS booting. A sys V equivalent would work and be simple, but I'm not
> > sure how useful with modern coding patterns. At a certain
> > multinational I used to work for, poor static data initialisation
> > implementation caused multi second process startup times, so this is
> > a very real problem.
> 
> I can do some things to improve conditional initializations,
> parallelization, etc. but frankly I do not share your perspective of what a
> usual c++ application should be doing with singletons. Singletons should be
> considered evil and should be chosen as pattern very carefully. My goal is
> not to create utility that will allow people to feel better to abuse the
> pattern.

Meh. I care about what works and scales out beautifully in an easy to 
use and safe fashion. Much of the time that matches CS theory, 
sometimes it doesn't.

> IMHO there is no system that could be perfect in every aspect from day one.
> Addressing potential misalignment with monadic continuations framework
> could be prioritised accordingly to their progress. Meanwhile we have a
> real problem at hand - multi-thread applications written against boost
> libraries have random crashes from a hard to reproduce and investigate
> source(s). I think this is the important aspect that boost community should
> focus on. Later on if we did mistakes and we did not make everything
> perfect we will learn from them and we will create GOM 2, 3, etc or we will
> abandon it as a completely bad idea and we will create something completely
> different.

All very valid points. If you do decide to present for review, do 
write up a design rationale page for the docs which explains all the 
routes you didn't take with reasons why. There is never anything 
wrong with saying "this is an intentionally simple v1.0 to learn more 
about the problem", whether of course that will pass review or not is 
another matter.

Niall

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