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

Subject: Re: [boost] a new library Global Object Manager submission interest check
From: George Georgiev (george.georgiev.sf_at_[hidden])
Date: 2014-06-11 12:53:56

>
> 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?

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

Moreover, the monadic continuations framework being prepared for C++
> 17 is likely to become the right and proper way of specifying ordered
> sequences of stuff, and I see no reason it shouldn't do static data
> init too. The question would surely be asked "how does this plug into
> the monadic continuations framework, and if it doesn't, what good
> rationales are there why not?"
>
> Your best rationale right now is because the monadic continuations
> framework isn't fleshed out yet, but a year from now that will be
> harder to argue.
>

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.