Why I hate C++
-
-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.
-
Quite, this is in the map object. Obscene is isnt it, that such an abortion as this is used so widely.
-
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:
what is the big difference bewtween operator overloading and virtual functions
Huge
Implementationwise: Yeah, probably, in most compilers. Not necessarily. On an abstract level, for the user: Not very much. Both mechanisms provide similarly identified operations to be interpreted differently for different types/classes. The intention is that the implementations for various types shall have similar semantics, but it doesn't have to be. In my "childhood engineering years" (i.e. after graduation) I was programming in a Pascal-inspired proprietary language which allowed a left argument as well as right arguments, and a single right argument didn't require parentheses. Furthermore, the identifier syntax for functions allowed a big selection of special characters and Functions could be overloaded. "+" was a perfectly fine name for a function that could take MyComplex left and right arguments, or a MyComplex left and (float: re, float: im) right arguments. Conceptually, predefined "+" functions for int+int, int+float, ... were just like user functions. (Obviously, the compiler compiled wellknown builtin functions like these quite differently from those that were actually user written.) I made a function library for all assignment functions (like C's =, ++, -- and so on) for struct types, that updated the reference count and triggered whenever an object was freed with more than one reference to it, or the reference count went to 0 in a non-free operation. This was for development/debugging only; for production work the library (with its noticable overhead) was omitted and the "simple" assignments took their place, as the default implmentation for the assignment functions. This language wasn't a fullblown OO language; it didn't have a 'virtual function' concept. Yet having worked with overloaded "AddToList(MyComplex)" and overloaded "MyComplex + MyComplex", using identical mechanisms for the two, certainly blurs the distinction between overloaded operators and overloaded functions. Adding virtual functions on top of that doesn't make a very large conceptual difference.
-
COMMON allowed you to share variables between different blocks of code: much like a C++ global variable being accessible from different classes. But ... it wasn't type checked, so you could declare a float and then use COMMON to import it as a 7 dimensional array of BYTE values if you wanted. Because the array bounds checking worked on the data as declared in the COMMON statement with no actual reference back to the original variable, you could happily use it to access any location in your memory space. And because there was no physical separation between code and data segments (flat memory model in those days) your code was not in a "read only partition" as code is now. Provided you understood machine code you could revise your program while it was running ... :laugh:
Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Oh, I'm more than old enough to know how it worked. I'm just appalled at the notion of doing it in FORTRAN. I've written my own self-modifying code a couple of times, although not in the last 25 years or so. I can see where .NET could let you write self-generating code, but that's a kettle of different piscus, as it were.
Software Zen:
delete this; -
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.
Member 7989122 wrote:
Mechanical Engineering Department and eager FORTRAN coder
Found your problem.
Software Zen:
delete this; -
Oh, I'm more than old enough to know how it worked. I'm just appalled at the notion of doing it in FORTRAN. I've written my own self-modifying code a couple of times, although not in the last 25 years or so. I can see where .NET could let you write self-generating code, but that's a kettle of different piscus, as it were.
Software Zen:
delete this;I'm just glad I never had the opportunity to do it in COBOL
Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
I'm just glad I never had the opportunity to do it in COBOL
Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
X| I have two claims to fame in my career: I've never written an ECO(*) (Engineering Change Order), and I've never learned COBOL. (*) A document used within my company that describes how to build a product. It's incredibly complicated, and for software it's completely over-engineered.
Software Zen:
delete this; -
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.
Wait.. what? Are you talking about std::array, std::list or std::map? Don't mix their terminology, please. I'm guessing you're dealing with a map. And I'm guessing the some_map[value] is initializing a KV-pair with value as key (hella confusing name, btw) and a default value (of type V). Typically, this is done before some algorithm which relies on a particular key existing / values to be initialised to keep its complexity low. Nothing wrong with that, except the very awful variable names. Something like this would make more sense:
std::map some_map = new std::map()
// init specific keys
some_map[new KeyType("key 1")]; // adds key to some_map, in no guaranteed order, with a default ValueType
KeyType key = new KeyType("key 2");
some_map[key] = new ValueType(); // same as above, but more verbose// do some algorithm that relies on initialized keys / values
-
I'm just glad I never had the opportunity to do it in COBOL
Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Most oldtimers know the Ken Thompson Turing Award lecture "Reflections on trusting trust" (and the youngers really should be introduced to it!) For a few years after this paper was published (1984), various writers expanded on the idea. One of the articles in my basement archive discusses how this compiler trojan could be implemented in the backend, code generating part, of a compiler suite such as gcc. It would then apply to all the compilers using that backend - Cobol is mentioned as an example, even though the malicious code never existed in Cobol form. This article discusses how the trojan could avoid detection, e.g. by propagating only to executables of a certain minimum size so that the size of the trojan code would be a tiny little fraction. It also discusses how a parse tree could be recognized as a compiler being compiled, and how the trojan could added at the parse tree level before code generation, so that it would spread even to the early (language dependent) compiler stages, not just the back end. This would not exactly be self modifying code, but it illustrates that even Cobol certainly isn't safe for malware.
-
Wait.. what? Are you talking about std::array, std::list or std::map? Don't mix their terminology, please. I'm guessing you're dealing with a map. And I'm guessing the some_map[value] is initializing a KV-pair with value as key (hella confusing name, btw) and a default value (of type V). Typically, this is done before some algorithm which relies on a particular key existing / values to be initialised to keep its complexity low. Nothing wrong with that, except the very awful variable names. Something like this would make more sense:
std::map some_map = new std::map()
// init specific keys
some_map[new KeyType("key 1")]; // adds key to some_map, in no guaranteed order, with a default ValueType
KeyType key = new KeyType("key 2");
some_map[key] = new ValueType(); // same as above, but more verbose// do some algorithm that relies on initialized keys / values
Seems to be something like that. Anyway, reading my_array[value]; and that is it, is damn confusiing!
-
It's not C++, it's the programmers. I use C++ and don't do that s**t.
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
You are pretty close to the perfect answer.... C++ is as sensible or as stupid and daft as you want it to be. Unfortunately not helped by the C++ ISO bods adding more and more different ways to make it more complicated without adding very much to real C++ users. The idea of less is more is lost on them. Could do with minimum C++ with a lot of the bad and new stuff removed. As for the Template library - great functionality but let down by the ludicrous syntax etc.
-
Member 7989122 wrote:
Mechanical Engineering Department and eager FORTRAN coder
Found your problem.
Software Zen:
delete this; -
But without those type of people we would never have put a man on the moon. Remember, it takes people with real jobs to get real things done.
Margaret Hamilton (scientist) - Wikipedia[^]
Software Zen:
delete this;
