241–250 of 276 posts
Earlier quoted context omitted.
Forgive my poor C++, but has_value() sounds like a bool, and empty() sounds like a bool. Why wouldn't "bool1 & bool2" work correctly?
In other languages, booleans are their own values (iirc in C/C++ they're aliases for 0/not-0) for which the `&` operand is simply not implemented. There's also linters and other quality control analyzers that will warn on a bitwise operator on booleans.
Earlier quoted context omitted.
That is just gaming your coverage stats, there are still the different branches they just aren't visible now.
That's not true. Compare `( a() || b() || c() ) ? yes() : no()` to `( a() | b() | c() ) ? yes() : no()`. In the second case, there are two paths through the code: a() b() c() yes() a() b() c() no() But in the first case, there are more paths: a() /* true */ yes() a() /* false */ b() /* true */ yes() a() /* false */ b() /* false */ c() /* true */ yes() a() /* false */ b() /* false */ c() /* false */ no() That is becau…
Earlier quoted context omitted.
Forgive my poor C++, but has_value() sounds like a bool, and empty() sounds like a bool. Why wouldn't "bool1 & bool2" work correctly?
In other languages, booleans are their own values (iirc in C/C++ they're aliases for 0/not-0) for which the `&` operand is simply not implemented. There's also linters and other quality control analyzers that will warn on a bitwise operator on booleans.
Earlier quoted context omitted.
> that‘s how we always did it ... which, frankly, is a very good reason. Don't needlessly change something people are used to. Why is the blinker control on the left side and the wiper control on the right side? Because that's what people expect.
No it's because this way your left hand only deals with blinker, and your right one wih the gear shift. Separation of concerns. It's reversed in the UK of course.
All my cars for the last ~15-20 years have had the indicator stalk on the left (i.e. same side as the gear stick), and the windscreen wiper/wash controls on the right, but I suspect that this might be a manufacturer-specific convention.
A quick bit of googled internet wisdom suggest Japanese brands tend to the right, European brands tend to the left, and EU standardisation has settled on left.
Strictly speaking, I would expect the indicator to be activated prior to commencing a manoeuvre, so would expect the two actions to not overlap.
How long have they shipped a secure Linux to a couple of hundred different devices simultaneously, while improving security, fixing critical bugs soon and delivering a pretty great user experience since they first launched Chrome OS? Sure, were soft bricks before, critical fixes introduced other bugs, duh. The same happens on Windows, macOS, Linux distributions - we're all human, we make mistakes, we try to learn from each mistake.
Don't give them a hard time. They already were in panic mode already.
Earlier quoted context omitted.
> that‘s how we always did it ... which, frankly, is a very good reason. Don't needlessly change something people are used to. Why is the blinker control on the left side and the wiper control on the right side? Because that's what people expect.
No it's because this way your left hand only deals with blinker, and your right one wih the gear shift. Separation of concerns. It's reversed in the UK of course.
https://news.ycombinator.com/item?id=768151
:)
Rust would have prevented this.
Rust's Option can't be simply dereferenced causing UB, so `val.is_some() & val.kaboom()` doesn't compile. Rust doesn't have implicit conversion between booleans and integers, so a problematic `true & 2` does not compile either. Rust does allow `true & true`, but booleans are strictly 0 or 1 in value, so you wouldn't get a wrong result, apart from eager evaluation. There's needless_bitwise_bool clippy lint for it.
I guess the equivalent of `operator->` would be `unwrap()`. It isn't UB, so this bug couldn't happen in Rust indeed.
> Rust doesn't have implicit conversion between booleans and integers, so a problematic `true & 2` does not compile either.
That isn't what's happening here as both `key_data_.has_value()` and `!key_data_->label().empty()` return bool.
Earlier quoted context omitted.
If you do not have the relevant tooling you can still read the canonical formatting. If you want custom formatting, I don't think that expecting your editor to reformat on the fly is a big ask. At the end of the day that exactly what tab proponents expect.
> If you do not have the relevant tooling you can still read the canonical formatting. Which is often unnecessarily difficult for whatever reason, hence my initial comment. Given that tabs already exist there's literally no reason not to use them other than to intentionally spite any future readers who don't agree with your preference for indentation width. > that exactly what tab proponents expect Because that capab…
[1] I'm hyperbolic, sorry if you actually do that although I pity you.
Earlier quoted context omitted.
Much more usefully, in C++ you can also parametrize over templates, which I think you still can't in rust. You can't parametrize over namespaces (at least not directly) which is an annoying and arbitrary restriction.
> You can't parametrize over namespaces (at least not directly) which is an annoying and arbitrary restriction. It's not a restriction, namespaces are neither types nor values so they would need specific support. Given that you can (ab)use classes with static members as namespaces which are also a type it's simply that nobody cared enough to add support for templating over real namespaces.
Stateless structures are a workaround (so is adl driven by a template parameter), still direct support would be nice.
Earlier quoted context omitted.
The code is: key_data.has_value() && !key_data_->label().empty() key_data is probably something like an std::optional, so short-circuit evaluation guards the dereferencing of the optional. If you write this with a binary and, no short-circuit evaluation can happen, so undefined behavior ensues. I wanna point out that std::optional, in the typical C++ stance, has a "I know what I'm doing" API and a "Humans make mistak…
Where is the undefined behavior? AFAU, UB is a compile time concept. As other commenter has asked, how can the compiler infer that has_value() call has any relation to key_data_ non-NULL-ness? EDIT: > optional->... is UB if the optional is empty I understand what you mean: dereferencing optional is undefined if has_value() is not checked for true in the same thread before. But that undefined behavior happens at runti…
Because of LTO.