10 thoughts on “cpp-resolver”

1. Hello Adam,

   I’ve just found your library and found it very useful. I really appreciate the work and I say that it’s solving lots of problems I have with the dependencies.

   I know it is in alpha state, but I found something that is lacking in the library.

   I’m stuck to using pointers to free functions, so I can’t use boost::function, neither boost::bind to the library.

   Do you have plans on adding this kind of feature in the future?

   Regards,
   Edison

2. Edison,

   What would an approach look like? We can probably make it work. I don’t want to link the core header to other dependenceis, but we could probably make an add-on header that supports boost::bind or boost::function. Send me some sample code and I’ll see if I can make it work.

3. Hello Adam, thanks for the fast asnwer.

   I can think of a simple example like this:

   class A {
   public:
   A(int param){}
   };
   A* myFactory(Zone& zone, int param1) {
   return new A(param1);
   }
   supply::configure(boost::bind(myFactory, _1, 1));

   In summary, if I could register factories beyond only free functions, but as boost::functions, which can be a member function, or many other things, my life would be better 🙂

   For a real world example, I have many many (~150) kinds of factories like this:

   class FactoryForA {
   static A* Create();
   }

   So, there is no Zone param in the factory, so if I had a more flexible type, beyond free functions, I would be able to write an adapter for this factory, which would take the Zone param and call my function.

   Thanks in advance,
   and just for you to know, I got the framework working today and it is soo good. It helped me a LOT.

4. Edison,
   I can’t help but think that it would be pretty easy to support bind. The default approach was to assume a no-args constructor, you want to make a no-args factory. So that would require something like:
   template
   T* delegate_to_factory(Zone& ){
   return F();
   };
   And then when you call configure you call:

   configure(delegate_to_factory(A, bind(…));

   Because, as we know, all (Computer Science) problems can be solved with an additional layer of indirection.

   I haven’t tried that yet, but if it fails, another thing you can try is building your own activator, and embed whatever state you require inside it, and registering it by hand. Once you get it to work once, generalizing it shouldn’t be that hard.

   I don’t have time to play with it right now. Let me know if you can get a prototype working, and we’ll mix it in to the rest of the code.

5. Hello Adam,

   I didn’t have the time to work on the support for more generic types for the activators. I’m now more worried about making other things work, and while doing that, some questions got into my mind.

   Why is there the HACK comment on this method:

   static void
   configure(const ZoneType& zoneType, factory factfunct,cleanup cleanfunct){
   //Hack. an attempt to force the creation of the activator map fairly early

   I think this method is maybe the most reasonable of the configures, since I sometimes want to configure a factory to exhist only on certain ZoneTypes.

   Also, I think that the ZoneType is kinda confusing. For example, I wanted to create a new kind of scope, which I called CommandScope, like in the example:

   class CommandScope{};

   Then when using the CommandScope, I would use ConcreteZoneType::get_instance(), but that makes a new Scope everytime it is called, shouldn’t that return a singleton for that kind of Scope? To cover that, U expanded the CommandScope class to this:

   class CommandScope{
   public:
   static resolver::ConcreteZoneType& GetInstance() {
   if (CommandScope::zoneType == 0) {
   CommandScope::zoneType= new resolver::ConcreteZoneType();
   }
   return *CommandScope::zoneType;
   }
   private:
   static resolver::ConcreteZoneType* zoneType;
   };

   Which in my opinion shouldn’t be done, but done by the framework. I think I maybe don’t understand the concept as you planned it.

   Thanks a lot, and sorry for any inconvenience,
   Edison

6. I just read my previous comment, and I want to add that I’ll be trying to do some work on the Generic type this weekend.

7. The hack comment went with the next line, which I meant to remove:

   int i = zoneType.zoneTypeCount;

   If you look at the SVN history, you wioll see that I had to convert the ZoneType from using static instances to static functions that instantiate static instances.

   See the Diff here:
   http://cpp-resolver.svn.sourceforge.net/viewvc/cpp-resolver/TRUNK/include/resolver.h?r1=16&r2=17

   Here’s the commit message, which, I think .says it well:
   to avoid the initialize dependency problem inherent in c++, I had to change the static instances to functions that create static instances on first access. This is an unfortunate side effect of c++. Without this change, the static instances would often segfault, as they were called prior to initialization. This means that programs that use these functions will appear to leak memory, although in reality they will merely allocate one instance on the stack per class, which means that it is no worse than static instances.

   I’ll answer the next part of your question in another post.

8. ZoneType is a singleton. It is meant to be a power type of the zone that uses it, and a key for looking up activators. There is only ever a single instance of it, as this initization code

   if (CommandScope::zoneType == 0) {
   CommandScope::zoneType= new resolver::ConcreteZoneType();
   }

   Is executed on a static instance variable. I didn’t want to do it this way, but C++ forced my hand. In Java, initialization of a static variable is done on first access, but C++ initializes if I understand correctly, in a random order prior to calling main();

9. Have you ever looked at POCO framework ? I recommended your DI solution to be included in there.

   http://pocoproject.org/forum/viewtopic.php?f=8&t=3076

10. I haven’t looked at POCO. I’m not currently in C++ mode although I’ve covered just about every other language in the past 10 months. I’d be happy to have the resolver code used in a larger project. I’ve registered on the POCO site (UID is admiyo) and I’d be happy to field any questions you have about it.

This site uses Akismet to reduce spam. Learn how your comment data is processed.