Why I hate C++
-
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; -
Margaret Hamilton (scientist) - Wikipedia[^]
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.
-
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.
Don't blame the language or its standard library for your inability to RTFM. From std::map::operator[] - cppreference.com: operator[] is non-const because it inserts the key if it doesn't exist.
-
Don't blame the language or its standard library for your inability to RTFM. From std::map::operator[] - cppreference.com: operator[] is non-const because it inserts the key if it doesn't exist.
No shit it inserts it, I just said that. RTFOT FFS.
-
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.
Why I don't hate the C++ language I have found it to be overly arcane with its syntax...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
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.
-
If you had ever had the experience of building a large software project using non-OO code, you would sing a different tune.
You can build a large project from procedural code just as well, it all depends on the architecture you design. Look at the WIndows kernel. All built in C (with a bit of assembler in the HAL)
-
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.
Yes, I still keep the AT&T C++ book on my desk. A slim volume describing a nice language which was an (IMO) elegant OO extension to 'C'. Now you can look at valid C++ syntax that looks like a cat walked across the keyboard. They seem to be trying to put every feature of every other language into C++ syntax and comprehensibility be damned.
-
You can build a large project from procedural code just as well, it all depends on the architecture you design. Look at the WIndows kernel. All built in C (with a bit of assembler in the HAL)
And have you, personally, built a million-line code-base in purely procedural code? In C, perhaps? If you have done so, and have done the same using an object-oriented language, then you have standing to dismiss object oriented programming as no better than procedural. Merely asserting that it is possible is not a very strong claim. Pointing to 30-year-old code like the Windows Kernel, that was developed before the broad availability of OO languages is meaningless.
-
And have you, personally, built a million-line code-base in purely procedural code? In C, perhaps? If you have done so, and have done the same using an object-oriented language, then you have standing to dismiss object oriented programming as no better than procedural. Merely asserting that it is possible is not a very strong claim. Pointing to 30-year-old code like the Windows Kernel, that was developed before the broad availability of OO languages is meaningless.
Ah, so because I havnt done it it isnt true. OK, gotcha! ;)
SeattleC++ wrote:
30-year-old code like the Windows Kernel,
:laugh: :laugh: :laugh: NT is old, 2000 was modified to include PnP and power handling. Windows 10 is even more recent.
-
Why reference the code and what is it you are requesting?
History is the joke the living play on the dead.
-
Seems to be something like that. Anyway, reading my_array[value]; and that is it, is damn confusiing!
