Modern C++ Won't Save Us • Hacker News Board

Re: Modern C++ Won't Save Us

#391

Post by steveklabnik » Thu, Apr 25, 2019, 7:53 PM UTC

noselasd wrote: post #390

simias wrote: post #248

Earlier quoted context omitted.

This is solved in Rust by letting you test and unwrap at the same time: if let Some(obj) = my_optional { do_stuff(obj); } >However if the dereferencing, my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed So basically that turns C++ optional types into fancy linter hints which won't actually…

C++ gives you all the options as usual. do_stuff(my_optional.value()) Is also safe, it throws if the value is absent, the safety check is performed behind the scenes. But people might not want to throw an exception, so if (my_optional) do_stuff(*my_optional); Must also be allowed. The consequence is someone can also just do do_stuff(*my_optional) No safety check is done and you get undefined behavior if the value is…

Yes, you have to use if let, not let. That code would be a compiler error. (Specifically, a “non-exhaustive pattern” error.)

Re: Modern C++ Won't Save Us

#392

Post by leshow » Fri, Apr 26, 2019, 1:45 PM UTC

favorited wrote: post #67

0815test wrote: post #24

Earlier quoted context omitted.

Yes, AIUI Swift does not ensure memory safety for concurrent code like Rust does. You have to expressly opt-in to concurrency-safety, and it's not checked by the compiler. Go definitely has this issue, which is admittedly bizarre for a language that's so often used to code network-oriented services making heavy use of concurrency.

That's because Swift doesn't have a first-class concurrency story yet. I imagine that concurrency safety will be sorted out when Swift gets concurrency, but in the meantime all Swift concurrency is using C primitives like pthreads and libdispatch.

That sounds like it's going to be a mess. If they introduce compile time checks that have the same strictness as Rust it will break existing code. It seems like Swift has already done that a few times over.

Re: Modern C++ Won't Save Us

#393

Post by w0utert » Sun, Apr 28, 2019, 12:09 PM UTC

0xffff2 wrote: post #342

w0utert wrote: post #262

Earlier quoted context omitted.

In terms of generated coded, it is exactly the same. But that's not the point of optional types. The point of optional types is to force you to write checks for undefined values, otherwise your code will not compile at all. In the old-fashioned style of your example, you might forget to check for the possibility of a null pointer/otherwise undefined value, and use it as if it were valid.

But the whole genesis for this comment chain is that you can make exactly the same mistake with std::optional.

Only if you deliberately unwrap the optional, which means you either don’t know what you are doing (in which case no programming language feature will be able to save you), or that you’ve considered your options and decided you want to enter the block knowing some variable can be undefined.

IMO, that’s not the same as not having optionals at all, and writing unconditional blocks left and right that may or may not operate on undefined values. It super easy to just dereference any pointer you got back from some function call in C++, without paying attention. Optionals force you to either skip the blocks, or think about how to write them to handle undefineds. Also, it’s ‘code as documentation’ in some sense, which I’m a big proponent of.

Re: Modern C++ Won't Save Us

#394

Post by favorited » Tue, Apr 30, 2019, 3:08 AM UTC

leshow wrote: post #392

favorited wrote: post #67

Earlier quoted context omitted.

That's because Swift doesn't have a first-class concurrency story yet. I imagine that concurrency safety will be sorted out when Swift gets concurrency, but in the meantime all Swift concurrency is using C primitives like pthreads and libdispatch.

That sounds like it's going to be a mess. If they introduce compile time checks that have the same strictness as Rust it will break existing code. It seems like Swift has already done that a few times over.

Using a new language concurrency feature would require you to change your code anyway, the same way using any new feature would. And when the Elm/Rust-style ownership annotations are made public, they will be opt-in.

Re: Modern C++ Won't Save Us

#395

Post by masklinn » Wed, May 08, 2019, 9:29 AM UTC

w0utert wrote: post #393

0xffff2 wrote: post #342

Earlier quoted context omitted.

But the whole genesis for this comment chain is that you can make exactly the same mistake with std::optional.

Only if you deliberately unwrap the optional, which means you either don’t know what you are doing (in which case no programming language feature will be able to save you), or that you’ve considered your options and decided you want to enter the block knowing some variable can be undefined. IMO, that’s not the same as not having optionals at all, and writing unconditional blocks left and right that may or may not ope…

> Only if you deliberately unwrap the optional

"Deliberately unwrap the optional" is the exact same thing as "deliberately unwrap the pointer", you just deref' it and it's UB if the optional / pointer is empty.

C++'s std::optional is not a safety feature (it's no safer than using a unique_ptr or raw pointer), it's an optimisation device: if you put a value in an std::optional you don't have to heap allocate it.

> It super easy to just dereference any pointer you got back from some function call in C++, without paying attention.

And optionals work the exact same way. There's no difference, they don't warn you and they don't require using a specific API like `value_unchecked()`. You just deref' the optional to get the internal value, with the same effects as doing so on any other pointer.