On 9 Jun 2014 at 7:34, George Georgiev wrote:
I'm specifically asking for an implementation which emulates the C++ Modules static data system for older compilers, but which disables itself and passes through to C++ Modules on newer compilers.
This feels a bit of an overkill for what I am suggesting - after all it is a single template header file (that does not require precompiling).
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.
I would want to see correct handling of exception throws during shared library init and deinit. And running out of memory.
I do not see how what I have will affect the exception handling in any way, but I will add tests for this too.
Heh. You have some fun coming so.
Well how I handled it was DAG subgroups, so you could tag parts of the DAG as only being possible when a placeholder static init item said it was initialised. Basically I introduced asynchronicity into the static data init system.
I'll admit now I retrofitted it, and the retrofit wasn't great. But it persuades me a decent static data init and deinit system ought to be async capable from the beginning. This is what I mean by thread ordering support, though of course i/o is another good use case e.g. initialise a static variable from the contents of a file.
What I am suggesting is a very simple system to help for resolving the mentioned in the introduction issues. When a global object receives the control to initialize itself, it could apply whatever conditions and whatever source of input. It looks like the DAG system you are referring have a completely different scope of tasks that it was/is solving.
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 have feeling that we are talking for two completely different things. I have a very raw version of the GOM here: https://github.com/ggeorgiev/gom. If you would like to keep referencing your DAG system it will be helpful if you provide a little bit more information about it. Do you have it published somewhere?
Sadly no. I'm simply preparing you for the kind of stuff which would be asked during peer review. I doubt I'd be alone in wanting to see async in there for example, as initialising static data from storage or network is not uncommon, nor is launching threads and syncing with them during static init. 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/