That's the problem with the C++ ecosystem, it is actually many vastly different ecosystems mashed together. It's impossible to find a "C++ developer" because there is no agreed upon "one C++ style". It seems what you're looking for is a "C++ developer who likes to write the same C++ style as myself" ;)
> It seems what you're looking for is a "C++ developer who likes to write the same C++ style as myself" ;)
No, I'm perfectly content with someone writing C++ in a different style.
What I'm not content with is someone who uses old code without a technical reason why. C style arrays, for example, are 100% inferior to std::array. Old loops with indices are maybe 80% (off the cuff guesstimate) inferior to ranged-for. There's absolutely no reason whatsoever to use `delete` in any C++ code that doesn't directly handle allocations (and so, very esoteric), and simlarly for `new`. But I keep seeing these things (and many other examples) show up in newly-written C++ code from "experienced" developers. Maybe 90% of the time they'll fix their code when I point out the modern solution and what problems the modern solution solves, and the last 10% of the time ends up in a technical argument about the merit of the old code (and that's fine as long as there is a technical merit for it).
> Are the advantages of std::array over C arrays big enough to add 8kloc to each compilation unit though?
I say yes, absolutely. C style arrays are _very easy_ to get wrong in many ways. Three just off the top of my head:
- iterating using a size_t instead of an iterator
- calculating the size of the array (and often using a preprocessor macro to do it)
- leaving things uninitialized
So a std::array provides iterators and works with a ranged-for loop. The only reason to use a size_t is if you truly need an index number (and I would argue: use `std::distance()` instead).
A std::array provides a `size()` giving the total number of objects in it. It also provides the type, so you can do sizeof(type) * array.size() -- though that's still error prone.
A std::array ensures that objects are correctly initialized.
And, if you still need to dangerously decay the data to a pointer, you can use .data() to grab that pointer.
> A range-checked std::array replacement can probably be written in a few dozen lines of code.
Can you provide an example?
> That's the problem with all C++ stdlib headers, they are incredibly overengineered for what they bring to the table.
I would argue that the standard library isn't overengineered. It's engineered for more than just your use case. Just because code "is there" doesn't mean that code makes it into your product. Pay for what you use, don't pay for what you don't use.
Last time I needed to write `delete` I was either fixing some low level garbage code that was super old or writing a smart pointer for a case not handled by the standard library. Either way it was so long ago that I really can't remember which.
Complaints about delete aren't about part of common modern C++, if they aren't from subject matter experts aren't well structured complaints.
Last time you needed to, sure. The problem is that if you find out how to do dynamic memory allocation, there will be tons of resources pointing at new/delete. Parts of the language that all the experts agree are terrible are just sitting there, poking out behind a shiny facade, waiting to scratch the unwary.
How is that not the case for any language that lets experts get at the gory details what is the alternative?
Even in languages like Ruby this problem exists. Superficially, Ruby has a decent garbage collector and you never need to dereference a pointer. In practice as soon as it gets slow you hit an optimization stopping point and need to write an extension in C. Then you have all this mess again except with all the baggage another whole language brings to the table and none of the sheltering of a type system.
At some point you just have trust software devs to use the tools.
holy mother of god! I used C++ around 2000 for some old projects. When new and delete where the object oriented "equivalent" for malloc() and free(). So, if you don't use that, what do you use in 2022 C++?
`std::make_unique()`, `std::make_shared()`, or another function that wraps `new` and `delete` into an RAII type (commonly called a smart pointer) so that you, the developer, worry less about explicit memory management.
And the standard smart pointers are perfectly extensible enough to wrap things allocated from C libraries (I like to pick on opengl's glalloc() and glfree(), though malloc() and free() are acceptable to pick on too), C-style `FILE` pointers, or even memory-mapped things from `mmap()`
I would also point out that even in 2000, `std::auto_ptr` existed. So even in 2000 you probably should not have been using `new` and `delete`.
By the GP's opinion, you use the stl classes that implement RAII for you.
What is, obviously, only one way to do it, with its up and downsides. Granted that the upsides are much more numerous than the downsides, but there is a reason it's not the only option available.
