
Writing Good C++14 by Default [pdf] - adamnemecek
https://github.com/isocpp/CppCoreGuidelines/blob/master/talks/Sutter%20-%20CppCon%202015%20day%202%20plenary%20.pdf
======
criddell
Every time C++ is discussed here, I feel like I might be the only person on
the planet that _likes_ C++ and enjoys working in it. I get excited when
Sutter publishes an article about some proposed new feature. I enjoy talking
about code with new hires and giving them a set of Scott Meyers' books to
read. I'm in awe of what the clever Boost contributors wring out of the
language.

I don't think it's a stinking ball of meat. It's a living language with a deep
history that's getting better all the time. It's a wonderful tool that I use
daily.

~~~
tonyarkles
Let's be friends! I did a lot of C++ back in the late 90s/early 2000s, and it
kind of sat on the shelf for me for a while. I've recently come back and am
discovering all of the joys of modern C++(11/14). I'm really really impressed.
The first project was a cross-platform library on top of libusb. With all of
the great concurrency things built-in now (std::thread/mutex/lock, etc), I
managed to write the whole library without a single #ifdef! Generates Linux
.so, OS X .dylib, and Windows DLLs. Amazing!

~~~
CuttlefishXXX
>I managed to write the whole library without a single #ifdef! Generates Linux
.so, OS X .dylib, and Windows DLLs. Amazing!

Could you expand on how you are doing this? You're still using a Makefile or a
similar tool with some kind of platform detection for the build itself, right?

~~~
flohofwoe
Not sure whether the parent does it like this, but you can use cmake to
describe the build, and then (for instance) run cmake --build to build the
project in a 'cross-platform' way using the platform's native compiler
toolchain, it works the same on Windows, OSX and Linux. I think what the
parent meant with 'no #ifdefs' is that the C++11 std lib comes with more
modules that make a lot of platform-specific code-paths unnecessary (for
instance std::thread, std::atomic for threading, and std::chrono for high-
resolution time-measuring).

~~~
tonyarkles
Yup, you nailed it. cmake for handling the builds, and the C++11 stdlib covers
every platform-specific thing I needed. The only platform-specific thing I
needed to do was point the CMakeLists.txt at the correct libusb (libusb.so,
libusb.dylib, libusb.dll). Absolutely beautiful.

Edit: to elaborate a little more about cmake... You can use cmake to generate
both Makefiles and Visual Studio build files.

On Windows:

mkdir build; cd build; cmake .. -G "Visual Studio 12 2013"; cmake --build .

On OS X or Linux:

mkdir build; cd build; cmake ..; make

------
kamac
It's good that C++ is evolving, but I'm not sure if it evolves in the right
way.

Basically, consider a ball of meat. The meat is rotting, nobody would eat it
anymore, so fresh meat is slapped on it. And the process repeats numerous
times, for years.

In the end, you'll have a giant ball of meat, that'll look fresh, but once you
poke the ball, you'll be hit by the stench of the rotten meat inside.

I'd prefer if they started anew, rather than keep slapping fresh meat on the
ball.

~~~
flohofwoe
This looks to me like making C++ more "rusty" which is a good thing IMHO,
exactly for the reason that I don't need to bring all my existing code to a
new language but instead can make it 'safe' in incremental steps.

There are many good reasons to evolve a language instead of inventing a new
one, the situation is a little bit like with OpenGL: 'modern OpenGL style' has
nothing in common with the original OpenGL, and many ideas have been
introduced in past versions which are now considered bad or dead. Still I can
take the OpenGL Gears sample (which is who-knows how old) and run it on a
modern GL driver.

This is both a good and bad thing. The bad is that it is confusing to learn
OpenGL if you haven't been following its entire history. Googling OpenGL
questions will give you 10 different answers, all correct, but only for a
specific time in its history. The good thing is that this approach allows me
to bring a large piece of GL code incrementally to modern standards without
having to rewrite everything.

Of course there are the new fancy 3D APIs (just like there are fancier
statically typed, compiled languages compared to C++), but in general, people
are underestimating the risks of rewriting a large piece of code (this is
still just as true as when it was written 15 years ago:
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html))

What I would like to see in C++ is to have very detailed control over language
features and enforce coding guidelines in my own code base. The more fine
grained this control, the better. Something like 'don't allow pointer
arithmetics', 'don't allow C arrays', 'don't allow multiple inheritance',
etc... Going with your example: as soon as the rotten meat layer is reached,
the compiler would no longer accept the code unless you specifically allow it
with an exception to the 'modern rule-set'.

A combination of such rules could result in a 'safe subset' which would have
the same compile-times guarantees as Rust, and if the rules are violated, the
compiler will complain (I think/hope this is what the presentation is mainly
about).

~~~
fauigerzigerk
_> What I would like to see in C++ is to have very detailed control over
language features and enforce coding guidelines in my own code base._

Maybe something similar to JavaScript's "use strict" would be good, including
the ability to restrict it to function/class/source file scope.

~~~
jzwinck
We already have that: `gcc -Wall -Wextra`, and a few more flags for specific
things that some projects find too restrictive.

~~~
fauigerzigerk
Assuming "that" means "very detailed control over language features" I would
say no, these flags don't provide that.

Only very few flags warn or disable the use of entire language features. Most
are warnings against dangerous ways of using some of the features.

