|
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.
|
|
|
|
|
Ok, that makes sense. I like the phrase "diamond of death" - I shall remember that one!
Joel Holdsworth
Wanna give me a job this summer?
Check out my online CV and project history[^]
|
|
|
|
|
AT the .NET Launch conference, the fellow that gave the keynote claimed that only a few people actually know how to design languages, compilers, etc. for Multiple Inheritence. They ommitted the feature for that reason.
<signature>
It's good to live,
Josef Wainz
Software Developer
|
|
|
|
|
Well, they do have MI in C++, so I'm sure they could have asked the C++ guys something 
Regards,
Alexandru Savescu
|
|
|
|
|
Alexandru Savescu wrote:
they could have asked the C++ guys something
Or Eiffel guys, or CLOS guys, or even Python guys.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
That seems to show that a few people actually know how to design languages, compilers, etc. [period]
In my mind, C# is more of a product from Microsoft than an language per say.
That is, of course, just an opinion.
I like MI because I want the language to allow me to express myself as much as I can, and there are not many interesting relationship apart from "is-a" that defines inheritance in the first place, and you find that quickly, modeling "real world objects" in OO diagram, you quickly find use for multiple inheritance!
Lets map the "problem", not the "solution" (Problem is the real world object, Solution is the "interface" coming from the computer science bag of tricks)
|
|
|
|
|
It can be a good thing but in the wrong hands it can make a developers life a nightmare.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
I couldn't agree with you more!
Jerry
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
