
C++17 and other future highlights of C++ - meetingcpp
http://meetingcpp.com/index.php/br/items/cpp17-and-other-future-highlights-of-cpp.html
======
nly
Looks like C++17, like C++14, is just going to be a spit shine over C++11.

Concepts, modules and coroutines were perhaps the three most anticipated
features, and they failed to deliver all three. No STL2 either. Woeful. The
field is now wide open for the next 5 years for Rust to come along and eat
C++s lunch.

The whole TS/std::experimental idea is just a folly. As a C++ programmer I
just don't care if a library is available via a TS vs Boost. There's literally
zero advantage to a TS. None. I'd rather stick with Boost, because then at
least I only have one implementation to test against, instead of three, each
with their own bugs, omissions and performance characteristics.

I've even taken to using boost::container::string where I can, instead of
std::string, because the libc++ and stdlibc++ implementations have different
performance characteristics.

~~~
BinaryIdiot
> Concepts, modules and coroutines were perhaps the three most anticipated
> features

Were they? They're great and all but from a practical standpoint I'm most
excited about networking being baked in. I do almost nothing nowadays that
doesn't require some form of networking. Now I can do it without bringing in
any extra dependencies beyond the STL? And it's portable? Yes please!

I'm not a huge C++ developer. Maybe if I was other things would be more
important to me. But adding in networking makes me want to use the language
again.

~~~
unfamiliar
Networking is a very particular set of features that you only need if you are,
well, doing something with the network. I'm not and probably never will, for
example. But concepts and modules (and perhaps coroutines) were general
features that would have potentially benefitted every single problem domain,
since they are fundamental to how you use the language, not what you are
trying to do with it.

~~~
nly
Doing networking in the standard library without introducing a proper async
framework is just more madness. Polishing off promises and futures, and
getting coroutines nailed down, would have made introducing an intuitive
network library a doddle.

Instead we'll get something carved out of ASIO, which is a complete mess full
of gross unintuitive APIs and callbacks.

~~~
gpderetta
What's wrong with ASIO interface? My only issue with it is that once a socket
is bound to an io_service it can't be easily rebound to another one.

For many applications where C++ is used, promises and futures introduce
unnecessary overhead. On the other hand an ASIO-like interface works just
fine.

Additionally, ASIO, and by extension the network proposal, have transparent
opt-in support for futures via a special callback type.

~~~
nly
Example terrible API: You have to create a socket for a new connection before
calling async_accept. Try using this with coroutines.

> opt-in support for futures via a special callback type.

Which is ugly. The coroutines opt-in as well. Coroutines actually have the
potential to be faster than callbacks.

------
jordigh
Special functions?[1] Why do they keep wanting to add that to the standard?
They've been trying to get special functions into the standard since C++11
(née C++0x). That seems like such a very niche use, better left for
specialised libraries where numerical researchers can work out the very best
algorithms rather than for a standard system library. I mean, compared to
accessing a filesystem or parallel processing, how many C++ users regularly
need the Riemann zeta function or a modified Bessel function of the second
kind?

\---

[1]
[https://en.wikipedia.org/wiki/Special_functions](https://en.wikipedia.org/wiki/Special_functions)

~~~
lobo_tuerto
Maybe because the need for them has popped up enough times and they tought it
would be a good idea to add them to the standard? Also that addition wouldn't
hurt no one.

~~~
jordigh
> Also that addition wouldn't hurt no one.

Library implementors would have to implement it. Most of them are probably
unqualified to do it, so they'll probably just grab Boost's implementation.
And Boost's implementation would be unreadable to most implementors. Thus
everyone would get a slightly subpar implementation, because most numerical
researchers are not keeping an eye on Boost and making sure it has the best
methods available. The end result is that those in the know will avoid the C++
stdlib, just like Qt did and reimplemented strings and maps.

We've seen this problem before with valarray and with export. There is a
problem with standardising something that nobody wants or nobody can implement
correctly.

~~~
Someone
The flip side is that I would rather use a “slightly subpar” implementation
than having to roll my own from a Google search and some smart guessing.

For example, if you want to implement a Student's t-test, you soon will run
into the problem that you want to have a Beta function or the gamma function.

One could probably copy-paste a somewhat working version together from search
engines, add asserts to prevent me from ever calling them with arguments out
of the range where it seems to work, but for most of us, the result likely
will be slower and less precise than a version that gcc, clang, or commercial
compilers would provide.

And yes, I could probably buy an implementation somewhere, but in the real
world, that often isn’t a real option, and even then, I wouldn’t know how well
it worked, either.

------
makecheck
Before they heap yet more into the language, I think they need to go back to
previously-standardized classes and seriously critique them, ideally replacing
some of them with entirely new designs.

For instance, it is _crazy_ that something as critical and commonplace as
"std::iostream" is riddled with error-prone design decisions. The "<<"
operator choice is _wrong_ , and it fails basic localization requirements
before you even get into its other problems. To this day, I see people who
don’t handle stream errors correctly in every case (and who can blame them,
when you have stuff like “bad() is actually not the exact opposite of
good()”?). Don’t even get me started on the fact that most flags have two
different pairs of constants with similar names, used in different contexts,
with different values, that will even _compile_ after the wrong one has been
chosen (producing who-knows-what behavior?). Or the fact that global stream
states can be screwed-with from anywhere, meaning that when a library call
returns you can’t be sure that your own "std::cerr" state is “undamaged”? And
this is just from streams! The list goes on.

------
eclark
Does it feel to anyone else like they are procrastinating on modules? C++ has
been thinking about it for a very long time. Yet the actual result is a
generic "soon."

~~~
lbrandy
I've been following modules pretty closely and attended the meeting in
Jacksonville. I think the story here is actually pretty positive. I understand
people are upset it's not making C++17 but those expectations were always
unrealistic. Based on my read of the situation, modules were never a serious
candidate for C++17.

IMO, what's happening with modules is basically the best (realistic) outcome.
Up until Jacksonville, we had only a proposal and all the implementors either
implementing their proposal, or implementing nothing waiting for a TS. Modules
were blocked on the committee. And that's a slow place to be blocked.

Now we've cleared the major hurdles for a modules v1 TS and gotten to the
point where implementors are unblocked by the committee and we can start
actually building and using it. If the early-adopters want modules from their
implementations, they'll actually be able get it, now, finally.

Once implementations start happening, and we gain a bunch of "deployment
experience", it'll be a whole lot easier to chart a course through the
remaining thorny issues with respect to macros and "middle-up" deployment to
existing codebases.

~~~
TillE
Just speaking as an average C++ programmer who doesn't watch the standards
process too closely, after C++14 it seemed like quite a few major features,
modules included, were expected for C++17. At that point no one was saying it
was unrealistic.

I was hoping for reflection, but it was clear to me a few years ago that there
wasn't enough interest or agreement there. But I think a lot of people
expected modules and concepts.

------
chris_wot
I'm finding it hard to keep up with all these new features!

In C++11, I think that the most overlooked feature is attributes. Finally, a
way of potentially doing AOP without resorting to hacks :-)

