6 ms·
One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type
by nialv7 2y ago
One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type of y, instead it can be anything you choose…
This is like implicit type conversion on steroids. And all this because C++ lacks the basic safety features to avoid dangling pointers.
Stop using C++ already!
- thegrim33 2y agoSmart pointers were added to the language 14 years ago. You're free to use old C++ with raw pointers and manual memory management, risking dangling pointers, or use modern C++, which provides smart pointers to avoid those issues.
- tsimionescu 2y agoAnd yet most if not all of the standard library keeps using pointer or reference arguments, not the new smart pointers that would actually document the ownership semantics.
- a_t48 2y agoMost arguments to standard library calls don't need to take ownership over memory, using a raw pointer or (const) reference is correct. Generally - smart pointers to designate ownership, raw pointers to "borrow".
- tsimionescu 2y agoIf a function takes a raw pointer, you need to check the docs to know if it is taking ownership or not. There is no general rule that applies to the whole of std that functions taking raw pointers assume that they are borrowing the value. And even if you could assume that pointer parameters represent borrowing, they are definitely not guaranteed to represent scoped borrowing: the function could store them somewhere, and then you end up with other issues. So shared_ptr is the only solution if you care about safety to represent a borrowed pointer. And of that's too costly, but the std designers did care about safety, they could have introduced a std::borrowed_ptr<T> that is just a wrapper around T* but that is used uniformly in all std functions that borrow a pointer and guarantee not to store it.
- shultays 2y agoWhat are the examples to std functions that uses a raw pointer but does not borrow/expects pointer to be valid past the function call?
- tempodox 2y agoThe fact that you have to ask that question makes GP's point. There's no way to tell that from looking at a function's interface at present.
- shultays 2y agoWhy? If all standard functions that take no ownership/keep references are using raw pointers then it behaves same as user code/C++ devs expect: if a function is taking a pointer then it claims no ownership. You take a look at standard_function(T*) and see raw pointer and then can assume it is not taking ownership or keeping references
- account42 2y agoThe fact that you don't have an answer make's GP's point. This isn't actually a problem with the standard library because the semantics are clear.
- jeroenhd 2y ago> lacks the basic safety features to avoid dangling pointers It doesn't. Unfortunately, C++ programmers choose not to use basic safety features for performance reasons (or aesthetics, or disagreement with the idea that a language should take into account that a programmer might make a mistake, but at least performance is a good one), but C++ actually has quite a few tricks to prevent the memory management issues that cause C/C++ bugs. Using modern C++ safety features won't completely prevent bugs and memory issues, just like using Rust won't, but the mess that causes the worst bugs is the result of a choice, not the language itself.
- aiono 2y ago> the mess that causes the worst bugs is the result of a choice, not the language itself. Even the creator of the language admitted that "just write better code bro" approach doesn't work.
- tsimionescu 2y agoHas he? He at least used to be the biggest proponent of it, "just follow these standards and development practices that I had to meticulously develop for the US military, that no tool can automatically check, and you'll be fine!".
- aiono 2y agoYes, it writes in the slide 6 of presentation that Bjarne himself created: https://github.com/CppCon/CppCon2023/blob/main/Presentations/Plenary_Delivering_Safe_Cpp.pdf https://github.com/CppCon/CppCon2023/blob/main/Presentations...
- tsimionescu 2y agoTell that to the designers of the C++ standard library, and the new features being added. They're the ones that keep adding new features that depend on references and pointers instead of std::shared_ptr or std::unique_ptr.
- 2y ago
- f1shy 2y agoI would not say stop using it. But just stick to the really needed features, and stop adding more features every 3 years. Nobody can keep up, not the developers, not the compilers... is just insane.
- pjmlp 2y agoFirst we need to rewrite the likes of LLVM, GCC, V8, CUDA,... into something else. Which is not going to happen in our lifetime, even the mighty Rust depends on LLVM for its reference implementation.
- lifthrasiir 2y agoStop producing a new C++ code as much as possible, then. It doesn't help to nitpick the weakest possible interpretation without acknowledging as such.
- pjmlp 2y agoWhich by definition means no more improvements to LLVM then, as one example, and by consequence no improvements on Rust backend.
- justinrubek 2y ago"as much as possible" nobody said anything about entirely stopping.