
C++17 and its Technical Specifications - meetingcpp
https://meetingcpp.com/index.php/br/items/c17-and-its-technical-specifications.html
======
readams
The C++ standards committee and community has really been firing on all
cylinders lately. C++ has made such enormous strides in the last few years. If
you've been away from C++ for a while, check out modern C++ again. You'll be
shocked by how good it's become.

Just keep away from the Google C++ style guide lines. They'll lead you very
far astray.

Check out
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)
for a good start on modern C++ style.

~~~
vardump
> Just keep away from the Google C++ style guide lines. They'll lead you very
> far astray.

Huh. I think Google C++ style guide makes a lot of sense. C++, the good parts.

What's wrong with the guide in your opinion?

I know a lot of people might disagree, but the common criticism of Google's
C++ style, exceptions, tends to be a misfeature when you need to actually
handle the errors.

It puts error handling code far from where errors occur, and where you often
have the best chance to deal with it. It also obscures error sources, it's not
immediately obvious in local method context just by looking at the source code
which calls can throw and which not.

Exceptions also don't undo any I/O that was done, so things might be in pretty
bad state -- and it tends to be pretty bad to deal with that a few method
calls up.

I like errors to be on my face, even if they're "ugly". You tend to forget
about hidden things.

~~~
azov
_> It puts error handling code far from where errors occur, and where you
often have the best chance to deal with it_

So, you pass file name to your data access library and the file is not there.
How are you going to deal with it? Write an error to the log nobody reads and
call terminate()? Create a new file and let users guess what happened to the
data they expected? Or return an error code?

If you picked the last option (as most people do) - well, bingo, you've just
put your error handling far from where the error occurred. The only difference
with throwing an exception is that now every function up the call stack needs
to check that error code till it reaches the place where you can handle it or,
even more likely, till someone forgets to check or chooses to ignore it.
Because, unlike Go or Rust, C++ compiler won't help you there.

Error codes don't undo I/O either.

As to "which functions can throw" \- let me suggest a simple rule: every
function can, unless you can prove otherwise.

Look, there are situations where it makes sense to avoid exceptions, but not
for the reasons you listed. Exceptions are the least evil way to handle errors
in C++. Google style guide bans them mostly for historical reasons, let's not
cargo cult it.

~~~
sbmassey
How about wrapping the return value in a templated error class that the caller
has to explicitly unwrap with an error handler to be able to use?

~~~
azov
That will help if there is a value to return - but then it's not much better
than just returning something invalid, like a NULL pointer. If the only return
value is success/failure you need compiler support (1) to ensure it's not
ignored.

(1) There are clever hacks to mimic this behavior to some extent, but I don't
even want to go there. If you really want this feature - just use a language
that has it.

------
BinaryIdiot
I'm very excited for networking to FINALLY be part of the standard.
Practically every modern language has networking capability in their standard
libraries.

The day I can pick up C++ and, without including any third party libraries,
write my own web server in a minimal amount of code will be the day I start
using it more. Too much of what I do nowadays requires some form of
networking.

~~~
rb808
Yeah I was a C++ dev for 12 years before switching out. I miss being able to
hit the metal, its depressing to work with Python Pandas that are advertised
as "nearly as fast as C". Meanwhile our main Java app has huge GC lockup
problems. Hopefully C++ will soon be at a level I can recommend it for
business applications again.

~~~
giancarlostoro
Sounds like you could take a look at D as an alternative to Java if you want
to hit the bare metal and still have (optional) GC. I like D a little more
coming from a C# / Java background but wanting something more natively
compiled.

~~~
fancy_pantser
s/D/go/g

~~~
giancarlostoro
Only mentioned D for being Object Oriented with classes.

------
moomin
This will probably be an unpopular position but: I really hope concepts
doesn't make it into C++17. Not because I don't want concepts, but because I
think definition checking is completely integral to what I want them for.

~~~
Rexxar
Even if definition checking is very important, why not implement the full
specification in two steps if it helps to make it happen ?

~~~
marvy
Because once you ship it without definition checking, three years later it's
too late to add it. Too many people will have written code that will break.
This is one of those unfortunate language features that you only get one
chance to get it right. Note: I haven't been following this stuff closely, I
could be missing something here, but I trust that someone will correct me if
I'm wrong. Or at least down-vote me to oblivion :)

~~~
Rexxar
The current specification create a "concept" keyword. Why the fully checked
concepts couldn't just use another keyword like "checked_concept" that behave
exactly like the "concept" keyword for user of the library ? Library
implementers can then migrate progressively their code when they can.

edit: or, alternatively, create a "checked_template" keyword when implementing
a checked template.

