4 ms·

"Manual memory management" means more than just explicit free(3). If you have to create a destructor, and a class for it to sit in, just to make sure some bit o

"Manual memory management" means more than just explicit free(3). If you have to create a destructor, and a class for it to sit in, just to make sure some bit of memory gets freed, that's manual memory management. The falsehoods here are yours.

ncmncm 5y ago
Self-deception in the terminally confused is always sad to see. It is extremely rare, nowadays, to "create a destructor" to manage memory. The destructors generated automatically from templates in the Standard Library suffice. Creating classes is just programming. So, no, that is not manual memory management.
- notacoward 5y ago
  You're confusing implicit with automatic. That's the best illustration of self-deception and "terminally confused" in this thread. If programmers have to think about when something truly goes out of the last scope it'll be in (sometimes not obvious when it's put into and taken out of containers and passed between callbacks) then it's not automatic. If they have to think about whether they can use/pass a reference and be sure it won't outlive the object itself, it's not automatic. These have been issues in every C++ codebase I've seen, so even if I were personally able to create a codebase without those issues it wouldn't change anything. It also doesn't make a difference if you're so accustomed to a certain set of ownership rules that the time you spend thinking about them is very small. It's still not zero, and other programmers who are less inured to the mess still exist. It's OK that these issues exist - as you say it's just programming - but don't delude yourself into thinking that's automatic memory management. It's implicit, but it's not automatic and that means it's (at least partly) manual. When you say you don't use manual memory management but then say you let standard-library templates handle it, that's a contradiction and tantamount to a lie.
  - ncmncm 5y ago
    Repeat that enough, you may come to believe it.

ncmncm 5y ago

Self-deception in the terminally confused is always sad to see. It is extremely rare, nowadays, to "create a destructor" to manage memory. The destructors generated automatically from templates in the Standard Library suffice. Creating classes is just programming. So, no, that is not manual memory management.

notacoward 5y ago
You're confusing implicit with automatic. That's the best illustration of self-deception and "terminally confused" in this thread. If programmers have to think about when something truly goes out of the last scope it'll be in (sometimes not obvious when it's put into and taken out of containers and passed between callbacks) then it's not automatic. If they have to think about whether they can use/pass a reference and be sure it won't outlive the object itself, it's not automatic. These have been issues in every C++ codebase I've seen, so even if I were personally able to create a codebase without those issues it wouldn't change anything. It also doesn't make a difference if you're so accustomed to a certain set of ownership rules that the time you spend thinking about them is very small. It's still not zero, and other programmers who are less inured to the mess still exist. It's OK that these issues exist - as you say it's just programming - but don't delude yourself into thinking that's automatic memory management. It's implicit, but it's not automatic and that means it's (at least partly) manual. When you say you don't use manual memory management but then say you let standard-library templates handle it, that's a contradiction and tantamount to a lie.
- ncmncm 5y ago
  Repeat that enough, you may come to believe it.