~~~
toth
I believe gp meant Javascript's "use strict" equivalent in C++, which I would
say is comparable to the compiler flags.

~~~
fauigerzigerk
"use strict" isn't comparable to warning flags at all, because it changes the
behavior of code. I only brought it up because it can be applied selectively
within function scope, not specifically for what it does.

I think what we need is a way to selectively disable language features.
Changing the behavior of existing features is a much more questionable thing
to do in my view.

The big question is if it's possible to disable some features without
affecting how other features must work. It failed miserably for exceptions,
but exceptions are a cross cutting sort of concern.

------
corysama
Comparisons of full-spectrum C++ vs Rust or some theoretical C++ that drops
support for the old stuff are subtly unfair.

If you are using a new language then you are by definition not
maintaining/upgrading old code. If you are starting a new project in C++, you
can follow the modern style guidelines and get most everything you are asking
for.

At this point, someone usually says "but nothing prevents my horrible
coworkers from using horrible features." If your coworkers are horrible, they
will find ways to be horrible no matter what language you chain them to.

~~~
steveklabnik

      > If your coworkers are horrible, they will find ways to be horrible no
      > matter what language you chain them to.
    

While this is true in some sense, it's also a relative degree of difficulty.
While you _can_ obviously write bad Rust code, like in any language, you have
to go really far out of your way to disable the compiler's assistance. Of
course, there are other kinds of 'bad code' than just unsafe...

~~~
corysama
> Of course, there are other kinds of 'bad code' than just unsafe...

Exactly. Many languages make it hard to be unsafe. But, every language makes
it easy to be horrible in one way or another.

------
Tobu
A direct link might work better:
[https://github.com/isocpp/CppCoreGuidelines/raw/master/talks...](https://github.com/isocpp/CppCoreGuidelines/raw/master/talks/Sutter%20-%20CppCon%202015%20day%202%20plenary%20.pdf)

~~~
adamnemecek
my reasoning was that people prefer to read things in the browser over
downloading them. afaik there is no way of achieving this only client side
without installing a plugin.

~~~
pjmlp
I always use native PDF renders. No need to have the browser turn my PC into
an airplane.

------
tmaly
maintaining the legacy code written in the late 90s is the hardest part. It
would be great if we could just press a button and the old code is now
magically C++14

~~~
neuromancer2701
My problem is that I work with a bunch of 90s era engineers and they still
want to code that way. It is what they know and they don't want to spend the
time to learn any of that new fangled C++11. Most of them are 5-10 years from
retirement if not working a shorten week already so why waste their time.

------
tempodox
Using C++ well has always been a question of judiciously selecting the feature
subset that does what you need the sanest way. Looks like cognitive load for
selecting that subset is increasing while the sane subset is getting smaller
in relation to the bulk of the language.

In other news, downloading a single PDF from GitHub is an atrocious pain in
the abdomen. I had to edit the HTML to get at that progenitrix-penetrating
URL.

~~~
rsam
> In other news, downloading a single PDF from GitHub is an atrocious pain in
> the abdomen. I had to edit the HTML to get at that progenitrix-penetrating
> URL.

I've usually found clicking on "raw" triggers the download; but possibly
doesn't work across all browsers?

~~~
tempodox
Yup, works in Safari. I'll have to remember that.

------
progman
"As clean and direct as any other modern language ..."

 _LOL_

Honestly I needed to read the C++98 code to understand the modern one. Yes,
C++ has advanced but the inherited waste is obvious.

Do other modern languages still operate with pointers?

[http://words.steveklabnik.com/pointers-in-rust-a-
guide](http://words.steveklabnik.com/pointers-in-rust-a-guide)

~~~
lhecker
In your blind love for Rust you seem to forget that it in fact operates with
pointers - _everywhere_.

The thing is that Rust either tracks the lifetime of a naked pointer (similiar
to std::unique_ptr), or you wrap pointers in objects which facilitate
reference counting to track the lifetime (similiar to std::shared_ptr).

In the end both kinds operate on generic, unsafe raw pointers - safe only
thanks to ownership tracking and "boxing".

The only difference here is that Rust thankfully made it opt-out while C++
unfortunately needs to use opt-in.

But yeah... I'm eager to hear your explaination how Rust doesn't use those
stupid pointers. Maybe you can create a new computer architecture too? I mean
since x86 uses pointers and stuff. Maybe we should use garbage collected
languages for that, huh?

~~~
progman
> In your blind love for Rust you seem to forget that it in fact operates with
> pointers - everywhere.

I don't use Rust at all :-) I favor Nim, Haskell and Lisp. I am just pointing
to Rust as a better alternative to cc14.

> I'm eager to hear your explaination how Rust doesn't use those stupid
> pointers.

Only in embedded systems where direct hardware access, memory and performance
are issues pointers makes sense. In all other cases pointers are bad
programming style.

[http://words.steveklabnik.com/pointers-in-rust-a-
guide](http://words.steveklabnik.com/pointers-in-rust-a-guide)

~~~
AlexeyBrin
_I don 't use Rust at all :-) I favor Nim, Haskell and Lisp. I am just
pointing to Rust as a better alternative to cc14._

This is some quality trolling. How can you recommend something that you don't
use ?

~~~
progman
I used Rust for a while. _Now_ I don't use it because I discovered other
languages that work better for my current applications.

