
C++17 progress update - ingve
https://www.reddit.com/r/cpp/comments/3q4agc/c17_progress_update_oct_2015/
======
green7ea
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](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.

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

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

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

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

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

~~~
choppaface
Is there anything newer than this on modules: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n404...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf) ?

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

~~~
pjmlp
clang support is only for C and Objective-C

See the CppCon videos:

[https://www.youtube.com/watch?v=RwdQA0pGWa4](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...](https://github.com/isocpp/CppCoreGuidelines/tree/master/talks)

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

~~~
avinassh
btw this is the account of Bjarne -
[https://www.reddit.com/u/bstroustrup](https://www.reddit.com/u/bstroustrup)

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

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

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

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

