Adam Young wrote:
Having had a career that has bounced me between a few languages, I have had the opportunity to work with a couple of tools in the Java world that didn't see, to have analogues in C++. One of these is the inversion of control containers, of which Spring is one of the best known. Ken Fowler suggested the term "Dependency Injection" as a way to better describe how inversion of control is performed, and I prefer his term.
I've written a fairly simple dependency injection framework in C++ that seems to make proper use of the C++ Language. It is not attempting to do any COM like component model. Rather, it allows the developer the ability to cleanly separate the Object usage from the construction policy.
I've posted the code on Sourceforge at https://sourceforge.net/projects/cpp-resolver/. I have not yet taken the time to get it into proper format for a Sandbox project, but will do that next if there seems to be enough interest in the project. I wrote up the philosophy behind the design here:
http://adam.younglogic.com/?p=146
The code is currently g++ only, although I've attempted to use only core language constructs. It has no dependencies on other libraries other than stl collections.
Any constructive feed back will be most appreciated.
I've been using "manual" DI (mostly constructor-based injection) for a long time in C++, and would be interested in a generic DI framework. If it could be made to work with dynamically loaded classes it would be even better - perhaps with a little help from the proposed Boost.Plugin library that was under development some time ago. That being said, you'll need to provide some more documentation in order for at least me to have any specific comments. Starting out with some more snippets and examples would be a great idea, IMHO. Some desired functionality off the top of my head: - Simple registration, preferably in some declarative (instead of imperative) way. - Allow e.g. manual, thread-specific, stack-based (see below as well) and global registration. Consumers should not need to be aware of which one they are using. - It should be possible to specify fallback/priority policies; e.g. stack-based -> thread-specific -> global. - Support for temporarily overriding resolvers; e.g. scoped_resolver<T, ...>. Allows for easier test case development, among other things. - Support for injecting specific instances as well as types/factories. Regards, Johan Nilsson