|
Quite, this is in the map object. Obscene is isnt it, that such an abortion as this is used so widely.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
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.)
|
|
|
|
|
OriginalGriff wrote: FORTRAN
OriginalGriff wrote: self modifying code
OriginalGriff wrote: misuse of COMMON
What. The. ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) .
Software Zen: delete this;
|
|
|
|
|
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 ... 
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Interesting times
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
We committed some serious atrocities in the name of efficiency back then. 
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).
|
|
|
|
|
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 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;
|
|
|
|
|
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.
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
|
Interesting bit of history, thanks.
|
|
|
|
|
Suddenly a wild overloaded operator appears...
Try stand up comedy. 
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Operator overloading can result in some of the worst abuses of the language. Usually the overloads are intuitive and reduce your typing but they can be easily taken beyond that into the realm of the absurd.
I recently wrote my own little vector and matrix library for 3D graphics and there are some overloads in it that I think are sensible. For example, I have a point class that stores three coordinates and it has an [] overload that returns the coordinate at that index. This lets you write point[index] instead of point.coordinates[index]. That makes sense to me and I would not want it to do anything else behind the scene.
The example you cite is beyond what I consider to be intuitive. It would be best to have explicit methods to implement that functionality instead of an overridden operator in my opinion.
I don't hate C++ at all. What I hate is when people try to get cute with it as in your example. I don't think it enhances the readability or maintainability of the code at all if one has to figure out what is going with a statement like that.
|
|
|
|
|
-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.
|
|
|
|
|
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.
modified 15-Jul-18 13:14pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
