this post was submitted on 11 Apr 2024
27 points (93.5% liked)
C++
1763 readers
1 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't really see how it's daunting enough to avoid mentioning. You can replace a C array on the stack by just swapping it with std::array. Yes, it can depend on the project structure, but that's equivalently true for any STL container the author recommended.
I think it's a good call not to mention them because they are irrelevant given the topic. If your code base and/or the consumers of your code base are using C-style arrays for input and/or output, it's hardly helpful to suggest changing all your interfaces to use another data type. It's outright impossible if you're dealing with extern C interfaces.
Depending on what OP is trying to do; swapping out the internal implementation with
arrayand then decaying to the old terrible.data()'pointer that could be anything' when having to cross interfaces and boundaries could be a winner. At least their own stuff gets the benefits of known size, bounds checking and being a real class, and the code improvements can be done a little at a time. I'd almost consider this the main use case forarray- unless for some reason you just absolutely must allocate on the stack, thenvectoris better in every way.Same argument for smart pointers. If some legacy code returns an owning pointer, then get it wrapped up as soon as possible. At least your own code won't leak.