Why I hate C++
-
We committed some serious atrocities in the name of efficiency back then. :-O
Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Not as much for speed - more to overcome space limitations. I am too young to have any PDP-8 experience, but an older colleauge told that every single one of the 4094 memory locations - 12 bit data values, 12 bit addresses - was precious. If you had to use a constand, you would always look through the entire binary program to see if the value was already used somewhere, usually as an instruction code, rather that wasting a whole 12 bit word on a duplicate... Yet, with 4096 twelve-bit words, they managed to make a complete newspaper typesetting system (they had hand coded a segment swapping system to read code from a 5 Mbyte (later: 10 Mbyte) disk. Only once did a customer demand all the options, and they couldn't fit all the resident parts into RAM. So they sold that newspaper a 2-CPU solution: When a function in CPU 1 needed to call some code that couldn't fit it, it raised an interrupt signal to CPU 2, the interrupt ID identifying the required function, and went to sleep while CPU 2 was working. Return from the function, in CPU 2, generated an interrupt back to CPU 1, interrupt ID being the result status, so that CPU 1 would wake up and continue its work... I heard about this around 1980, at a time when the PDP-8s had been replaced by PDP-11s serveral years ago, so I guess the story dates to around 1970 ("Computer Techniques A/S", later renamed "Comtec AS", was founded in 1967).
-
Hey! You can do stupid things in any language, if you try hard. Back in my FORTRAN days, I discovered you could write self modifying code with judicious misuse of COMMON ... you can't do it now, but back then? Handy... :cringe:
Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
When structured languages (like Algol, Pascal etc) came onto the scene, we used to say that "You can program FORTRAN in any language". Around 1980. a professor in the Mecanical Engineering Department and eager FORTRAN coder wrote an article for the newsletter from the University Computing Center, with a fierce attack on this silly idea of indenting loops and conditional blocks (when programming in these new languages). Like in a book: All text is left justified, starting at the margin. You can't make it consistent anyway, if you, say, have a labeled statement in that indented part: Any jump to that label would break the idea of this indented block being a coherent unit... Or something like that. I believe I still have that newsletter in my archives. I really should dig it up to see if he had any valid arguments at all. He probably didn't. I can't imagine what they would be.
-
There may be reasons to dislike C++, but surely this one is a programmer induced problem. :~
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
One reason to dislike C(++) is that it provides excellent tools for a programmer to make a mess in a very simple way. In the earlier days, you could see quite a few horrible cases of poiner arithmetic - and the programmers were proud of it, proud of how they could do things that were impossible in toy languages like Pascal that gave you a slap on your fingers for just addressing outside the array limits, and introducing artificial differences between a pointer to the start of an array and the array itself. Every knowledgeabler person should know that they are the same! Fortunately, intricate pointer arithmetic is no longer the way to prove your skills. OO techniques has been more popular for that for at least 15-20 years. Virtual functions and overrides may be terribly abused, too, and what is the big difference bewtween operator overloading and virtual functions, at the conceptual level?
-
OriginalGriff wrote:
if you try hard.
And the lazies use VB.
I remember "PEEK(address)" and "POKE address, value" as dearly loved functions, but that was in the DOS days. If my memory is correct, it never made it into Visual Basic, though. (I guess it would be more or less meaningless, too, considering the memory management of Windows.)
-
What you should really be hating on is the abhorrent coder not the language. That's like hating the hammer that was used to build the crappy shack you live in.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Oh I do, dont worry, but C++ allows this kind of crap to happen.
-
Oh I do, dont worry, but C++ allows this kind of crap to happen.
so does every other language that is of any use beyond kiddie crap.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
so does every other language that is of any use beyond kiddie crap.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
C++ positively invite this kind of ridiculousness. Give a man a hammer, and everything is a nail. Give a language feature x and every one has to abuse it. C++ has more of these than any other language I have used, ADA, VB, Java, Small Talk, Prolog and of course C, way more.
-
As our program manager said once: After object-oriented design course every programmer writes only singleton classes.
-
some_array[value];
[] is over ridden and is commented as // find element matching _Keyval or insert with default mapped Which actually means 'insert it at the end of the list'. Why not a function called 'add_to_map_at_end'? Christ I hate C++ sometimes, it is so up its arse pointless at times.
As our program manager said once: After object-oriented design course every programmer writes only singleton classes.
-
Any 20 years old code base saw its sharse of clowns, especially the self-taught enthusiast that follow any "guru" blindly. I had such a colleague, luckily he went out slamming the door... unfortunately he had 10 years to make damages. I recently had to update some of his code and I was happy that he was no longer in my proxymity or I would be writing this from behind bars.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
I have come across some right howlers in this code base. Anyway, C++, of all the languages I have used, from ADA, to Prolog, through VB and Java, allows this kind of sillyness. So it is for that that I condemn it. And personally I dont see that OO is a massive benefit over a procedural language except in specific instances. And in fact it is often worse. Particularly in control code, code that is not data centric, but process centric.
-
While I agree with your statement, std::map implements this very [] operator overload as described. Actually that comment is a nice addition. Would I implement something like that though? probably not.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
Quite, this is in the map object. Obscene is isnt it, that such an abortion as this is used so widely.
-
One reason to dislike C(++) is that it provides excellent tools for a programmer to make a mess in a very simple way. In the earlier days, you could see quite a few horrible cases of poiner arithmetic - and the programmers were proud of it, proud of how they could do things that were impossible in toy languages like Pascal that gave you a slap on your fingers for just addressing outside the array limits, and introducing artificial differences between a pointer to the start of an array and the array itself. Every knowledgeabler person should know that they are the same! Fortunately, intricate pointer arithmetic is no longer the way to prove your skills. OO techniques has been more popular for that for at least 15-20 years. Virtual functions and overrides may be terribly abused, too, and what is the big difference bewtween operator overloading and virtual functions, at the conceptual level?
Member 7989122 wrote:
the programmers were proud of it,
This is a problem in any language, and exactly what I am getting at here.l C++ give bedroom nerd programmers who think complexity is good the chance to do this. Real engineers dont.
Member 7989122 wrote:
what is the big difference bewtween operator overloading and virtual functions
Huge. An overridden function is subclass specialisation. An operator overload is supposed to *improve* the operator's functionality specifically for that class. In fact without overloading that operator might be dangerous. Take the classic 'class contains an allocated pointer' and not overriding the '=' operator. The class being copied to needs new memory allocating, and the contents copied to it. This is good. This is logical. Using [] to add a member to the end of an array is just stupid.
-
-1 for blaming an excellent tool when the real problem lies with (s)he who uses it...
History is the joke the living play on the dead.
Actually this is in the STL library, the map object, pretty much a part of C++. So yeah, it sucks.
-
Actually this is in the STL library, the map object, pretty much a part of C++. So yeah, it sucks.
I've used STL extensively for decades and std::map is not the problem as mentioned in your OP. As you pointed out, the overridden function was incorrectly implemented so again, the fault lies with the developer and not the language. Technically speaking, STL is a library implemented in C++. So your OP would better have been title "Why I hate STL" (where you probably would have found a much more accepting audience). Cheers, Ian
History is the joke the living play on the dead.
-
I've used STL extensively for decades and std::map is not the problem as mentioned in your OP. As you pointed out, the overridden function was incorrectly implemented so again, the fault lies with the developer and not the language. Technically speaking, STL is a library implemented in C++. So your OP would better have been title "Why I hate STL" (where you probably would have found a much more accepting audience). Cheers, Ian
History is the joke the living play on the dead.
-
I have come across some right howlers in this code base. Anyway, C++, of all the languages I have used, from ADA, to Prolog, through VB and Java, allows this kind of sillyness. So it is for that that I condemn it. And personally I dont see that OO is a massive benefit over a procedural language except in specific instances. And in fact it is often worse. Particularly in control code, code that is not data centric, but process centric.
I beg to differ, there are always pieces of information in a process which are data-centric, and applying OO correctly will break up processes in subprocess objects that are easier to isolate, replicate, store, observe and even parallelize. I do intermix procedural and OO because pure OOP more often than not introduces complexity trying to fit square pegs in round holes, but that's precisely why I like C++ and not the oter OOP languages: it's C, but with 100% OO support.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
I beg to differ, there are always pieces of information in a process which are data-centric, and applying OO correctly will break up processes in subprocess objects that are easier to isolate, replicate, store, observe and even parallelize. I do intermix procedural and OO because pure OOP more often than not introduces complexity trying to fit square pegs in round holes, but that's precisely why I like C++ and not the oter OOP languages: it's C, but with 100% OO support.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
there are always pieces of information in a process which are data-centric
Often not with drivers. In fact many are pure process and have no data of their own. They have states, flags, plenty of that, but no data.
-
den2k88 wrote:
there are always pieces of information in a process which are data-centric
Often not with drivers. In fact many are pure process and have no data of their own. They have states, flags, plenty of that, but no data.
Munchies_Matt wrote:
Often not with drivers.
More like never, I concur. Drivers, firmware and heavy computing procedures get no benefit and mostly troubles at all from an internal OO implementation. As consumers of OOP (object as parameters), or external implementation (i.e. the driver is encapsulated in an object) they might get some benefits though.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
Munchies_Matt wrote:
Often not with drivers.
More like never, I concur. Drivers, firmware and heavy computing procedures get no benefit and mostly troubles at all from an internal OO implementation. As consumers of OOP (object as parameters), or external implementation (i.e. the driver is encapsulated in an object) they might get some benefits though.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
Probably why MSFT dont authorise C++ in the kernel, it isnt worth it. OF course when I see classes with get/set functions I chuckle. Just what is the point of pretending it is OO? :)
-
Member 7989122 wrote:
the programmers were proud of it,
This is a problem in any language, and exactly what I am getting at here.l C++ give bedroom nerd programmers who think complexity is good the chance to do this. Real engineers dont.
Member 7989122 wrote:
what is the big difference bewtween operator overloading and virtual functions
Huge. An overridden function is subclass specialisation. An operator overload is supposed to *improve* the operator's functionality specifically for that class. In fact without overloading that operator might be dangerous. Take the classic 'class contains an allocated pointer' and not overriding the '=' operator. The class being copied to needs new memory allocating, and the contents copied to it. This is good. This is logical. Using [] to add a member to the end of an array is just stupid.
Munchies_Matt wrote:
This is a problem in any language, and exactly what I am getting at here.l C++ give bedroom nerd programmers who think complexity is good the chance to do this.
Sure every programming language has facilities that may be abused. Some has more such "options" than others. Take pointer arithmetic: You can do that in C an C++, but not in C#. Adressing out of array bounds (deliberately or accidentally) you can do in C, but not in Pascal. Silent fall through in a switch statement you can do in C, but neither in Pascal (no fallthrough at all) or C# (explicit). Dividing 'B' by 2 to get an exclamation mark: Allowed in C, not in properly typed languages. Fortran had its 'facilities', such as common blocks and GOTOs. Actually, most languages do provide labels and GOTO, but I don't think I have programmed a single GOTO in my 35 years as a programmer, and I have hardly ever come across code that uses is. At least not after that 101 Elementary Programming as as freshman at the U, which was taught in Fortran (the next year they switched to Pascal). Other languages, too, can be abused. But languages do vary a lot in how much effort it takes to get to those misbehaviour features (I think you could do pointer arithmetic tricks in "unsafe" C#, and many Pascal compilers lets you turn off the array index checking). It also varies a lot what is commonly accepted programming style in textbook examples, widely distributed open source code etc. For C, you see things like (usually unsafe) pointer arithmetic, or pro forma arrays of length 0 because they will be arbitrarily indexed out of bounds etc. Fortran examples could have lots of labels and GOTOs, and so could Basic, but you would rarely if ever see a GOTO in a Pascal or C# textbook. You may be a "clever" C programmer able to "prove" that you can do the same nasty things in a more strictly typed language, a language lacking explicit pointers, etc. "So that other language is just as bad as C". No, it isn't, if you have to be an expert and do special tricks that noone does by accident. In C (/C++) you might do things by accident or delibrately, and a bystander will be unable to distinguish between them. You need not do anything to "allow" neither switch fallthrough, out-of-bounds indexing or pointer arithmetic. Many other languages are far more helpful, trying to guide you not to do silly things. C is a "you asked for it, you got it"-language.
