C++17 progress update | Hacker News Reader

C++17 progress update

reddit.com

107 pointsingve21 comments

I'm very sad to see that reflection (or introspection) won't be making an appearance in c++17. Even limited introspection suggested in N3951 (http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html) would be a great boon. Implementing features that would render Qt's preprocessor useless would be a great start and would standardize the tooling around c++ as well as reducing the amount of boilerplate code required to do something as simple as serialization.

Lack of serialization/marshalling support at the language level is a big issue. Serialization eats up a lot of CPU time in any message passing system, it's slow when done with run-time introspection, and it's something that can be done fast by code compiled for a specific structure. Attempts to speed up serialization usually involve preprocessors; there are preprocessor code generators for Google protocol buffers and OpenRPC marshalling.

It's probably possible to do serialization code generation at compile time in Rust.

Or any language where you can write code that generates code at compile time, like Nim. Unfortunately, any answer for C++ is unlikely to be so elegant, so preprocessing feels like a lesser evil.

If you had some way to apply templates to each element of a structure in sequence, you could use template metaprogramming to do marshalling. Suppose you could write

    struct pnt {
      float x;
      float y;
      bool valid;
    };
    pnt p;

and then have

    auto s = serialize(p);

expand into

    auto s = serialize_field("x", p.x, serialize_field("y", p.y,
         serialize_field("valid", p.valid)))

then serialization could be implemented by defining serialize_field for each type.

  > It's probably possible to do serialization code 
  > generation at compile time in Rust.

This is precisely how it's generally done. See https://crates.io/crates/serde for an example.

Or any other language with compile-time reflection, such as D. Here's my serialization library in it: https://github.com/atilaneves/cerealed

I am using https://google.github.io/flatbuffers/ right now, it's going slowly but I'm still learning c++

Well, to be honest C++ is trying too little, too late

And to be fair, the competition is still getting there where it really matters that you write C++ code. Go is starting to be supported on ARM, but given that it had issues with i386 I'm not sure what kind of issues might show up. Swift is for now Apple only, not sure about Rust

Go and Rust still need to find their way into OS vendors SDKs.

Many of us only use first class support languages, regardless of other options might exist out there.

> Many of us only use first class support languages, regardless of other options might exist out there.

Yes, that's the reality unfortunately

There are very few options for small embedded hardware. Or even for desktop applications, as forgotten as they are today (though Java plays in this field)

Herb Sutter has a nice blog entry that complements Lavavej's reddit post: http://herbsutter.com/2015/10/25/2568/

Honestly, if modules alone make it into C++17, I will be a happy camper.

"(Note that the Oulu meeting is when we plan to feature-complete C++17 and send it out for its main comment ballot, so that will be a big meeting. (It will also be within a few dozen kilometers of the Arctic Circle and is deliberately scheduled so that the summer solstice occurs during the meeting, so the joke is that there will likely again be lots of post-dinner sessions in Oulu, but for once we can guarantee there will be no evening sessions!)"

Is there anything newer than this on modules: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n404... ?

It looks like this change could reduce build times... but are there any benchmarks published yet? Sounds like clang has some support already.

clang support is only for C and Objective-C

See the CppCon videos:

https://www.youtube.com/watch?v=RwdQA0pGWa4

And the Microsoft proposal that is part of the Core C++ Guidelines:

https://github.com/isocpp/CppCoreGuidelines/tree/master/talk...

I love how active Bjarne and the some of the other committee members are on the cpp subreddit. C++ has such a great community surrounding it.

Yes, and contrary to the C community it sprung from, it really values safety.

btw this is the account of Bjarne - https://www.reddit.com/u/bstroustrup

Does anyone know if they decided to fix rvalue reference and move semantics as proposed? Someone suggested that move semantics should be handled in the destructor, not the constructor.

I don't believe that any "destructive move" proposals have advanced out of Evolution and into Core. The issue is whether moved-from objects should be in a weird twilight state ("valid but unspecified"), which is the status quo, or whether moving from an object should straight-up destroy it. The question is... controversial.

I read about the fact that there should be no move constructor, only a move destructor. When you think about it, it's awesome and solves all problems.

You get rid of rvalue references except for universal references.

P0002R1 Remove Deprecated operator++(bool)

bool t = false; bool t2 = true cout<<++t<<endl; cout<<++t2<<endl; ... 1 1

I had no idea you could do that. That's just odd.

Reply on news.ycombinator.com