Comments by "Lepi Doptera" (@lepidoptera9337) on "Object Oriented Programming is a Dirty Rotten Low Down Trick: A Look at How C++ Works" video.

  1. Most of this stuff sounds implementation dependent. I don't think one can rely on any of this.
    4
  2. It depends on your compiler and operating system. And even if the compiler manufacturer claims such a thing or something similar still doesn't mean it's true. If you can hack the MMU, then absolutely everything, everywhere, at all times, is on the table. Don't forget... C/C++ have an asm statement. ;-)
    2
  3. And it comes with a beautiful blonde girlfriend who will always love you for free. Yes, we know. ;-)
    2
  4. Every Turing complete language can do anything (memory and performance permitting). I have written 100% uptime, zero bug programs in C using nothing but global variables that are running in hundreds, if not thousands of industrial products right this moment (I don't have access to the latest sales information of my former employer). It's not the language that is the problem. It is how you use it.
    1
  5. Every professional programmer has occasionally used "tricks like these", at least if he ever grew past an entry level job function. There is nothing particularly unsavory about them. If you know how to use pointers, you can get creative with them. Technically speaking pointers are nothing other than your CPUs indirect addressing modes in a somewhat higher level language construct. Why are they there to begin with? Because CPU instruction sets without them is a half-step towards an insane language like Malbolge: they are almost completely useless in practice except for the most trivial programs.
    1
  6. You can trace back the "why" for OOP to a time when CPUs had very little memory. It allows the compiler to re-use the same function from the base class for all derived functions and therefor minimizes the memory footprint of the program. The idea behind C++ is very well documented by Stroustrup in his book: he was trying to explore how one could move as much effort from run-time to compile-time without giving up as little flexibility as possible. That, too, is basically all about optimization. There are no mysteries here... you can find all of that documented in the literature.
    1
  7. Hehehe... how to screw everybody royally with pointers. I like it. ;-)
    1
  8. Yes, it is so cool that every hacker will thank you for giving them a named pointer to one of their malicious functions. ;-)
    1
  9. C's union type does just that. It's cumbersome, static and error prone, but it can be done.
    1
  10.  @michaellv426  I am simply telling you why unions were written into the C standard. They cover exactly what you are asking for, so it's not like the need for your technique hasn't been recognized even at the language definition level. Of course you can build a library for all of this that does the dynamic memory allocation and access reliably... you can even program the MMU for that purpose, if you are a really good bare metal programmer. I am doing just that on a 32 bit microcontroller just now to avoid having to turn the data cache off while doing DMA from my fast ADCs. That is quite cumbersome because it only works if you have an otherwise static memory layout and you have to take the memory map from the linker output and annotate it back manually into user code. ;-)
    1
  11. You know that, I know that, but your middle manager who had a 30 minutes "OOP for middle manager idiots" introduction to OOP doesn't. And THAT is your real problem.
    1
  12.  @MCRuCr  What's worse is that it doesn't even come with the experience to know that it's not even practical. :-)
    1
  13.  @MCRuCr  Because what you are being paid for are side effect. Functions don't have side effects. Dude, did you ever take CS 101? These are childish questions. ;-)
    1
  14.  @MCRuCr  I didn't just attend the course. I taught it as a TA, kid. Don't feel sorry for yourself now. ;-)
    1
  15. Ummm... no. OOP is a program documentation strategy. Your compiler strips all of it from your code because your CPU does not have an instruction set that knows anything about objects. Records and naming for polymorphism is one way to implement OOP in a language that doesn't offer it as syntactic sugar.
    1
  16. That's correct. All of this is program documentation.
    1