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.

> I'm just a hobbyist, but "new" and especially "malloc" are not "right way of doing C++"

How do you think the std::vector is implemented under the hood ?

I think what he's saying is that using `std::vector` is better than using pointers and `malloc` from the point of view of doing simple things. (Simple is not the right term but can't think of a better word). I mean 80% of times.

With that line of argumentation, why not use sbrk() or poke the syscall directly? :) I'd say prefer the safest, highest-level of abstraction that you can get away with. Which would generally mean std::vector over new/malloc.

I have no problem with the use of std::vector (in 90% of cases it is all you need), my problem is with the new trend of shunning any use of new/delete or naked pointers in modern C++.

Sure, dogma is not very useful. But when people ask "what should I use" saying "well, there are valid cases for everything" (like someone else in the thread basically did) does not help much either.

Sure but they are implemented by C++ specialists that work on this code all the time. I'd trust them to use malloc more correctly and bug free than I'd ever trust myself to do. As long as we're not talking embedded here I'd rather rely on work already done by experts than reinvent the wheel, perhaps poorly.

Umm, no. A vector allows you to dynamically change the length of an array. If you need it, then you pretty much need a vector (or some other kind of smart container). Otherwise, there's no reason to prefer a vector to C-style array.

Also shared_ptr's make the ownership relation harder to understand. (Also there's additional synchronization cost for copying pointers.) Of course there are situations where you need them, but in general, I think it's better to avoid them.

Your parent poster was probably referring to std::array.