Re:How fast can you allocate a large block of memory in C++?
by ipmifatwa on Thursday January 16, 2020 @12:38AM
(#22061963)
Sometimes your just need a buffer for a syscall. Newing a buffer is canonical and unique_ptr isn’t free enough to use in the most performance sensitive contexts.
[ Parent
| on HN ]
Re:How fast can you allocate a large block of memory in C++?
by a_t48 on Thursday January 16, 2020 @01:35AM
(#22062167)
Can you give an example of unique_ptr being too heavy?
Re:How fast can you allocate a large block of memory in C++?
by fnbr on Thursday January 16, 2020 @01:56AM
(#22062220)
I worked with a team which used raw pointers instead of unique_ptr as they use more memory (twice as much, I think). The core data structure was a tree, and the tree was several hundred GB in size. So they were doing whatever they could to shave off memory.
Re:How fast can you allocate a large block of memory in C++?
by tcbawo on Thursday January 16, 2020 @07:31AM
(#22063874)
Unique pointers imply ownership of the underlying memory. If you have multiple references to the same data, or in your case a tree, it might make sense to use raw pointers (or references) to access the tree data. It would not make sense to grant ownership of the same memory to two unique_ptr, or make copies of data unnecessarily.
Re:How fast can you allocate a large block of memory in C++?
by inetknght on Thursday January 16, 2020 @10:06AM
(#22065144)
In that case, you'd have something like `std::vector` or `std::unique_ptr` which owns the actual allocation (and governs the scoping and therefore deallocation), while using `vector.data()` or `unique_ptr.get()` to pass around an unowned pointer. All raw pointers can then be considered to be unowned by convention.
Re:How fast can you allocate a large block of memory in C++?
by de_watcher on Thursday January 16, 2020 @02:15AM
(#22062291)
Without a custom deleter unique_ptr should have zero overhead.