|
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).
|
|
|
|
|
But you do have to admit that the differences are not earth shattering. If you would have compiled that code, saw the error, I'm sure you would not throw your arms in the air and say "I can't do this!" you would probably have just put "enum" in front So while there are differences in syntax and usability I don't think they are that great that you couldn't just fix your code to compile. Obviously C++ has more keywords that perhaps a C programmer has not been exposed to (class for example) but if they understand OO I don't think it would be impossible for them to learn.
I know I joked about forgetting enum on the front but in reality I don't think it's that big of a deal and it's easily fixed. It doesn't change the logic of the program.
|
|
|
|
|
I couldn't disagree with you more.
Regards,
Alexandru Savescu
|
|
|
|
|
Toby Opferman wrote:
It hides too much of the details in a language oriented towards being lower level. This is definately one of the downfalls of C++.
In C++, you can be as high or low level as you want. Therefore C++ is ultimately better than C.
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.
Not languages are OO, people are.
|
|
|
|
|
>> In C++, you can be as high or low level as you want. Therefore C++ is ultimately better than C.
Disagree, it's worse. Because you are mixed you cannot pick when to be high and when to be low! Go use java.
>> Not languages are OO, people are.
I agree with this statement. I really meant to say it's the wrong language for high level constructs.
|
|
|
|
|
I agree that in the wrong situation or in the wrong MI can cause nightmares, but is programmer error MI's fault. It is really, really, REALLY powerful if used properly and I don't think because there's the opportunity to screw things up is good enough reason to condemn it.
Besides, I'm very biased. I think every feature of C++ is the best. C++ > everything.
|
|
|
|
|
I've always wondered why there's no support for multiple inheritance in C#. Has been removed for performance reasons? or just due to dumning down?
Joel Holdsworth
Wanna give me a job this summer?
Check out my online CV and project history[^]
|
|
|
|
|
Everything derives from object in C# hierarchies. Therefore, if MI was allowed you would automatically have a "diamond of death" each time you use it. Unless of course, all inheritance were virtual, but that would be too costly.
I think C# really misses not a full-fledged MI, but some form of mix-ins.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