~~~
whitegrape
Always looking for yet another reason to sustain my hope of avoiding C++
forevermore, I like the argument-reversal against using other languages
instead. "Most devs don't know it, they have to retrain!"

I learned C++98 pretty deeply (better than it deserved) but apart from a few
things like "hey cool you guys sort of have lambdas now and auto and some new
pointer types I'll learn if against my hopes I ever have to do anything
important" I haven't really kept up much, but I know there's a lot that has
been added. My friend (who just knows a little C++98, his main languages are
higher level things for writing automation tools) was talking to me a few
weeks ago about finding a bug in his boss's code and having a moment of "Nope,
let's wait for him to come back tomorrow" after seeing the totally unfamiliar
rvalue reference && in a constructor he tracked down as the source of the
bug... If I were to become involved in any C++ project again, if it wasn't
strictly maintenance work I'd feel very uncomfortable doing anything without
first taking a chunk of time to learn everything new. I feel like that chunk
of time would better be spent on Rust, and if I were a manager looking to
build something brand new that needed to be low level, I'd also be heavily
looking at Rust and hiring people who know it or people who want to learn it,
vs. going with C++ and hoping that people that put C++ on their resumes
actually understand the modern details on a more than academic level (which
would be hard to test for in interviews) and if they don't shelling out the
same cost to train them as that of training newcomers to Rust. As for what
motivates me out of the office as a true C++ replacement so that companies
don't have to train me on their dime, Nim is much more fun.

------
jmpeax
> SG14 - Games & Low Latency

Can't help but think Jonathan Blow's new language designed for games will blow
C++ out of the water, and will probably arrive much sooner than these long
drawn-out C++ committee features.

------
nikanj
I recently had to do some C++ again, and the amount of weird pitfalls and
annoying corner cases is really starting to get to me. For example, std::cout
<< std::hex << myNumber prints the number in hex as expected. Well, if the
number has 16 bits or more. Eight-bit integers are an alias of char, and
std::hex does wrong things if you feed it a char.

There probably is a workaround for this, as there is a workaround for every
other "feature" too, but the more seldom I write C++, the more I realize the
language could really use a streamlining. Programming languages are weird, as
they seem to develop more, not less, rough patches and glitches as they age.

------
falsedan
This article really should include links to the previous entries in the same
series. I hoped the 'Back' link would help guide me to them, but it just runs

    
    
      history.go(-1)

~~~
meetingcpp
The very first link is a link to the previous part of the series.

~~~
falsedan
Oh, so it is. I thought it was a link to the current Technical Specifications,
most likely to move into C++ after C++17.

------
phkahler
Yawn. Tell me when they standardize 2,3,and 4 element vector types so I don't
need to use intrinsics.

~~~
Animats
I once proposed a library for 2, 3 and 4 element vectors based on the one in
Graphic Gems.[1] It was rejected because it didn't use templates.

[1]
[http://www.animats.com/source/graphics/algebra3.h](http://www.animats.com/source/graphics/algebra3.h)

~~~
phkahler
The nice thing about the intrinsics is that they can be passed by value or as
a return type. They map nicely to modern vector hardware. Anything done with
templates is going to be very generic and will not have these characteristics.
But let them continue adding abstractions with funky syntax instead of
optimized versions of widely used constructs. ;-)

~~~
Joky
I don't see why template-based types would be able to be passed by value or
returned?

An interesting library is Boost::SIMD (!! not part of Boost !!):
[https://github.com/NumScale/boost.simd](https://github.com/NumScale/boost.simd)

------
TwoBit
I think they should stop C++ standard updates for a five year period during
which we can learn from the recent changes.

