[intrusive] rtti_base class proposition
Hi, Here is my idea for this little class: class rtti_base { virtual void _dummy() {} }; Every class deriving from rtti_base can be queried by means of RTTI, in particular rtti_base class and dynamic_cast can be used in similar way as IUnknown and QueryInterface() in COM Object Model rtti_base* could be used as a "smart" void* pointer - we can get type information, and use it in heterogenic containers as in: std::list<rtti_base*> beings; we can iterate through beings and call Cat::GiveMilk() for cats but Girl::Kiss() for girls. :-) The main purpose of this class is to set some standard name for that pointer type. Ireneusz Szpilewski
Ireneusz Szpilewski wrote:
class rtti_base { virtual void _dummy() {} };
Once you have virtual functions, you need a virtual destructor. Hence the base class should define a virtual destructor and then there's no need for _dummy().
Every class deriving from rtti_base can be queried by means of RTTI, in particular rtti_base class and dynamic_cast can be used in similar way as IUnknown and QueryInterface() in COM Object Model [snip] The main purpose of this class is to set some standard name for that pointer type.
Why is a common, standardized or de facto standard name needed? The usual case is to create a base class for each context in which a common base is desired. There's no value, that I can see, in having a common base for all such cases. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:Stewart, Robert wrote:
Ireneusz Szpilewski wrote:
class rtti_base { virtual void _dummy() {} };
Once you have virtual functions, you need a virtual destructor. Hence the base class should define a virtual destructor and then there's no need for _dummy().
Every class deriving from rtti_base can be queried by means of RTTI, in particular rtti_base class and dynamic_cast can be used in similar way as IUnknown and QueryInterface() in COM Object Model
[snip]
The main purpose of this class is to set some standard name for that pointer type.
Why is a common, standardized or de facto standard name needed? The usual case is to create a base class for each context in which a common
Great idea! :-D base is desired.
Because that could be a C++ standard common class as Object in C# or IUnknown in COM. Let's call it object_t. ;-) Just not forced by language rules, but used at will if needed. Anyone could attach to it and have generic pointer to objects. As in my example above, I have a room where are cats and girls. I want to give milk to cats and kiss girls. There are two classes: class Cat { public: void GiveMilk(); }; class Girl { public: void Kiss(); }; they have really nothing in common, but objects of both classes are in my room. So I add to them something by which I can hold them all via pointers, and, in addition, query about their types. Let's suppose you have the same problem with different (or not) classes and have used also rtti_base to hold them all. Then we both win! You can insert your objects into my container, and if by accidence they derive from Cat or/and Girl, they will be pleased in my room. If I put my objects into your collection std::stack<rtti_base*> for example, they can also be pleased if you GiveMilk() to Cats and Kiss() Girls. :-) (By the way std::shared_ptr<rti_base*> would give us C++ equivalent of IUnknown interface with metods: QueryInterface(); AddRef(); Release(); ) Ireneusz Szpilewski
Am Tuesday 20 October 2009 19:47:38 schrieb Ireneusz Szpilewski:
Why is a common, standardized or de facto standard name needed? The
usual case is to create a base class for each context in which a common base is desired.
there are various solutions for this in C++ and boost. when you migrate from another language a common object base class might seem necessary, but I don't know of a case that can't be handled by void *, boost::any, boost::variant...
(By the way std::shared_ptr<rti_base*> would give us C++ equivalent of IUnknown interface with metods: QueryInterface(); AddRef(); Release(); )
boost::intrusive_ptr
Stefan Strasser wrote:
Am Tuesday 20 October 2009 19:47:38 schrieb Ireneusz Szpilewski:
Why is a common, standardized or de facto standard name needed? The
usual case is to create a base class for each context in which a common base is desired.
there are various solutions for this in C++ and boost. when you migrate from another language a common object base class might seem necessary, but I don't know of a case that can't be handled by void *, boost::any, boost::variant...
I think it would be yet another possibility, kind of smart void*. In math, objects having special properties deserve unique name to identify them, as 0, 1, pi. We don't have special name for number 245.43234. An empty class with sole virtual destructor is such a special object. C++ allows RTTI iif class has a virtual function. So the easiest way to tell someone how to RTTI-enable his class would be to say: "Derive from rtti_base"). class rtti_base { public: ~rtti_base(){} } Ireneusz Szpilewski
On Wed, Oct 21, 2009 at 2:54 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
Stefan Strasser wrote:
Am Tuesday 20 October 2009 19:47:38 schrieb Ireneusz Szpilewski:
> Why is a common, standardized or de facto standard name needed? The
usual case is to create a base class for each context in which a common base is desired.
there are various solutions for this in C++ and boost. when you migrate from another language a common object base class might seem necessary, but I don't know of a case that can't be handled by void *, boost::any, boost::variant...
I think it would be yet another possibility, kind of smart void*.
Actually there is such "smart void*" which does rtti checking during casts in the Boost Vault: [vault]/Memory/RawPtr/rawptr-draft.zip
In math, objects having special properties deserve unique name to identify them, as 0, 1, pi. We don't have special name for number 245.43234. An empty class with sole virtual destructor is such a special object. C++ allows RTTI iif class has a virtual function. So the easiest way to tell someone how to RTTI-enable his class would be to say: "Derive from rtti_base"). class rtti_base { public: ~rtti_base(){} }
Ireneusz Szpilewski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ________________ ::matus_chochlik
Matus Chochlik wrote:
On Wed, Oct 21, 2009 at 2:54 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
Stefan Strasser wrote:
Am Tuesday 20 October 2009 19:47:38 schrieb Ireneusz Szpilewski:
Why is a common, standardized or de facto standard name needed? The
usual case is to create a base class for each context in which a common base is desired.
there are various solutions for this in C++ and boost. when you migrate from another language a common object base class might seem necessary, but I don't know of a case that can't be handled by void *, boost::any, boost::variant...
I think it would be yet another possibility, kind of smart void*.
Actually there is such "smart void*" which does rtti checking during casts in the Boost Vault: [vault]/Memory/RawPtr/rawptr-draft.zip
But do we need a special library for such a simple thing?
In math, objects having special properties deserve unique name to identify them, as 0, 1, pi. We don't have special name for number 245.43234. An empty class with sole virtual destructor is such a special object. C++ allows RTTI iif class has a virtual function. So the easiest way to tell someone how to RTTI-enable his class would be to say: "Derive from rtti_base"). class rtti_base { public: ~rtti_base(){} }
Ireneusz Szpilewski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Stefan Strasser wrote:
(By the way std::shared_ptr<rti_base*> would give us C++ equivalent of IUnknown interface with metods: QueryInterface(); AddRef(); Release(); ) boost::intrusive_ptr
Boost documentation on boost::intrusive_ptr says:
"As a general rule, if it isn't obvious whether *intrusive_ptr* better fits your needs than *shared_ptr*, try a *shared_ptr*-based design first."
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ireneusz Szpilewski wrote:
Stewart, Robert wrote:Stewart, Robert wrote:
Ireneusz Szpilewski wrote:
Every class deriving from rtti_base can be queried by means of RTTI, in particular rtti_base class and dynamic_cast can be used in similar way as IUnknown and QueryInterface() in COM Object Model
Why is a common, standardized or de facto standard name needed? The usual case is to create a base class for each context in which a common base is desired.
Because that could be a C++ standard common class as Object in C# or IUnknown in COM. Let's call it object_t. ;-) Just not forced by language rules, but used at will if needed. Anyone could attach to it and have generic pointer to objects.
I don't care what you call it. There is no good reason to do this in C++. [snipped examples of using containers of heterogeneous types.] I'm well aware of uses of this approach and they are usually misguided. A common base class is not terribly helpful. One specific to a particular use case is far more useful. Using your approach encourages programming with dynamic_cast. There are times when it is needed, but its use should be limited and not encouraged generally. In your cats and girls use case, the proper thing to apply is the Visitor Pattern. That permits you to do double-dispatch to determine the correct behavior when a visitor interacts with the objects in a room. Only when the visitor's type is combined with that of an object is the correct interaction known. Hard coding that into a function is a maintenance nightmare and should be avoided. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Ireneusz Szpilewski wrote:
[...] I don't care what you call it. There is no good reason to do this in C++.
[snipped examples of using containers of heterogeneous types.]
I'm well aware of uses of this approach and they are usually misguided. A common base class is not terribly helpful. One specific to a particular use case is far more useful. Using your approach encourages programming with dynamic_cast. There are times when it is needed, but its use should be limited and not encouraged generally.
I think of rtti_base as of yet another screwdriver in our toolbox. The more tools we have, the more various things we can do. As you wrote:
"There are times when it is needed" ;-) so, why not to have it?
Ireneusz Szpilewski
On Wed, Oct 21, 2009 at 3:09 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
Stewart, Robert wrote:
Ireneusz Szpilewski wrote:
[...] I don't care what you call it. There is no good reason to do this in C++.
[snipped examples of using containers of heterogeneous types.]
I'm well aware of uses of this approach and they are usually misguided. A common base class is not terribly helpful. One specific to a particular use case is far more useful. Using your approach encourages programming with dynamic_cast. There are times when it is needed, but its use should be limited and not encouraged generally.
I agree that defining and using a common base class for all other classes in a project is in 99% of cases a very bad idea. There is a book called "C++ Gotchas: Avoiding Common Problems in Coding and Design" and the use of such "cosmic hierarchies" is a gotcha #97 ;-)
I think of rtti_base as of yet another screwdriver in our toolbox. The more tools we have, the more various things we can do. As you wrote: "There are times when it is needed" ;-) so, why not to have it?
Ireneusz Szpilewski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ________________ ::matus_chochlik
Matus Chochlik wrote:
On Wed, Oct 21, 2009 at 3:09 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
Stewart, Robert wrote:
Ireneusz Szpilewski wrote:
[...] I don't care what you call it. There is no good reason to do this in C++.
[snipped examples of using containers of heterogeneous types.]
I'm well aware of uses of this approach and they are usually misguided. A common base class is not terribly helpful. One specific to a particular use case is far more useful. Using your approach encourages programming with dynamic_cast. There are times when it is needed, but its use should be limited and not encouraged generally.
I agree that defining and using a common base class for all other classes in a project is in 99% of cases a very bad idea. There is a book called "C++ Gotchas: Avoiding Common Problems in Coding and Design" and the use of such "cosmic hierarchies" is a gotcha #97 ;-)
Don't look at class hierarchy, look at object. It would be composed of many other subobjects (by means of multiple inheritance), just as a human body is composed of different organs. What's wrong with fact that all men have penises? (I will make "rtti_base" tattoo on mine) Of course man should have one penis, so every class should inherit rtti_base virtually. (By the way, C++ virtual inheritance implementation is broken) I insist on that deriving from rtti_base is voluntary and controlled by a particular class hierarchy designer. In our analogy - every man can have his penis cut off if he (or his wife) doesn't need it. What can you do with penises? We all know what. ;-) And what can we do with rtti_base? If we have pointer to it, we can query the pointed object using RTTI. Ireneusz Szpilewski
2009/10/21 Ireneusz Szpilewski <irek@szpilewski.opole.pl>:
Don't look at class hierarchy, look at object. It would be composed of many other subobjects (by means of multiple inheritance), just as a human body is composed of different organs.
How do you implement a heart transplant when you inherit from your heart, rather than contain it? (Not that I think arguing by analogy is a good idea.)
Scott McMurray wrote:
2009/10/21 Ireneusz Szpilewski <irek@szpilewski.opole.pl>:
Don't look at class hierarchy, look at object. It would be composed of many other subobjects (by means of multiple inheritance), just as a human body is composed of different organs.
How do you implement a heart transplant when you inherit from your heart, rather than contain it?
Before transplant: class Me: private MyHeart { }; After transplant: class Me: private SombodyElsesHeart { }; Ireneusz Szpilewski
2009/10/21 Ireneusz Szpilewski <irek@szpilewski.opole.pl>:
Scott McMurray wrote:
How do you implement a heart transplant when you inherit from your heart, rather than contain it?
Before transplant:
class Me: private MyHeart { };
After transplant:
class Me: private SombodyElsesHeart { };
And how exactly are you supposed to make that change at runtime? (That's not a heart transplant; That's growing a clone body around the new heart.)
Scott McMurray wrote:
2009/10/21 Ireneusz Szpilewski <irek@szpilewski.opole.pl>:
Scott McMurray wrote:
How do you implement a heart transplant when you inherit from your heart, rather than contain it?
Before transplant:
class Me: private MyHeart { };
After transplant:
class Me: private SombodyElsesHeart { };
And how exactly are you supposed to make that change at runtime?
What do you suggest?
heart as a member of Me? Before: class Me { MyHeart heart; }; After: class Me { SomebodyElsesHeart heart; } It can't be done at runtime either.
(That's not a heart transplant; That's growing a clone body around the new heart.)
This is exactly how transplant is seen from the new heart point of view ;-)
Ireneusz Szpilewski
Hi, On Thu, Oct 22, 2009 at 5:26 AM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
And how exactly are you supposed to make that change at runtime?
What do you suggest?
heart as a member of Me?
Before:
class Me { MyHeart heart; };
After:
class Me { SomebodyElsesHeart heart; }
It can't be done at runtime either.
If MyHeart and SomebodyElsesHeart publicly inherited from say, a Heart (abstract) base class, and if Me's heart member variable was a (smart) pointer to Heart, then you could indeed change the actual (sub)type of the Heart object that a Me object owns at runtime. This is a common technique, methinks. Regards, Eugene
Eugene Wee wrote:
Hi,
On Thu, Oct 22, 2009 at 5:26 AM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
And how exactly are you supposed to make that change at runtime?
What do you suggest?
heart as a member of Me?
Before:
class Me { MyHeart heart; };
After:
class Me { SomebodyElsesHeart heart; }
It can't be done at runtime either.
If MyHeart and SomebodyElsesHeart publicly inherited from say, a Heart (abstract) base class, and if Me's heart member variable was a (smart) pointer to Heart, then you could indeed change the actual (sub)type of the Heart object that a Me object owns at runtime. This is a common technique, methinks.
Regards, Eugene _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
So, what do you suggest? Heart* as a member of Me? Let's try: struct Me { Me() { heart = new(MyHeart); } ~Me() { delete heart; } private: Heart* heart; }; What if MyHeart has SingMySong() method while Heart does not? How can I access it? Ireneusz Szpilewski
Hi, On Thu, Oct 22, 2009 at 12:08 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
What if MyHeart has SingMySong() method while Heart does not? How can I access it?
Since we are on the topic of RTTI, you could just use say, dynamic_cast to convert the Heart* to a MyHeart* and thus call SingMySong(). On the other hand, maybe Heart should have such a virtual function instead, if it is supposed to be used polymorphically. Regards, Eugene
Eugene Wee wrote:
On Thu, Oct 22, 2009 at 12:08 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
What if MyHeart has SingMySong() method while Heart does not? How can I access it?
Since we are on the topic of RTTI, you could just use say, dynamic_cast to convert the Heart* to a MyHeart* and thus call
That's the source of the problem for this whole thread: the OP is too inclined to use dynamic_cast to solve design problems. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Eugene Wee wrote:
Hi,
On Thu, Oct 22, 2009 at 12:08 PM, Ireneusz Szpilewski <irek@szpilewski.opole.pl> wrote:
What if MyHeart has SingMySong() method while Heart does not? How can I access it?
Since we are on the topic of RTTI, you could just use say, dynamic_cast to convert the Heart* to a MyHeart* and thus call SingMySong(). On the other hand, maybe Heart should have such a virtual function instead, if it is supposed to be used polymorphically.
But we were to do a transplant in C++. I'll try my best, I set up my classes: class MyHeart: public rtti_base, // can do dynamic_cast public Heart, // it is human heart public MySongSinger // it can SingMySong() { // }; class Me: public rtti_base, // can do dynamic_cast public Human // I am a Human, hospital can do Human->SwapHearts(Heart* newheart); { //... rtti_base* heart; // initialized to new MyHeart }; I am ready and waiting in the hospital for a dead person heart. BANG!!! Fortunately (for me) there was a car accident and we have 2 bodies: Joe dead_joe; AlienHumanoid dead_alien; What to do next? Ireneusz Szpilewski
Am Thursday 22 October 2009 18:24:14 schrieb Ireneusz Szpilewski:
But we were to do a transplant in C++. I'll try my best, I set up my classes:
class MyHeart: public rtti_base, // can do dynamic_cast public Heart, // it is human heart public MySongSinger // it can SingMySong() { // };
class Me: public rtti_base, // can do dynamic_cast public Human // I am a Human, hospital can do Human->SwapHearts(Heart* newheart); { //... rtti_base* heart; // initialized to new MyHeart };
I am ready and waiting in the hospital for a dead person heart. BANG!!! Fortunately (for me) there was a car accident and we have 2 bodies:
Joe dead_joe; AlienHumanoid dead_alien;
What to do next?
could you plase move this to comp.lang.c++ or a similar place?
I agree that defining and using a common base class for all other classes in a project is in 99% of cases a very bad idea. There is a book called "C++ Gotchas: Avoiding Common Problems in Coding and Design" and the use of such "cosmic hierarchies" is a gotcha #97 ;-)
How would you model in C++ such situation:
Matus Chochlik wrote: there is a Factory making plastic Cats and Dogs. They make some cats and dogs every day. Truck drivers arrive from time to time and get new products for further processing. Plastic cats and dogs are not sorted by the factory, they are mixed together and have the same price. How the factory should be modeled? struct Factory { ? }; Ireneusz Szpilewski
Ireneusz Szpilewski wrote:
there is a Factory making plastic Cats and Dogs. They make some cats and dogs every day. Truck drivers arrive from time to time and get new products for further processing. Plastic cats and dogs are not sorted by the factory, they are mixed together and have the same price.
How the factory should be modeled?
struct Factory { ? };
you just have to have Cat and Dog inherit from FactoryProduct and not from an arbitrary cosmic base class that has no meaning in the model. That's object design 101
Joel Falcou wrote:
Ireneusz Szpilewski wrote:
there is a Factory making plastic Cats and Dogs. They make some cats and dogs every day. Truck drivers arrive from time to time and get new products for further processing. Plastic cats and dogs are not sorted by the factory, they are mixed together and have the same price.
How the factory should be modeled?
struct Factory { ? };
you just have to have Cat and Dog inherit from FactoryProduct and not from an arbitrary cosmic base class that has no meaning in the model.
That's object design 101
Exactly my thought and what I was attempting to convey in my earlier replies: I think the OP is stuck in the misguided mindset of using pointers to a weak ABC + dynamic_cast to handle variations, hence the wish for a "cosmic base class." That's why I suggested, for example, the Visitor Pattern, to a previous query. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Joel Falcou wrote:
Ireneusz Szpilewski wrote:
there is a Factory making plastic Cats and Dogs. They make some cats and dogs every day. Truck drivers arrive from time to time and get new products for further processing. Plastic cats and dogs are not sorted by the factory, they are mixed together and have the same price.
How the factory should be modeled?
struct Factory { ? }; you just have to have Cat and Dog inherit from FactoryProduct and not from an arbitrary cosmic base class that has no meaning in the model. OK, lets call it boost::object :-).
Ireneusz Szpilewski
Ireneusz Szpilewski wrote:
Joel Falcou wrote:
you just have to have Cat and Dog inherit from FactoryProduct and not from an arbitrary cosmic base class that has no meaning in the model.
OK, lets call it boost::object :-).
You're missing the point. It isn't the name he's faulting. It's the use of a meaningless ABC just to add RTTI support. As I said before, you create an ABC that represents the root of a hierarchy for the given use case, not use a one-size-fits-all ABC. In this case, as Joel noted, Product is your ABC. Give it appropriate virtual functions and a virtual destructor and create collections of Products to your hearts content. Why would you need a container of Products and Organs (as in body parts) when one belongs to a factory and the other to a hospital? They are unrelated, so they shouldn't derive from a common base class. Given the foregoing, there's no value in your RTTI ABC. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Thursday, October 22, 2009 5:04 PM Subject: Re: [boost] [intrusive] rtti_base class proposition
Ireneusz Szpilewski wrote:
Joel Falcou wrote:
you just have to have Cat and Dog inherit from FactoryProduct and not from an arbitrary cosmic base class that has no meaning in the model.
OK, lets call it boost::object :-).
You're missing the point. It isn't the name he's faulting. It's the use of a meaningless ABC just to add RTTI support. As I said before, you create an ABC that represents the root of a hierarchy for the given use case, not use a one-size-fits-all ABC.
In this case, as Joel noted, Product is your ABC. Give it appropriate virtual functions and a virtual destructor and create collections of Products to your hearts content. Why would you need a container of Products and Organs (as in body parts) when one belongs to a factory and the other to a hospital? They are unrelated, so they shouldn't derive from a common base class
Because I am a Juggler. OK I give up, thanks :-)
participants (7)
-
Eugene Wee -
Ireneusz Szpilewski -
Joel Falcou -
Matus Chochlik -
Scott McMurray -
Stefan Strasser -
Stewart, Robert