Survey Results

FirstPrev Next

MI the "right" way Ravi Bhavnani17-Mar-02 10:29 Ravi Bhavnani 17-Mar-02 10:29  I often multiply inherit from interface classes (i.e. classes that have pure virtual functions, no data members, and no implemented functions), a la Java. I also don't create inheritance chains that result in diamond patterns. Makes for pretty easy-to-understand and reusable code. /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com Re: MI the "right" way Nemanja Trifunovic17-Mar-02 14:04 Nemanja Trifunovic 17-Mar-02 14:04  I don't like these Java-like class hierarchies. When I have a chance to design an application, I prefer "shallow" hierarchies and heavy use of STL and self-made templates. And the only time I ever use MI is when I work with ATL (almost never). I don't even like the concept very much... I vote pro drink Re: MI the "right" way Tomasz Sowinski18-Mar-02 4:57 Tomasz Sowinski 18-Mar-02 4:57  I agree. This should be the separate option in the poll. Tomasz Sowinski -- http://www.shooltz.com I love it. Giles17-Mar-02 9:09 Giles 17-Mar-02 9:09  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 Re: I love it. Nemanja Trifunovic17-Mar-02 14:06 Nemanja Trifunovic 17-Mar-02 14:06  In this case, I would always prefer containment over MI. Looks cleaner, IMHO. I vote pro drink Re: I love it. Bernhard18-Mar-02 19:14 Bernhard 18-Mar-02 19:14  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. Re: I love it. Giles19-Mar-02 11:29 Giles 19-Mar-02 11:29  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 ATL/C# Christian Graus16-Mar-02 23:19 Christian Graus 16-Mar-02 23:19  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 Re: ATL/C# David Wengier17-Mar-02 2:07 David Wengier 17-Mar-02 2:07  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 Re: ATL/C# Russell Morris17-Mar-02 6:57 Russell Morris 17-Mar-02 6:57  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. Re: ATL/C# Daniel Lohmann17-Mar-02 9:11 Daniel Lohmann 17-Mar-02 9:11  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

Last Visit: 31-Dec-99 18:00     Last Update: 9-May-24 20:24 Refresh ᐊ Prev1234

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.