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
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
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
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk