On 8 Jun 2014 at 8:47, George Georgiev wrote:
1. It needs to provide the same facilities as C++ Modules on older compilers in a way which falls through to C++ Modules on newer compilers.
I have tested the implementation on several gcc and msvc compilers - and it works. It does not depend on any resent c++ improvements - and outperform the static initialization pattern even in its thread unsafe form.
I think you misunderstand me George. 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. That I think would get people here excited.
2. It needs to work correctly as shared libraries are dynamically loaded and unloaded.
This is something that I need to evaluate and add some tests, but I believe it will.
I would want to see correct handling of exception throws during shared library init and deinit. And running out of memory.
3. On top of that base you need thread ordering support such that the DAG can coordinate multiple threads during bootstrap and shutdown.
I am not sure what this means exactly, Could you please elaborate. Usually what I do is adding my thread pools and other multi-thread related object to the GlobalObjectManager - this way it indirectly helps for the bootstrap and shutdown, but this is without any implicit knowledge about their multi-thread nature (it is not needed).
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.
4. It needs to integrate well with debug tools like valgrind e.g. correctly get valgrind to account for true resource leaks versus fire and forget allocations.
This is done. It works also well with mcvs _CrtDumpMemoryLeaks()
Oh good! I remember manually running the MSVC CRT final end of process routines, and then manually exiting the process to get the MSVCRT leak dump to work right. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/