The concept of bitcasting is as old as programming. In the context of C++, I'm also pretty sure that the bitcast template, in one form of another, is also much older than LLVM itself.
This discussion[1] maybe useful in solving the problem. "things()" member function should be qualified with a reference to prevent it from being called from an rvalue object.
If f() returns a value then you have a problem and should fix it, but if f() instead returns a reference (that is not dangling in itself), then it should be fine.
I think the idea is that it's supposed to hide the content until the page has loaded entirely, then fade it in, because it "looks faster". But if uMatrix (or something similar) blocks scripts from ampproject.org, you just get a nice 8s delay. You can get around it by removing /amp/ from the end of the URL ( https://herbsutter.com/2017/11/11/trip-report-fall-iso-c-sta... )
I would like to see a spaceship operator for floating point comparison, where a<=>b means a is less than, equal to, or greater than b. It would be useful for checking that a and b aren't NaN. If either were NaN, then the comparison would return false.
The NCEG (Numerical C Extensions Group) proposed a complete set of floating point operators for all combinations of NAN and <, ==, and >. I implemented them in Digital Mars C++, and nobody used them. I also implemented them in the D programming language, and there is simply no interest in it.
Plus then you couldn't use it for </>/== at the same time like you'd want to and relative meanings for different types would be inconsistent. I think this idea is a nonstarter.
Double ampersand is logical AND, you want double bars for logical OR.
And still, that's equivalent to !(std::is_nan()), unless you're suggesting using the operator on other non-floating-point types which have a similar problem...
It just makes more sense. Similar to how a<=b is equivalent to (a<b)&&(a==b).
Coming up with an entirely fresh meaning for <=> involving spaceships and a conglomerated comparative threesome just seems illogical to me, given the original meanings of the component symbols of <=>.
This operator already exists in Ruby, Perl and a couple other languages.
It's also incredibly useful, allowing six functions to be replaced by one. Or, rather, with zero, because in 99.9% of cases you will just be able to declare the signature with '= default;' and let the compiler generate the implementation. Then you have all relational operators available for that type. It makes defining new types much, much easier.
Plus, it provides a place to statically define what sort of ordering the type has, so further compile-time optimizations can be done.
In contrast, <=> as is_ordered is nearly useless. It would basically only be used for floats, where !(isnan(a)||isnan(b)) is both equivalent and IMO more clear.
Well, this is C++, so the spaceship operator can be overloaded for all sorts of clever purposes.
For example, when comparing strings, you could use it to coerce the arguments into spaceship objects, then run a little Space War simulation to lighten the user's day. Just another day of C++ operator overloading.
No, it could be used for any type. It would be equivalent to (a<b)&&(a==b)&&(a>b), but would be most useful for floating point, where this operator would evaluate to false if a or b is NaN.
Nope, this operator will always evaluate to false. Show me any pair of numbers, which is not NaN, which will be at the same time, equal, smaller, and greater. Of course I can imagine such a set, and operations... (I have a little bit of a mathematical background) but for programming it will be quite useless.
No, the operator is like the same operator in Ruby. You define an operator<=> for one or two types and then whenever you use one of the normal comparison operators in code (say a < b), the compiler replaces it with a<=>b < 0.
Can someone smarter than I am explain the significance about bit_cast running at compile time?