|
I think likewise.
MI is a nice to have, but comes with too many limitations and caveats (a fattening, teeth destroying, cancer causing, allergenic lemon cake).
As for template metaprogramming mentined in one post, I think its just one more ugly workaround for missing features in C++. I'd rather have no MI and a clean implementations for generic and compile time programming, than an crippled addon sublanguage using MI .
Wolfgang Reichl
|
|
|
|
|
Well said, I couldn't agree more. Its about choice after all. No one forces programmers to use multiple inheritance, and it's not the fault of the language if programmers don't know how to use it properly.
I doubt that we would even bother to pose this question if C# supported multiple inheritance.
Regards,
David
|
|
|
|
|
Supporting any feature is always a good thing when it comes to programming languages.
<center> </center>
|
|
|
|
|
|
|
I would say single inheritance and use of interface leads to simpler design (read easier to maintain when you get back to it 2 years later or it is not you code).
However multiple inherante is required in C++ if you want to used policy based or template metaprogramming.
Yves Tkaczyk
|
|
|
|
|
But the question is this: Is support for inheriting from two or more classes a Good or Bad thing? So to that end I must answer it's a GOOD thing. Now it _depends_ on when it is best adopted, but the support for it should remain.
My rule of thumb is this: If it comes down to a trade between a complex interface and a simple implementation, or a simple interface and a complex implementation, I prefer the latter. When building up to a system, it's always best to encapsulate your code and ring out the design in order to provide a simple and near-bulletproof interface for others to get to. Anyway, that's my 2c.
~Nitron.
ññòòïðïðB A start
|
|
|
|
|
I have found that in my experience, interfaces can account for about 90% of the times that I need/want to use multiple inheretence. But it's still a great feature to have available when you need it.
<flamebait> The only reason I think that C# does not have it is because they figured Java doesn't have it, so C# doesn't need it either. </flamebait>
The generation of random numbers is too important to be left to chance.
|
|
|
|
|
I'll just qoute Bjarne Stroustrup[^]:
People quite correctly say that you don't need multiple inheritance, because anything you can do with multiple inheritance you can also do with single inheritance. You just use the delegation trick I mentioned. Furthermore, you don't need any inheritance at all, because anything you do with single inheritance you can also do without inheritance by forwarding through a class. Actually, you don't need any classes either, because you can do it all with pointers and data structures. But why would you want to do that? When is it convenient to use the language facilities? When would you prefer a workaround? I've seen cases where multiple inheritance is useful, and I've even seen cases where quite complicated multiple inheritance is useful. Generally, I prefer to use the facilities offered by the language to doing workarounds.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
How many moms ever admit that their son is a nasty brat?
Nish
|
|
|
|
|
LOL....I thought the same thing reading that
|
|
|
|
|
But he is right.
|
|
|
|
|
Bjarne Stroustrup didn't invent MI, did he? He just added it to his language.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Mine did.
But I forgave her. Now I'm paying for her retirement... mwahahahaha. *ahem*
Die Freiheit spielt auf allen Geigen
|
|
|
|
|
Sometimes MI is abused, but that does not mean that MI should be abolished. Some people often argue that interfaces can replace MI.
That's simply not true: this is the same as saying that interfaces can replace inheritance! If we believe in MI replacement by interfaces, what's special about the 2nd or 3rd class to derive from? Nothing. So, inheritance should never be allowed (BTW, single inheritance can also be abused): all classes should only be defined by the interfaces it implements.
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
Daniel Turini wrote:
BTW, single inheritance can also be abused
How?
For the record, I voted "depends".
Vikram.
http://www.geocities.com/vpunathambekar
"It's like hitting water with your fist. There's all sorts of motion and noise at impact, and no impression left whatsoever shortly thereafter." — gantww.
|
|
|
|
|
Vikram A Punathambekar wrote:
How?
An interesting point.[^]
I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Quite a good read, Nemanja.
Vikram.
http://www.geocities.com/vpunathambekar
"It's like hitting water with your fist. There's all sorts of motion and noise at impact, and no impression left whatsoever shortly thereafter." — gantww.
|
|
|
|
|
I voted that it's good, I thnk overall that C++ gets it right by giving features based on how they can be used well, and trusting programmers not to use them poorly, but I have to say that in C#, I don't miss it, and in a lot of ways, I like the idea of interfaces more, on a day to day basis.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
I actually voted bad as with most things that C++ provides you. I actually think that people should program towards a programming model and a design rather than towards a language syntax (which is what usually happens when people program in C++).
I know that I will probably be flamed for this but that's my opinion. I use OO in C when nessecary. I've maintained other people's code and in that time I noticed that bad C++ was harder to maintain than bad C. It seems like since it's there people feel that they have to use it. I remember when I first learned C++ and I felt the same way that you must overload all possible operators, you must make everything inherit from 15 classes, etc. If you can get out of that mode of thinking that's good but it seems that even in the most professional environments I have not seen that accomplished! They don't understand OO and think that just using a "class" makes their program "OO".
C++ is also the wrong language for OO since it's a relative of C which is essentially trying to be a portable macro assembler. It hides too much of the details in a language oriented towards being lower level. This is definately one of the downfalls of C++.
|
|
|
|
|
Toby Opferman wrote:
I actually voted bad as with most things that C++ provides you. I actually think that people should program towards a programming model and a design rather than towards a language syntax (which is what usually happens when people program in C++).
Providing a feature doesn't make the feature bad! When the people use the language poorly, it doesn't mean that the language is bad. It isn't for nothing that it is one of the most popular languages in the world.
Toby Opferman wrote:
C++ is also the wrong language for OO since it's a relative of C which is essentially trying to be a portable macro assembler. It hides too much of the details in a language oriented towards being lower level. This is definately one of the downfalls of C++.
C++ is a language on it's own, not just a relative of C. There are people who can program in C and think that they can program in C++ too. This is wrong! A C programmer is not a C++ programmer and vice versa.
I think and believe that I share this thought with many other programmers, that C++ is a perfectly good language for OO programming. It supports many design patterns and you can do magical things with the syntacs. It's more like a language that has something for everything.
C++ is not perfect for everything, but it's good for almost anything.
I also got the blogging virus..[^]
|
|
|
|
|
Popularity is never a judgement call for good or bad! Many examples of superior technology can be sited that were faded out for inferior technology! This goes back as far as Beta vs. VHS! Do you own a Beta? I still laugh when I see that commerical for I think it's Lexus with their headlights that turn the corner when you turn, something that Tucker invented in his car over 50 years ago (Never heard of Tucker's car?? )
I don't agree with C programmer vs. C++ programmer to that extent because it's more about method of programming rather than language syntax. The syntax of the language should not dictate a good design. As an example, anyone who understands procedural programming can program that way in C or C++. I see no reason why they couldn't. Anyone who understands OO should be able to implement the same design in C or C++ (or even assembly)! Also, unfortunately C++ *IS* a superset of C. This does provide low level implementation and attempts to give you higher level constructs at a cost of contradictions in the language architecture.
|
|
|
|
|
Anything is possible but using C and OO in the same sentence makes me wonder about your own knowledge of OO.
Johannes
|
|
|
|
|
Aza wrote:
"Anything is possible but using C and OO in the same sentence makes me wonder about your own knowledge of OO"
First, just so that you know I don't agree with Toby at all. That being said, however, could you please elaborate on what you wrote? Please don't tell me you meant to say that OOP is not possible with C, because this is truly not the case. Sure it's not ideal, but it certainly is possible. If you think otherwise, I highly recommend taking a brief look at the gnumeric[^] source code. Here you will see some very clean OOP.
|
|
|
|
|
Thanks but he actually helped to prove my points
|
|
|
|