>
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.