|
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
|
|
|
|
|
As I said anything is possible (and gnumeric is an excellent example of that). You can basically do OOP with any imperative language that does not make them OO languages (one could even argue that C++ is not an OO language since it does not enforce OO).
Johannes
|
|
|
|
|
Toby Opferman wrote:
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
Because someone can doesn't mean they should! Besides that if you design towards a certain pattern, why not use the right language to enforce that pattern?
Toby Opferman wrote:
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.
I don't know where you heard that, but you can read this[^] and see that C++ started as a superset of C, but nowdays is a complete different language that supports the same syntax. Example: in C you can do a typecast like this (SomeVar* pVar = (SomeVar*) pOtherVar;) You can do that in C++ too, but it is fundamentally wrong.
I also got the blogging virus..[^]
|
|
|
|
|
I don't think that you understand the big picture. C++ comes from C and as such has carried over a lot of C's traits. "Technically" speaking you just don't like the word "superset", but again that's just grammar. However if you compare C and C++'s base programming model they are much more simmilar rooted than say Ada compared with Assembly or Prolog compared with Pascal.
You even gave a perfect of example of what I'm talking about! That is the problem, C++ tries to be a higher level langauge however it contradicts itself because of it's origins in C. This brings over some of the "lower level" capabilities like you posted that are technically not morally correct in higher level languages (and a lot of times are not supported). That code will work in C or C++, however you mentioned my exact point that it's now considered "fundamentally wrong". This is my point of C++, it attempts to provide high level constructs however it's base is a lower level language. This is where the contradiction lies.
|
|
|
|
|
C++ is *NOT* a superset of C. Here is some valid C code, but invalid C++ code:
<br />
enum A<br />
{<br />
X,<br />
Y,<br />
Z<br />
};<br />
<br />
enum a<br />
{<br />
x,<br />
y,<br />
z<br />
};<br />
<br />
A someFunc()<br />
{<br />
a a_=x;<br />
<br />
return a; <br />
}
|
|
|
|
|
Actually that code wouldn't compile in C or C++. You have just proved u know neither language!
I think you wanted to do this:
enum A
{
X,
Y,
Z
};
enum a
{
x,
y,
z
};
enum A someFunc()
{
enum a a_=x;
return a_;
}
And this doesn't really prove anything beyond C++ has stricter type checking than C. This does not change the overall picture. We can point out hundereds of differences, we can even throw in K&R C style and compare it to ANSI C style, the little differences don't really mean much. I'm talking about the overall picture that everyone agrees with, C++ came from C and thus at some level they have similarities. Those similarities are what I am refering to, not little compiler differences.
|
|
|
|
|
touchee! Yes, I forgot the enum keyword. Shame on me. Yes, C++ does have stricter type-checking. But still, C++ is NOT a superset of C. Please see this website: Incompatibilities Between ISO C and ISO C++[^].
I understand your point that C++ came from C, but that doesn't mean that C programmers can program C++ -- or vice versa. My mistake of forgetting the enum keyword is an example. Yes, I have programmed in both languages, but as you can see, I forgot one important C rule. And a long time ago, as a C programmer going to C++, I hated the strict type checking on enums because it ruined some things I was used to (like enumerating bit-masks).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