~~~
moomin
In any event, it looks like concepts have indeed been kicked to the kerb. I
think the definition checking was important, and some were concerned that
there was no library implementation using it, which means they haven't shaken
it out in practice yet.

------
soulbadguy
Was the coroutine proposal droped from C++17 ? That was one of the most
exiting feature

~~~
meetingcpp
No, that is not dropped, but it also is not contained in a TS yet, I'm not
sure if it gets added to C++17.

There is a wording paper: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2016/p005...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2016/p0057r2.pdf)

Not sure if Jacksonville will already give green light or if this will be
decided later. Would be a good addition though.

------
tragomaskhalos
std::optional seems to have been in gestation for ever, and we're crying out
for it. Is there some complexity issue here that I'm missing?

~~~
makecheck
One reservation I have about “optional” (and for that matter, “shared_ptr” and
other objects that directly store their tracking in an object) is that object-
oriented storage models do not necessarily make sense for tiny objects.

If you have a lot of optional data, or a lot of reference counts, etc. it can
make a lot more sense structurally to gather the state of all variables in one
place. For instance: if you have 10 optional fields in a structure, create a
single set of 10 bit flags to track them all; the result is much smaller than
10 “optional” objects ever could be. The last thing you want is a ton of
padding across millions of objects in your program; this starts to affect
everything from efficient use of caches to maximum memory capacity.

It just seems a bit of a slippery slope; optional<> might start showing up all
over the place as the One True Way To Optional things, without regard for the
unnecessary padding and/or wrapping of data.

The only way to really do this “for free” is to have the compiler keep track
of what was ever set, as Swift appears to do, keeping the tracking out of the
memory or run-time footprint.

~~~
jzwinck
People often use a vector of vectors as a matrix. It's not as efficient, it
usually is a bad idea, yet it doesn't discredit std::vector.

I suppose we could create a variadic template std::optional<...> which works
like a tuple to solve your padding concerns.

------
vardump
When will there be a C++XX that will actually remove bad features? Of course
with a migration plan and tools.

C++ standard is pretty big, I don't personally know anyone who _really_ knows
C++.

I write C++ as my day job.

~~~
jzwinck
There have been deprecations like auto_ptr and gets(). But I assume you're
looking for more.

You aren't going to get it. C++ is just not that language. It isn't going to
have a Python 3 moment. Nor should it.

I for one am glad to be able to upgrade to new versions of the language
without having to rewrite much.

~~~
Noughmad
Complete breaking is never going to happen. What can be done is adding
compiler switches which enforce some kind of "strict" or "modern" mode.
Something close to "-Wall -Werror", but with errors explicitly for the
deprecated/bad features.

------
Syntaf
I've given a number of talks on the parallelism TS at C++ conferences and
fully believe it can revolutionize the C++ libraries, I really hope it can
make it into C++17.

Having such easy parallelism techniques within the language would be _huge_ ,
I can think of so many scenarios where stupid-parallelism can be applied using
the STL. The only set back is the additional room to shoot yourself in the
foot, people that don't understand the overhead of parallelism could easily
blow up a program in terms of efficiency.

------
KKKKkkkk1
The guys who've been prodding us to use chevron IO in lieu of printf and to
pepper our code with gems like the for_each "algorithm" are back, and they
have some new awesome features for us. Thanks, guys.

------
jokoon
Other question: do you think that writing a compiler that only work with C++14
or 17, might compile code faster ? Or will C++ always be slow to compile ?

I'm still wondering what makes go so fast to compile.

~~~
looki
Not currently. I think it can be largely attributed to header files, for which
we currently have no solution in modern C++. Think about what your code would
look like if you expanded all #includes of a single file, each containing
entire class definitions that need to be parsed.

One of the proposals for the next C++ standard is for modules, which would
allow better symbol importing and would largely boost compilation speeds,
among other benefits.

------
je42
Finally "then" for futures ! Yay !

------
ape4
Risking downvotes... all this stuff seems a bit boring. For example, since the
start C had ways to access the disk, C++ gave us ifstream's and now C++17 has
filesystem - yawn.

~~~
azov
ifstream is very, very limited. Shocking as it is, there's still no _standard
and portable_ way in C++ to do very basic filesystem operations, like list
files in a directory - you have to use platform APIs or third-party
portability libraries.

Seems like C++17 finally resolves this. We only had to wait 34 years :)

~~~
lettergram
I've been using Qt for years to do this. I have my fingers crossed I can
finally use the standard libraries.

~~~
sbmassey
Well it is basically an almost-copy of Boost.Filesystem which you can use
today, can you not?

~~~
CyberDildonics
Boost requires compiling libraries ahead of time and linking them in, so to do
that on top of Qt would be asking a lot for very little gain. If filesystem
was a header only library I don't think it would be as much of an issue.

