Re:C++17 Is Here: Interview with Herb Sutter
by smitherfield on Tuesday October 24, 2017 @11:30AM
(#15542288)
I'd pretty strongly disagree with the notion that stack or static-allocated arrays (especially `std::array`) aren't idiomatic C++; rather it's (unnecessarily) allocating everything on the heap that's the anti-pattern, since it defeats the whole purpose (fast, fine-grained, deterministic memory model) of using C++ in the first place. (And implies lots of memory leaks and global state).
Also, `new`/`delete` aren't unidiomatic when strictly adhering to RAII and
- Writing exception-safe code (with the `new (std::nothrow) T` form).
- Writing custom smart pointers or data structures, or high-performance containers (especially with C++17 aligned `new`/`delete` and C++14 sized `delete`).
- Using memory pools (with placement `new`/`delete`).
`[std::]malloc`/`[std::]free` aren't necessarily unidiomatic either, such as
- When using a C API (or one in pre-standard C++ or a third language) which is incompatible with `new`/`delete`.
- When you need `[std::]realloc`, and for whatever reason a `std::vector` isn't an acceptable substitute.
- In embedded or other environments that don't provide a STL.
Also, `new`/`delete` aren't unidiomatic when strictly adhering to RAII and
- Writing exception-safe code (with the `new (std::nothrow) T` form).
- Writing custom smart pointers or data structures, or high-performance containers (especially with C++17 aligned `new`/`delete` and C++14 sized `delete`).
- Using memory pools (with placement `new`/`delete`).
`[std::]malloc`/`[std::]free` aren't necessarily unidiomatic either, such as
- When using a C API (or one in pre-standard C++ or a third language) which is incompatible with `new`/`delete`.
- When you need `[std::]realloc`, and for whatever reason a `std::vector` isn't an acceptable substitute.
- In embedded or other environments that don't provide a STL.