std::string_view make_view(const std::string& in)
{
return in;
}
Is an absolute minefield, as is: std::vector<int> vec = {1, 2};
std::span<int> sp = vec;
vec.push-back(3);
These are using safe, modern C++ techniques that are designed to help catch errors, but are still absolutely lethal.Basically all the ways that ranges::view can go wrong and even trigger UB.
Finally, the address sanitizer helps you with that, however I wonder how many actually do use sanitizers?
Overall, I agree that something could have been done to prevent temporary objects at all. From my newbie point over view, it seems the standard API has the tendency to be lower level rather than ergonomic: it's up to you to know how to use it (and fuck up with it). Quite sad, because that kind of makes the language more difficult to use than it should be. I don't have enough knowledge, and I wonder if making the constructor on (const std::string&&) private/deleted would have been enough to prevent it?
The second case I guess the principle is similar. Not sure if the sanitizer finds the error there, but still scary.
In a short, C++ approach is to give any object a "blank state" which it must turn into after the value was moved from it. It is an attempt to track state "value was moved out" dynamically. Rust tracks it statically by treating a variable whose value was moved out as uninitialized variable and ensuring that are no accesses to uninitialized variables.
It's a different approach, and definitely less efficient than compile-time checking, but if your program is not too complex I think it's OK. Especially if you use such sanitizers at the unit test level.
I don't have enough experience to say if it actually works in general though, because as usual everything on paper is always working.
I use C++ to write general backend servers / web apps among the other things. Not a single one ever deployed without passing sanitizer tests.
Not that my code would ever look like the examples above. I personally consider modern C++ safe enough for decent level programmer.
Of course I can not guarantee safety buy my servers run non stop servicing tens of thousands of client for months between updates without any hick-ups.
I looked at Rust to see if it can offer me any practical advantage vs modern C++ for what I do and so far did not see anything convincing enough.
EDIT: Just to know: clang sanitizers or anything else?
I understand that this is rather unique position but this is what I wanted, worked for and had managed to achieve. I mostly design and create products from start to finish for my clients. Been on my own for 20+ years already.
BTW. I doubt that Rust or any language for that matter can be a cure from shitty programmers. Some help sure but they'll manage to fuck things up regardless on a different level.
I am quite happy no longer to do code review of such deliveries.
Hence why I only use C++ on personal projects.
This is the problem with naked pointers in the first case. We've had I don't know how many years of experience to tell us that relying on programmers to not make mistakes is a terrible idea. If documenting requirements fixed these issues we would still just be able to write C.
The problem with sanitizers is they're an opt-in addition, and like static analysis tools they have a tendency to be have some false positives, which causes people to distrust then and say "but I'd never make that mistake". Compiling with asan enabled would cause our CI build times to double, as we'd need to build with and without (and we have 4 configurations over 3 platforms. My previous project had 3 configurations over 9 platforms).