Why C++ sucks
-
Vikram Punathambekar wrote: who argued very well as to what is/was wrong with C++. That paper is bigger than this. I assume it's a well written paper..? Of course, there are deficiencies in C++. Bjarne & co knows this. I think that's the reason why they are working on a new revision of C++. But I still think it's the best language for real world applications right now. I like Lisp and it's dialects better than C++ from a pure language point of view. However, how much support is there for creating seamless applications in those languages? How much support and documentation is there? Vikram Punathambekar wrote: If I can find the link... Please do! It might be an interesting read, given that it's objective and to the point and not full of personal oppinions. :) -- Now we live in a world of uncertainty Fear is the key - to what you want to be You don't get a say, the majority gets it's way You're outnumbered by the bastards till the day you die...
Jörgen Sigvardsson wrote: I like Lisp ... How much support and documentation is there? I think you'd be surprised. :) The Association Of Lisp Users[^] Tools and libraries[^] Companies that use Lisp[^] Implementations (free and commercial)[^] J
"You can get anything you want at Alice's Restaurant."
-
No, it doesn't. IMO, it's the coolest language ever. :cool: But this guy does have a few good points: http://www.nothings.org/computer/cpp.html Come to think of it, C# seems to be better than C++, tho' I'm just learning C#. Sorry if it's a repost.
Vikram. ----------------------------- My soon-to-be-updated site KI klike KDE kand kuse kit, kbut KI kmust kadmit, kstarting kall knames kwith K kis ksilly. KI khope kthey kwill kgive kup kthis kwhole kscheme ksoon kand kcome kup kwith kreal knames. pI vThink aHungarian nNotation vIs iA aWonderful nThing cAnd pEveryone avShould vUse pIt aAll dThe nTime, adNo nMatter pWhat dThe nContext, adEven adWhen vSpeaking. -
Jörgen Sigvardsson wrote: I like Lisp ... How much support and documentation is there? I think you'd be surprised. :) The Association Of Lisp Users[^] Tools and libraries[^] Companies that use Lisp[^] Implementations (free and commercial)[^] J
"You can get anything you want at Alice's Restaurant."
I know.. but compare with C++. How many Lisp articles can you find on CP? :) -- Now we live in a world of uncertainty Fear is the key - to what you want to be You don't get a say, the majority gets it's way You're outnumbered by the bastards till the day you die...
-
That's kind of what I got from it. He has some good arguments, but I disagree with most of them. The one good point he does make is that the whole header file /CPP file split-up is quite a nuisance. C# actually gets this part right - no header files necessary. :) But the problem with most of his arguments is that C++ programmers, in general, prefer having power and flexibilty to having safety nets. "When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
Navin wrote: The one good point he does make is that the whole header file /CPP file split-up is quite a nuisance. I actually disagree. I can't think of anything worse than checking on the declaration of a function (for argument types etc.) and having to scroll through an entire source file to find it. Header files with just the declaration make it much shorter and easier. Ryan Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact" -
Navin wrote: The one good point he does make is that the whole header file /CPP file split-up is quite a nuisance. C# actually gets this part right - no header files necessary. I actually find this good as it separates the interface from the implementation. I wish there was some way to move the private data and methods into the implementation file though. Yes, I know you can do it by using the "pimpl" idiom, but I'd like to see language support for it. Navin wrote: But the problem with most of his arguments is that C++ programmers, in general, prefer having power and flexibilty to having safety nets. All he seems to be upset with is the syntax. Syntax which he doesn't really know. He states in the article: Something like that--I'm not very familiar with C++ operator overloading. That single line decimated his credibility :) Something like that - my ass! I bet he loves Perl. -- Now we live in a world of uncertainty Fear is the key - to what you want to be You don't get a say, the majority gets it's way You're outnumbered by the bastards till the day you die...
Jörgen Sigvardsson wrote: I actually find this good as it separates the interface from the implementation. I agree. I find it so incredibly annoying that in C# the definition (or interface, as you put it) and the implementation are so intwined. I can't get a good overview of the class when methods go on and on and on for pages. Regions suck, in my opinion. I spend more time fousing around (hey, a word for pseudodictionary.com) with opening and closing regions--they just get in the way. I end up writing everything as an interface just to avoid implementation! (just kidding.) :-D Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files" -
Jörgen Sigvardsson wrote: I actually find this good as it separates the interface from the implementation. I agree. I find it so incredibly annoying that in C# the definition (or interface, as you put it) and the implementation are so intwined. I can't get a good overview of the class when methods go on and on and on for pages. Regions suck, in my opinion. I spend more time fousing around (hey, a word for pseudodictionary.com) with opening and closing regions--they just get in the way. I end up writing everything as an interface just to avoid implementation! (just kidding.) :-D Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"Marc Clifton wrote: I find it so incredibly annoying that in C# the definition (or interface, as you put it) and the implementation are so intwined. I can't get a good overview of the class when methods go on and on and on for pages. I find it kind of annoying, too, but I generally use the Class Scout to get an overview - and it works quite well. :)
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
That's kind of what I got from it. He has some good arguments, but I disagree with most of them. The one good point he does make is that the whole header file /CPP file split-up is quite a nuisance. C# actually gets this part right - no header files necessary. :) But the problem with most of his arguments is that C++ programmers, in general, prefer having power and flexibilty to having safety nets. "When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
the whole header file /CPP file split-up is fundamental to OOD. One of the main objectives (other than reusability) of OOD is to separate the data from the interface; with C++ this is both physical (the file splits) and implemented (the class). The fact that C# doesn't support this (and in doing so saying.. eh.. to hell with OOD, lets go back to spaghetti) is just another reason why C# (and Java for that matter .. what real purpose does it serve) should be destroyed, and never mentioned again.
-
Jörgen Sigvardsson wrote: I actually find this good as it separates the interface from the implementation. I agree. I find it so incredibly annoying that in C# the definition (or interface, as you put it) and the implementation are so intwined. I can't get a good overview of the class when methods go on and on and on for pages. Regions suck, in my opinion. I spend more time fousing around (hey, a word for pseudodictionary.com) with opening and closing regions--they just get in the way. I end up writing everything as an interface just to avoid implementation! (just kidding.) :-D Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"Marc Clifton wrote: I can't get a good overview of the class when methods go on and on and on for pages. If they run on and on an on, then maybe it is time for a little refactoring ;) Marc Clifton wrote: I can't get a good overview of the class when methods go on and on and on for pages. Regions suck, in my opinion. I love regions and was hoping they would do something like that for the HTML editor so I can collapse everything between matchings tags. Maybe you just have not got the hang of them. When I first started with C# I was glad to see the header go. Could not stand them, always trying to figure out which one to use and in what order. Don't forget the times you include one header for COM and it blows your code with redefinitions. Not to mention the versioning problems! Then the sad news came to light, I still have to select my libraries with "Using" unless I want to always specify the full path so I am not completely out of the woods. There have been several times I have pulled a little code from the usenet where the Using lines were not included and it contains a class or two that I have not used before and have to dig out the library to which they belong. Not a big problem (a lot better than the header mess from the past). It would be great to have it notice when a class is not known and automatically parse the .NET libraries and any custom ones I have built looking for the correct match and automatically generate them or in some method allow me to override if I wish but not require my input by default! Rocky Moore <><
-
the whole header file /CPP file split-up is fundamental to OOD. One of the main objectives (other than reusability) of OOD is to separate the data from the interface; with C++ this is both physical (the file splits) and implemented (the class). The fact that C# doesn't support this (and in doing so saying.. eh.. to hell with OOD, lets go back to spaghetti) is just another reason why C# (and Java for that matter .. what real purpose does it serve) should be destroyed, and never mentioned again.
ROK_RShadow wrote: the whole header file /CPP file split-up is fundamental to OOD A very good point. Exposing only the declarations is fundamental to OOP; the user should not be bothered by the details in the implementation. Maintaining separate files is a PITA, though...
"The Lion shall lie down with the Lamb;
but the Lamb will not get much sleep..."
Lazarus Long -
I will agree with him to this extent - most C++ code I have seen in my life should have been written in straight C. From my experience, few programmers know how to take advantage of the additional complexity C++ brings to the table and merely end up writing bizarre C code with classes. That is one reason I've become interested in C#. However, having used it a while, I don't really see that it solves the complexity issue any more than Java did. It just reformats the complexity while giving up much (though certainly not all) of the power of C++. Conceptually, issues such as reflection and attributes are just as easy to get wrong in a design as anything C++ allows. And don't even get me started on garbage collection. What a frigging joke. Give me old fashioned destructors any day for a cleanly designed application! "More capitalism, please..."
Excellent, Stan! Esp the garbage collection stuff.
Vikram. ----------------------------- My soon-to-be-updated site KI klike KDE kand kuse kit, kbut KI kmust kadmit, kstarting kall knames kwith K kis ksilly. KI khope kthey kwill kgive kup kthis kwhole kscheme ksoon kand kcome kup kwith kreal knames. pI vThink aHungarian nNotation vIs iA aWonderful nThing cAnd pEveryone avShould vUse pIt aAll dThe nTime, adNo nMatter pWhat dThe nContext, adEven adWhen vSpeaking. -
Navin wrote: The one good point he does make is that the whole header file /CPP file split-up is quite a nuisance. C# actually gets this part right - no header files necessary. I actually find this good as it separates the interface from the implementation. I wish there was some way to move the private data and methods into the implementation file though. Yes, I know you can do it by using the "pimpl" idiom, but I'd like to see language support for it. Navin wrote: But the problem with most of his arguments is that C++ programmers, in general, prefer having power and flexibilty to having safety nets. All he seems to be upset with is the syntax. Syntax which he doesn't really know. He states in the article: Something like that--I'm not very familiar with C++ operator overloading. That single line decimated his credibility :) Something like that - my ass! I bet he loves Perl. -- Now we live in a world of uncertainty Fear is the key - to what you want to be You don't get a say, the majority gets it's way You're outnumbered by the bastards till the day you die...
Jörgen Sigvardsson wrote: I actually find this good as it separates the interface from the implementation. Yes. I myself would rarely implement a c++ function in the class definition. If I want it inline I will define it outside the class definition. I do this because it is much harder to read the interface when the 10 pages of implementation are interspersed. Jörgen Sigvardsson wrote: "pimpl" idiom What is that? John
-
Jörgen Sigvardsson wrote: I actually find this good as it separates the interface from the implementation. Yes. I myself would rarely implement a c++ function in the class definition. If I want it inline I will define it outside the class definition. I do this because it is much harder to read the interface when the 10 pages of implementation are interspersed. Jörgen Sigvardsson wrote: "pimpl" idiom What is that? John
John M. Drescher wrote: What is that? pimpl = pointer to implementation. in .h-file:
struct MyInstanceData; // forward ref
class SomeClass {
private:
MyInstanceData* pimpl;
public:
SomeClass();
~SomeClass();
void Operation();
};in .cpp-file:
struct MyInstance {
int x;
};SomeClass::SomeClass() : pimpl(new MyInstanceData) { }
SomeClass::~SomeClass() { delete pimpl; }
void SomeClass::Operation() {
pimpl->x = 2;
...
}This way you can change the instance data without breaking the interface, and thus your client code will not have to be recompiled. This technique is also sometimes called "compiler firewall". :) -- Now we live in a world of uncertainty Fear is the key - to what you want to be You don't get a say, the majority gets it's way You're outnumbered by the bastards till the day you die...
-
John M. Drescher wrote: What is that? pimpl = pointer to implementation. in .h-file:
struct MyInstanceData; // forward ref
class SomeClass {
private:
MyInstanceData* pimpl;
public:
SomeClass();
~SomeClass();
void Operation();
};in .cpp-file:
struct MyInstance {
int x;
};SomeClass::SomeClass() : pimpl(new MyInstanceData) { }
SomeClass::~SomeClass() { delete pimpl; }
void SomeClass::Operation() {
pimpl->x = 2;
...
}This way you can change the instance data without breaking the interface, and thus your client code will not have to be recompiled. This technique is also sometimes called "compiler firewall". :) -- Now we live in a world of uncertainty Fear is the key - to what you want to be You don't get a say, the majority gets it's way You're outnumbered by the bastards till the day you die...
I see. Thanks for the explanation. John