4 ms·
> 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'
by jcelerier 7y ago
> 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.
- shakna 7y ago> 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.
- _rtld_global_ro 7y agoIt's only true if the program is about to exit, for long running programs like daemons, ``memory leak`` is still a thing.
- tos1 7y agoAlso, make_unique<int[]> would not be UB: The post matches new[] with delete and does not even care about valgrind mentioning this.
- pjmlp 7y agoAnd critical embedded OSes running on IoT devices, but who cares about that. /s