|
|
Great for when I'm using say a vector in a mutithreaded situation. Derive a class from a vector or map, combined with a Critcal Section wrapper class so I can Lock and Unlock it.
Nice.
Giles
|
|
|
|
|
In this case, I would always prefer containment over MI. Looks cleaner, IMHO.
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
i always thought deriving from all the stl - classes is plain bad, because their destructor ist not virtual?
didn't you ever shoot yourself in the foot with this?
well.. most of the articles said that the problem could occur just occasionally.. but you say you use it all the time and had never problems? lucky you..
my opinion toward mi..
i prefer containment.. but sometimes it is essential.. and makes sense.. and then i use it..
have a nice one...
bernhard
Sometimes I think the surest sign for intelligent life elsewhere in
the universe is that none of them ever tried to contact us.
|
|
|
|
|
Bernhard wrote:
always thought deriving from all the stl - classes is plain bad, because their destructor ist not virtual?
didn't you ever shoot yourself in the foot with this?
No problems. Its always worked out quite nicely. Really.
Giles
|
|
|
|
|
I dunno about MFC, but ATL sure as anything derives from multiple classes, every time. So of course I use it, indirectly 
I would have liked a 'No, I've never had the need' option though, as opposed to I don't SEE the need, which is quite a different thing. I guess this question stems from C# not supporting MI ? I'm using C# right now, and let me take this opportunity to whine about it.
Why, oh why, does this not work ?
Bitmap b;
Bitmap c = b.Clone();
Even though they are both Bitmaps, I need to CAST the return from b.Clone() to a Bitmap for it to compile. I am starting to love parts of the IDE though - collapsible code rules, I dunno how I lived without it, from a navigation point of view. I love public members declared with get/set methods. I'm getting used to the way I declare event handlers through the IDE ( give me a chance and I'll get to doing it with delegates, I am sure ).
Overall, I still think I prefer C++, but I'm starting to enjoy C# nonetheless. To bring myself back to the subject, I think interfaces are somewhat of a compiler copout, but I think this survey will show that most people think MI is a good idea, while still hardly ever using it in their own code. I know I tend to chase down language features and play with them in my own time ( with a view to bringing them into my production code if they are useful ), but although I've always known about MI, I've never had a reason to use it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Christian Graus wrote:
I'm getting used to the way I declare event handlers through the IDE ( give me a chance and I'll get to doing it with delegates, I am sure ).
Isnt that funny. With VB, I have been used to using the IDE to create event handlers for longer than I care to remember. Since the first day I used .NET beta 1, I hand wrote every single event handler. I guess years of seeing "Button1_Click" and the like have driven me to it. I really prefer the normal names I can now give them, so I type them myself.
--
David Wengier
Sonork ID: 100.14177 - Ch00k
|
|
|
|
|
Christian Graus wrote:
Why, oh why, does this not work ?
Bitmap b;
Bitmap c = b.Clone();
ICloneable.Clone() returns an object (type Object).
This is where I absolutely hate generic interfaces: I wish there was a way to be able to mark the return value (or anything else, for that matter) as the type that implements the interface. You know - something that can be done with simple C++ templates quite easily.
For instance, ICloneable.Clone would be like this:
public interface ICloneable
{
impl_type Clone();
}
so that any object that claimed to implement ICloneable would have to have a Clone() method that returned an object of that type, not a Clone() that returned an Object.
--
Russell Morris
"WOW! Chocolate - half price!" - Homer Simpson, while in the land of chocolate.
|
|
|
|
|
This is where I absolutely hate generic interfaces: I wish there was a way to be able to mark the return value (or anything else, for that matter) as the type that implements the interface. You know - something that can be done with simple C++ templates quite easily.
For instance, ICloneable.Clone would be like this:
public interface ICloneable
{
impl_type Clone();
}
so that any object that claimed to implement ICloneable would have to have a Clone() method that returned an object of that type, not a Clone() that returned an Object.
The important point on common bases is to ensure substitutability - that's the (real) sense of inheritance! But substitutability gets lost if you do it your way. Two different instantiations of a template are not type compatible. Consider you want to clone a collection of objects for which you don't know the exact types, what would you do?
However, I also hate
these annoying casts. The best solution would be to support two Clone() members - one returning the real class type and one returning the common base.
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
