6 ms·

As a C++ fan, I’d say manual memory control isn’t going anywhere but manually calling malloc and free is ridiculous in 2022 and beyond when `std::unique_ptr` Pr

As a C++ fan, I’d say manual memory control isn’t going anywhere but manually calling malloc and free is ridiculous in 2022 and beyond when `std::unique_ptr` Provides a better abstraction.

jstimpfle 4y ago
I'm a C programmmer and I rarely call malloc() and free(). Most memory is allocated in more global contexts that comprises many smaller allocastions. Such contexts get freed at appropriate, more global points, if at all. Often the implicit releasing of memory on process exit, done by the OS, is sufficient. This way removes the need to do memory management on a small scale. The problem I see personally with unique_ptr is that it's still doing small-scale memory management. It only removes some of the typing. (And for non memory management related tasks, it add significant amount of typing as well, compared to naked pointers).
Xorlev 4y ago
I can't recall the last time I used malloc/free in C++. Even new/delete are rare acquaintances, I use new most often in unit tests. As far as I'm concerned, it's automatic memory management (with lots of control). There's also the other end of the automatic memory management spectrum, garbage collection.
- pjmlp 4y ago
  It is incredible how even something basic like new, which most C predecessors already had, isn't never going to be part of it, manually calculating heap allocations for 50 years.
  - jstimpfle 4y ago
    Maybe you haven't caught up with C best practices. I like C programming and I rarely do malloc()/free().
    - pjmlp 4y ago
      I have, oh boy do I have, on those code bases where we do pentesting or apply SecDevOps security assessment tooling. CVE database is updated almost every week on those "best" practices.
      - jstimpfle 4y ago
        In other words, you're saying that good practices aren't followed widely even though better practices might be available in some of the situations you are seeing? Which would be a fair point, I only don't like the way you walk around what I said.
_gabe_ 4y ago
> manually calling malloc and free is ridiculous in 2022 Why though? I use C++ and I use a variation of malloc and free all the time. The arguments I hear against malloc is: 1. You'll leak memory. This is super easy to solve in literally 300 lines of code or less. Just have a vector of your memory allocations in debug mode. Then call a custom allocator and free function that adds an allocation and removes an allocation from this list. At the end of the program, print out any allocations that are in the list that never got freed. You can use macros to print the exact file and line number that allocated the memory and then fix it very quickly. 2. It's not typesafe. So just use new if you're really concerned with type safety and then overload the operator to get the benefits I described above. 3. It's unsafe. How is this any more unsafe than RAII? Aren't there still the same risks involved? 4. Nullptr exceptions. Once again, same problem with smart pointers. Technically if you're not transferring ownership you should be passing a const reference or a raw pointer rather than a smart pointer anyways. So the end result is the same. Maybe I'm missing some huge thing, but I have not heard any convincing argument for using shared pointers over malloc. (And yes I know you should really use new if you're not using POD because of constructors and all that stuff, but I'm equating new and malloc for brevity). Lastly, I've found that when I use shared pointers I get lulled into a false sense of security and get sloppy. It's a good thing to really think about why you're making a specific memory allocation. Doing it manually forces you to consider whether there's a better option like static local storage or something. In addition, as long as you have a memory tracker implemented like my answer to 1, you never have to spend time worrying about memory. Just today, I forgot to free some memory and I was immediately notified when I ran my program and it printed a warning after I closed it with the leak. I cleaned it up in 5 minutes, end of story. Edit: I forgot to mention, what's the one huge pro to using new/delete or malloc/free over smart pointers? Explicit control over when memory gets allocated and deallocated. If you use smart pointers everywhere, won't you eventually have the same issue as GC? They go out of scope at random points in your programs lifetime, and you get "random" lag spikes from memory cleanup. The whole point of using C++ is to have control over when this stuff happens! If you don't care when it happens, why not use the GC?
- lelanthran 4y ago
  > 1. You'll leak memory. > > This is super easy to solve in literally 300 lines of code or less. Just have a vector of your memory allocations in debug mode. Then call a custom allocator and free function that adds an allocation and removes an allocation from this list. At the end of the program, print out any allocations that are in the list that never got freed. You can use macros to print the exact file and line number that allocated the memory and then fix it very quickly. I've got similar macros for C, but it is still less work to simply use valgrind.
pjmlp 4y ago
It was already ridiculous 40 years ago. When I got introduced to C++ via Turbo C++ 1.0 for MS-DOS in 1993(!), I saw no longer a reason to do that other than being forced to deal with legacy C code. Turbo C++ already came with collection classes, and RAII has been a thing since C++ no longer was named C with Classes. Unfortunately re-education takes generations when a language happens to be copy paste compatible with C.

