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/