Bugzilla – Bug 518
Constructing objects from a TypeId seems complex
Last modified: 2009-03-10 07:16:52 UTC
From the code I am writing: void AddWimetronetStack (Ptr<Node> node, NodeId nodeId, TypeId terminalMobility) { [...] terminalMobilityStrategy = Ptr<wmrp::TerminalMobilityStrategy> (dynamic_cast<wmrp::TerminalMobilityStrategy*> (terminalMobility.GetConstructor ()()), false); [...] So, given a TypeId, creating an object of that typeid seems rather more complex than the average NS-3 programmer will be able to discern. Good thing I am not an average programmer, but I feel sorry for the poor souls that will need to do this too :-) A good candidate for a better API could be (for example): Ptr<T> TypeId::CreateObject () const;
ObjectFactory::SetTypeId (...); ObjectFactory::CreateObject<> (...); The above API could be improved probably but I think it is fairly close to what you want. I am going to mark this bug as invalid unless you add more context.
I did have the feeling I was missing something... :-) Still, it would be nice to construct an object directly from a TypeId. It's how e.g. Python works: you call the type and as result you get an instance of that type. It's rather uncomplicated.
(In reply to comment #2) > I did have the feeling I was missing something... :-) > > Still, it would be nice to construct an object directly from a TypeId. It's > how e.g. Python works: you call the type and as result you get an instance of > that type. It's rather uncomplicated. The main reason why this is not so is that a TypeId can represent anything which derives from ObjectBase while ObjectFactory can only create objects which derive from Object.
(In reply to comment #3) > (In reply to comment #2) > > I did have the feeling I was missing something... :-) > > > > Still, it would be nice to construct an object directly from a TypeId. It's > > how e.g. Python works: you call the type and as result you get an instance of > > that type. It's rather uncomplicated. > > The main reason why this is not so is that a TypeId can represent anything > which derives from ObjectBase while ObjectFactory can only create objects which > derive from Object. I don't see how one thing invalidates the other: Ptr<T> TypeId::operator() const; This is type agnostic; can build anything that is reference countable ;-)
(In reply to comment #4) > > The main reason why this is not so is that a TypeId can represent anything > > which derives from ObjectBase while ObjectFactory can only create objects which > > derive from Object. > > I don't see how one thing invalidates the other: > > Ptr<T> TypeId::operator() const; > > This is type agnostic; can build anything that is reference countable ;-) ObjectBase is not reference countable, hence, my earlier comment.
(In reply to comment #5) > ObjectBase is not reference countable, hence, my earlier comment. Oh.. I had not noticed it. Probably "Ptr<T> TypeId::CreateObject () const;" would still work in spite of this. But to preserve the layering logic, I give up on this.