4 ms·

Do you have any examples? std::launder fixes an issue that has existed since C++98.

tialaramex 5y ago
In C++ 03 they realise their pointer (inherited from C) is awful. Do they fix it? No, they add a new type named std::auto_ptr which is "smart". Thanks to operator overloading it can behave like the existing pointer. Kind of. std::auto_ptr is pretty bad, and so in C++ 11 they deprecate auto_ptr and introduced std::shared_ptr and std::unique_ptr so now finally their language has halfway usable pointers, with these unwieldy names and some odd semantics you just have to get used to. C-style pointers remain all of: Simpler to use by virtue of their terse syntax, still necessary, and unsafe. std::auto_ptr still exists forever, but is officially deprecated. At first C lacks strings, promoting string literals to a strange array with an extra zero value in it. Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted, but it provides no enforcement of the most obvious expectation you have - C++ allows a string_view to outlive the underlying string, causing Undefined Behaviour. In C++ 20 you get to use ranged behaviour, and, that extra zero value bites you hard because of course you didn't mean the zero value but in C++ that's "part" of your string. They also, finally, decide that UTF-8 might be a good idea and define yet another type of string to mean UTF-8 encoded, about five years after everybody who matters was of course encoding strings as UTF-8.
- gpderetta 5y ago
  Shared_ptr and unique_ptr are not replacement for raw C pointers. And the reason they are not blessed with language syntax is because user can and often do implement their own, so those two library types are not particularly special.
  - BenFrantzDale 5y ago
    Agreed. And a huge strength of C++ is that you can write low-level classes like these and have them be fully performant and have reasonable native-feeling syntax. Almost no other languages provide that.
  - IiydAbITMvJkqKf 5y ago
    Specifically, both shared_ptr and unique_ptr are owning pointers. Using plain old pointers for non-owning variables is idiomatic.
    - tialaramex 5y ago
      Non-owning pointers are a genuinely useful tool, but as a tool they're more welding torch than hammer, if that's what you needed it's really what you needed - but most often it probably isn't what you needed at all and will cause more harm than good. So it's strange to provide them with stuff like terse built-in syntax, while not providing anything similar for the thing people will want all the time, ownership. Result: The Right Thing™ is harder to do and wastes visual space compared to the Wrong Thing. A "correct" program ends up full of boilerplate just to get what you'd obviously want.
- nemetroid 5y ago
  > std::auto_ptr still exists forever, but is officially deprecated. std::auto_ptr is fully removed since C++17. I agree with most of your comment, but I think it reinforces the grandparent's point. The warts of std::string and null terminated strings are not "problems introduced by C++'s other recent additions".
- saagarjha 5y ago
  > Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted Such as what? std::string_view represents exactly one thing, and that’s a slice into a string with a lifetime longer than it. That’s basically it. There aren’t really and other additional feature to it, so I feel like you may be confused as to what it does.
  - tialaramex 5y ago
    Yes, it's "just" a slice. Which is in fact one of the most obvious things you would want, and yet was not afforded by std::string.
    - capitalsigma 5y ago
      A lot of your criticism makes sense. I don't follow this one, though: `string_view` is *by definition` non-owning. Was non-owning the whole thing you wanted? If so, why are you surprised by lifetime issues? If non-owning isn't your main desire, what's wrong with `std::string`?
      - tialaramex 5y ago
        Probably in C++ context this feels unreasonable but I'm arguing that C++ is wrong here. It's OK for the language to enforce that the lifetime of the string underpinning a slice must equal or exceed the lifetime of the slice despite the slice not "owning" the string. In 2011 there probably wasn't a mainstream non-GC language doing that. C++ would have been innovating here, and maybe C++ in 2011 didn't want to be innovating. By 2017 when C++ 17 introduces std::string_view it's behind the curve, this is not an exciting new feature, it's a weak imitation of what everybody else was already doing better.

In C++ 03 they realise their pointer (inherited from C) is awful. Do they fix it? No, they add a new type named std::auto_ptr which is "smart". Thanks to operator overloading it can behave like the existing pointer. Kind of. std::auto_ptr is pretty bad, and so in C++ 11 they deprecate auto_ptr and introduced std::shared_ptr and std::unique_ptr so now finally their language has halfway usable pointers, with these unwieldy names and some odd semantics you just have to get used to. C-style pointers remain all of: Simpler to use by virtue of their terse syntax, still necessary, and unsafe. std::auto_ptr still exists forever, but is officially deprecated. At first C lacks strings, promoting string literals to a strange array with an extra zero value in it. Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted, but it provides no enforcement of the most obvious expectation you have - C++ allows a string_view to outlive the underlying string, causing Undefined Behaviour. In C++ 20 you get to use ranged behaviour, and, that extra zero value bites you hard because of course you didn't mean the zero value but in C++ that's "part" of your string. They also, finally, decide that UTF-8 might be a good idea and define yet another type of string to mean UTF-8 encoded, about five years after everybody who matters was of course encoding strings as UTF-8.

gpderetta 5y ago
Shared_ptr and unique_ptr are not replacement for raw C pointers. And the reason they are not blessed with language syntax is because user can and often do implement their own, so those two library types are not particularly special.
- BenFrantzDale 5y ago
  Agreed. And a huge strength of C++ is that you can write low-level classes like these and have them be fully performant and have reasonable native-feeling syntax. Almost no other languages provide that.
- IiydAbITMvJkqKf 5y ago
  Specifically, both shared_ptr and unique_ptr are owning pointers. Using plain old pointers for non-owning variables is idiomatic.
  - tialaramex 5y ago
    Non-owning pointers are a genuinely useful tool, but as a tool they're more welding torch than hammer, if that's what you needed it's really what you needed - but most often it probably isn't what you needed at all and will cause more harm than good. So it's strange to provide them with stuff like terse built-in syntax, while not providing anything similar for the thing people will want all the time, ownership. Result: The Right Thing™ is harder to do and wastes visual space compared to the Wrong Thing. A "correct" program ends up full of boilerplate just to get what you'd obviously want.
nemetroid 5y ago
> std::auto_ptr still exists forever, but is officially deprecated. std::auto_ptr is fully removed since C++17. I agree with most of your comment, but I think it reinforces the grandparent's point. The warts of std::string and null terminated strings are not "problems introduced by C++'s other recent additions".
saagarjha 5y ago
> Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted Such as what? std::string_view represents exactly one thing, and that’s a slice into a string with a lifetime longer than it. That’s basically it. There aren’t really and other additional feature to it, so I feel like you may be confused as to what it does.
- tialaramex 5y ago
  Yes, it's "just" a slice. Which is in fact one of the most obvious things you would want, and yet was not afforded by std::string.
  - capitalsigma 5y ago
    A lot of your criticism makes sense. I don't follow this one, though: `string_view` is *by definition` non-owning. Was non-owning the whole thing you wanted? If so, why are you surprised by lifetime issues? If non-owning isn't your main desire, what's wrong with `std::string`?
    - tialaramex 5y ago
      Probably in C++ context this feels unreasonable but I'm arguing that C++ is wrong here. It's OK for the language to enforce that the lifetime of the string underpinning a slice must equal or exceed the lifetime of the slice despite the slice not "owning" the string. In 2011 there probably wasn't a mainstream non-GC language doing that. C++ would have been innovating here, and maybe C++ in 2011 didn't want to be innovating. By 2017 when C++ 17 introduces std::string_view it's behind the curve, this is not an exciting new feature, it's a weak imitation of what everybody else was already doing better.