Hacker News Reader

I keep hearing how Modern C++ is safe now, and all the dumb UB was just C and legacy unidiomatic C++ code (even recently argued by Bjarne). But std::vector isn't legacy, has easy UB, and there's strong pushback like yours against fixing it.

I don't see Modern C++ ever getting past its safety-third design.

> But std::vector isn't legacy

Oh yes it is. std::vector is hella legacy. That's not a C++11 addition (where "Modern C++" began). And it has all sorts of very-legacy warts like https://en.cppreference.com/w/cpp/container/vector_bool

"Modern C++" added std::array which is what you might be thinking of, but it's much more limited & targets a different usage.

You can't be serious. "Don't use std::vector" is the modern C++ recommendation now?

If it is, it should throw a warning that it's deprecated and have a replacement for it.

I didn't say it wasn't recommended or should be avoided, but it definitely has "legacy" to it. It's not an exclusively "Modern C++" container.

if you are interested in C++ usage ... then you might learn that vector is the only std container that is relevant in modern context.

Because other have not aged well. String is heavily optimized for single short size. Which is almost never a tradeoff that matches your size. Hash things are strictly worse in std. Node based with allocator are not for high performance.

Of course people use additional array types that have short buffer sizes that are needed and such. But vector is probably the last usable std container. Gaming where i work has some extra requirements that exclude even vector but i think i gave you overview.

I use vector all the time, but that doesn't mean it's without any legacy baggage. It didn't get a clean sheet reboot in "Modern C++"

The argument was "this bug exists in pop_back, therefore Modern C++ is a failure" which is nonsense. This pop_back behavior predates "Modern C++", so it cannot be used as a reflection upon the current trends.

It doesn't really matter when you pick. Every era of "Modern C++" has enough unsafety to judge it a failure unless unsafety was the goal.

Take std::span which didn't even exist until C++ 20. Surely that's a modern feature and is safe by design right? Who would add a feature to a language they wanted to be safer five years after Rust and yet make it unsafe by default and even remove safer options "for compatibility" ? Ah yes, WG21.

I was so let down by that. Surely after Microsoft being advocating for span across C++ and C#, based on their Midori experience, C++ would adopt it as safe by default, nope.

The scenarios where there is no option in tooling (C vs C++ as only options), we have to keep using C++, for others, we can replace one domino piece at a time, eventually only those niche scenarios will be left.

I don't follow. What should one use to have safe and efficient dynamically growable arrays in modern C++ if `std::vector` is not considered as modern?

What good is it that a feature is legacy if there's no replacement for it?

Tradeoffs. Everyone has to make them. Modern c++ is safe in the mistakes people often make. Sure there is unsafe stuff, but they are not in things where you would normally do that.

> C++ is about don't pay for what you don't use, and if you don't need the bounds check you shouldn't have to pay for it.

There's a good compromise here though: do the bounds checks by default in operator[], and provide a separate get_i_know_what_im_doing() method that omits the bounds checks, which the programmer can call as an optimization. The fast/unsafe thing needs to be available, but it doesn't need to be the most convenient syntax.

I'm sure there are backwards compatibility problems with making a behavior change like that now, but I'm guessing e.g. CppFront is making that choice from the start? (Edit: sounds like it, if this is up to date: https://github.com/hsutter/cppfront/issues/110#issuecomment-... )

Zero cost means it won't be slower if I had to manually write the bounds checking myself.

> If high performance isn't one of your goals, then why are you writing C++ at all?

Because high performance isn't a synonym for corrupted data.

You're right, though. Those that care about high performance and correct data are better off with Fortran and Chapel.

pop_back is about to invoke a destructor. Remember unlike what the name would suggest, it's not actually returning the element it removed - it's equivalent to erase(end() - 1). So adding a bounds check is going to be inconsequential in nearly any usage. And if you're doing a lot of pop_backs all at once, then if you cared about Real Speed you'd obviously be using the range erase() to do it all in one go.