Trip report: Fall ISO C++ standards meeting | Hacker News Reader

Trip report: Fall ISO C++ standards meeting

herbsutter.com

78 pointsarunc34 comments

> we already have memcpy, but bit_cast is safer and also can run at compile time.

Can someone smarter than I am explain the significance about bit_cast running at compile time?

It can be used with constexpr (http://en.cppreference.com/w/cpp/language/constexpr) to precompute values at compile time.

Here are some videos on the topic: https://www.youtube.com/watch?v=PJwd4JLYJJY https://www.youtube.com/watch?v=rpn_5Mrrxf8

I suppose to be used in constexpr functions.

So you can have a constexpr (compile-time) code fragment that, say, casts a float to an unsigned int and extracts the mantissa.

Mostly though, this is fairly unimportant and tedious spec-manship, filling in some obvious gaps.

We had a version of this in chromium a few years ago. This is a proposal just picking that up from what I can tell.

Bitcast, including the specific nomenclature, comes from LLVM, which had the concept more than 10 years ago.

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.

Is there a typo in operator== ?

  friend bool operator==(const CIString& a, const CIString& b) 
  { return ci_compare(a.s.c_str(), b.s.c_str()) != 0; }
  friend bool operator< (const CIString& a, const CIString& b)
  { return ci_compare(a.s.c_str(), b.s.c_str()) <  0; }

This way a<b implies a==b.

```

for (auto& x : f().things()) { // dangling reference!

mutate(&x);

}

```

Oh shit I think I have to go through a dozen projects in production and fix some code now. Thanks Herb.

Are you sure?

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.

click

Now it all makes sense. This is what I get for trying to read technical stuff while drunk at midnight.

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.

[1] https://stackoverflow.com/questions/21861148/what-does-the-s...

Wow this website loads incredibly fast.

That's because it's not laden with shitware like most other sides.

Herb Sutter's awesome like that.

Sarcasm? There's an 8 second animation until anything shows up. From the page's stylesheet:

  body {
    animation: -amp-start 8s steps(1,end) 0s 1 normal both;
  }

  @keyframes -amp-start {
    0% {
      visibility: hidden;
    }
    100% {
      visibility: visible;
    }
  }

? The site is loaded before I can even tab to it.

uh ? I don't see anything being animated when opening it

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.

Basically adding an operator to replace the existing `std::is_nan()`? Not sure if this deserves to be first class in the language...

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.

No, it would be the same as evaluating (a<b)&&(a==b)&&(a>b), not std::is_nan.

A special syntax seems unnecessary. Just drop something like this in your project:

  template<typename A, typename B>
  bool is_unordered(const A& a, const B& b) {
    return !(a<b||a==b||a>b);
  }

edit: changed implementation to match name.

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.

(a<=b) is equivalent to ((a<b)||(a==b))

((a<b)&&(a==b)) is equivalent to (false)

You mean:

    (a<b)||(a==b)||(a>b)

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...

Special operator for one type? Please no.

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.

Why not `is_nan()` insted?

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.

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.

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.

https://dlang.org/spec/expression.html#floating-point-compar...

I researched a little bit into to this question - this might be interesting: https://stackoverflow.com/a/43773235/1073695

If you want to check whether either of two values is NaN, rejoice, it is now optimized to a single instruction on x86 by GCC 6 and Clang 3.7: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387

You write isnan(x)||isnan(y) but the compilers now optimize the whole thing to one instruction.

If you want specific syntax you can use the builtin unordered(x, y).

Reply on news.ycombinator.com