As a C++ fan, I’d say manual memory control isn’t going anywhere but manually calling malloc and free is ridiculous in 2022 and beyond when `std::unique_ptr` Provides a better abstraction.

jstimpfle 4y ago

I'm a C programmmer and I rarely call malloc() and free(). Most memory is allocated in more global contexts that comprises many smaller allocastions. Such contexts get freed at appropriate, more global points, if at all. Often the implicit releasing of memory on process exit, done by the OS, is sufficient. This way removes the need to do memory management on a small scale. The problem I see personally with unique_ptr is that it's still doing small-scale memory management. It only removes some of the typing. (And for non memory management related tasks, it add significant amount of typing as well, compared to naked pointers).

Xorlev 4y ago

I can't recall the last time I used malloc/free in C++. Even new/delete are rare acquaintances, I use new most often in unit tests. As far as I'm concerned, it's automatic memory management (with lots of control). There's also the other end of the automatic memory management spectrum, garbage collection.

pjmlp 4y ago
It is incredible how even something basic like new, which most C predecessors already had, isn't never going to be part of it, manually calculating heap allocations for 50 years.
- jstimpfle 4y ago
  Maybe you haven't caught up with C best practices. I like C programming and I rarely do malloc()/free().
  - pjmlp 4y ago
    I have, oh boy do I have, on those code bases where we do pentesting or apply SecDevOps security assessment tooling. CVE database is updated almost every week on those "best" practices.
    - jstimpfle 4y ago
      In other words, you're saying that good practices aren't followed widely even though better practices might be available in some of the situations you are seeing? Which would be a fair point, I only don't like the way you walk around what I said.

_gabe_ 4y ago

> manually calling malloc and free is ridiculous in 2022 Why though? I use C++ and I use a variation of malloc and free all the time. The arguments I hear against malloc is: 1. You'll leak memory. This is super easy to solve in literally 300 lines of code or less. Just have a vector of your memory allocations in debug mode. Then call a custom allocator and free function that adds an allocation and removes an allocation from this list. At the end of the program, print out any allocations that are in the list that never got freed. You can use macros to print the exact file and line number that allocated the memory and then fix it very quickly. 2. It's not typesafe. So just use new if you're really concerned with type safety and then overload the operator to get the benefits I described above. 3. It's unsafe. How is this any more unsafe than RAII? Aren't there still the same risks involved? 4. Nullptr exceptions. Once again, same problem with smart pointers. Technically if you're not transferring ownership you should be passing a const reference or a raw pointer rather than a smart pointer anyways. So the end result is the same. Maybe I'm missing some huge thing, but I have not heard any convincing argument for using shared pointers over malloc. (And yes I know you should really use new if you're not using POD because of constructors and all that stuff, but I'm equating new and malloc for brevity). Lastly, I've found that when I use shared pointers I get lulled into a false sense of security and get sloppy. It's a good thing to really think about why you're making a specific memory allocation. Doing it manually forces you to consider whether there's a better option like static local storage or something. In addition, as long as you have a memory tracker implemented like my answer to 1, you never have to spend time worrying about memory. Just today, I forgot to free some memory and I was immediately notified when I ran my program and it printed a warning after I closed it with the leak. I cleaned it up in 5 minutes, end of story. Edit: I forgot to mention, what's the one huge pro to using new/delete or malloc/free over smart pointers? Explicit control over when memory gets allocated and deallocated. If you use smart pointers everywhere, won't you eventually have the same issue as GC? They go out of scope at random points in your programs lifetime, and you get "random" lag spikes from memory cleanup. The whole point of using C++ is to have control over when this stuff happens! If you don't care when it happens, why not use the GC?

lelanthran 4y ago
> 1. You'll leak memory. > > This is super easy to solve in literally 300 lines of code or less. Just have a vector of your memory allocations in debug mode. Then call a custom allocator and free function that adds an allocation and removes an allocation from this list. At the end of the program, print out any allocations that are in the list that never got freed. You can use macros to print the exact file and line number that allocated the memory and then fix it very quickly. I've got similar macros for C, but it is still less work to simply use valgrind.

pjmlp 4y ago

It was already ridiculous 40 years ago. When I got introduced to C++ via Turbo C++ 1.0 for MS-DOS in 1993(!), I saw no longer a reason to do that other than being forced to deal with legacy C code. Turbo C++ already came with collection classes, and RAII has been a thing since C++ no longer was named C with Classes. Unfortunately re-education takes generations when a language happens to be copy paste compatible with C.