|
Bugzilla – Full Text Bug Listing |
| Summary: | Constructing objects from a TypeId seems complex | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | core | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | CC: | mathieu.lacage |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
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. |
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;