Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> int* array = new int[n];

that's why you do `auto array = std::make_unique<int[]>(n);` (or `auto array = std::make_unique_default_init<int[]>(n);` if you don't believe in your compiler's ability to optimize redundant writes)

Also, this "memory leak" is only an issue on pre-1990 operating systems as "current" operating systems have no trouble reclaiming unfreed memory - you loose exactly the same amount of memory in both cases : zero.

So no, don't litter noexcept everywhere, especially for that, this article just does not make sense.



> Also, this "memory leak" is only an issue on pre-1990 operating systems as "current" operating systems have no trouble reclaiming unfreed memory

Not just that, the OS is faster to reclaim the unfreed memory than if the program was cleaning it up.


It's only true if the program is about to exit, for long running programs like daemons, ``memory leak`` is still a thing.


Also, make_unique<int[]> would not be UB: The post matches new[] with delete and does not even care about valgrind mentioning this.


And critical embedded OSes running on IoT devices, but who cares about that. /s


> And critical embedded OSes running on IoT devices, but who cares about that.

are there current non-homegrown RTOSes that do not reclaim memory ? I know that QNX does.


Probably not, but not having to depend on such factors is good engineering and security best practices.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: