Writing Good C++14 by Default [pdf]

https://github.com/isocpp/CppCoreGuidelines/blob/master/talks/Sutter%20-%20CppCon%202015%20day%202%20plenary%20.pdf

by adamnemecek • 11 years ago

121 81 11 years ago

Tobu2• 11 years ago

A direct link might work better: https://github.com/isocpp/CppCoreGuidelines/raw/master/talks...

adamnemecek2• 11 years ago

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.

pjmlp6• 11 years ago

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

Tobu2• 11 years ago

It didn't render on my mobile.

nosnos2• 11 years ago

Thank you! That pdf renderer is unbearably slow on firefox.

progman6• 11 years ago

"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

adamnemecek2• 11 years ago

Honestly I needed to read the C++98 code to understand the modern one.

Was that your first time reading C++14? If so are you surprised that there was some learning curve?

Do other modern languages still operate with pointers?

As much as I'm rooting for Rust to succeed, C++ will be around for quite a while longer so it might be a good idea to make it a bit friendlier.

progman6• 11 years ago

The problem with modern C++ is that people stick to their programming styles. Many will use some of the new good features but they will also use the old ones (pointers!) because it's so easy to use them. Rust however forces people to accept new programming styles because the legacy ones (pointers!) are not appreciated.

okamiueru• 11 years ago

What do you mean by having to "read the C++98 code to understand the modern one"? Isn't this how "here is the new way of doing it"-examples work? Until you don't know it, of course you will need to read whatever version you do know. The point is that once you do learn it, you can use it.

And "inherited waste is obvious"? If you mean to say that it carries a lot of historic luggage, and you feel encumbered by it, then geez, the document in question was almost tailored for you.

C, D, Go also have pointers available. And, to be honest, thinking that pointers are "obsolete" suggests lack of understanding.

You know what, all your points seem to be against C++. A typical language evangelist.

progman6• 11 years ago

And, to be honest, thinking that pointers are "obsolete" suggests lack of understanding.

Who has lack of understanding? Rust proves that pointers are not actually necessary anymore.

You know what, all your points seem to be against C++. A typical language evangelist.

What is wrong about C++ criticism? I was a professional C++ developer for a long time but now I am really glad that I don't need to maintain any C++ anymore. At the beginning C++ was real joy of programming but now it has grown to something which I don't like anymore.

There are other really modern languages much more clean and almost as performant as C++. Rust and Nim for instance. In Nim I am much more productive than in C++.

arcticbull2• 11 years ago

I think what makes C++ so challenging for me isn't C++98, C++11, C++14 or whatever comes next. The challenge for me is that I need to know the superset of all the features (and past 'features') at the same time, doubly so to interoperate with existing code or libraries.

The more gets layered on without taking anything away the more difficult it is to reason about your code let alone that of anyone else. And without taking anything away, all the cool new features can't defend you at all, they're just more rope.

The challenge for me is just how much context C++ forces me to hold in my head at any given time. And thanks to operator overloading, I can't trust anything I see -- when you can change the meaning of the comma operator, any piece of code can do literally anything other than what it looks like.

Ultimately, I stopped developing in C++ because there's just too much cognitive load for me. In a professional setting you're not coding for yourself, you're coding for you 6 months from now, and that guy has know idea what kind of tricks you were playing back in the day.

pjmlp6• 11 years ago

And thanks to operator overloading, I can't trust anything I see -- when you can change the meaning of the comma operator, any piece of code can do literally anything other than what it looks like.

I always laugh at this complaint specifically against C++.

Except for Go and Java, all other mainstream languages allow for either operator overloading, or symbolic names for functions/Methods.

Even JavaScript ES7 might get them, http://51elliot.blogspot.de/2015/01/fluent-talk-summary-bren...

fauigerzigerk4• 11 years ago

That's all true. But there's a dilemma we can never completely avoid. The more expressive power a language gives you, the more productive you can be when you really know the code in and out. The same expressive power will make it more difficult for others or for your future self to understand what the code does.

It's always going to be a trade-off. The more focused you are on one piece of code, the more it makes sense to use an expressive language. The more you switch between projects, the greater the developer turnover, the dumber the code needs to be in order to stay close to maximum productivity.

If we really want to have an impact on productivity, we need to change how teams are put together and stay together.

rcurry• 11 years ago

C++ is the monkey's paw of programming languages. Sure, it'll grant your wishes, but you'll end up paying some terrible price for it in the end.

nosnos2• 11 years ago

How is this different with every other language? At least C++ is being maintained gracefully so one could update it with newer ways of doing the same thing and still work versus a language that is dead and you're stuck leaving it or reimplementing the program completely in something else. Or you're using a language that is new and version 0.6 completely breaks 0.5 so you can't ever upgrade without rewriting parts of it and yeah, you should upgrade because 0.5 has some horrible security vulnerability.

lhecker• 11 years ago

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?

progman6• 11 years ago

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

jerf• 11 years ago

In the end everything is "unsafe" assembler. "It's all unsafe if we penetrate the abstractions!" is basically "Everybody's naked under their clothes!" Yes, true, but profoundly irrelevant.

Safety is added by the higher layers. If Rust has pointers that are ownership tracked, then it is incorrect to think of them as raw pointers; they are safer than that. Safety is attained by creating compilers/runtimes/interpreters that can not be convinced to execute certain patterns of assembler code, or perhaps require rather explicit labeling.

flohofwoe5• 11 years ago

You can just as well write large pieces of C++ without using pointers or heap allocations at all. In fact this is considered 'good style'. As soon as you have stuff living on the heap, Rust also needs (smart) pointers to track these heap objects, and the compiler is clever enough to guarantee compile-time safety (although I guess this is the main reason why compilation in Rust is so slow), while in C++ these checks are done at run-time (of course compile time checks would be better).

kibwen3• 11 years ago

Tracking ownership doesn't make the Rust compiler slow. Compiling Rust is already faster in general than compiling C++ (where the lack of a module system and code explosion from templates is absolutely killer), with the caveat that the Rust compiler hasn't yet implemented incremental recompilation and so subsequent compilations can be slower than subsequent compilations in C++ if your C++ build system is reusing artifacts intelligently. Incremental compilation in Rust is slated for after the middle-end overhaul which is currently ongoing.

steveklabnik3• 11 years ago

Hi. Please note that that blog post has a very prominent "Rust versions 0.8 - 0.9" on the top. Almost nothing in that post is accurate at this point, even the stuff that is has different terms now.

Also, if you don't use Rust, and do use nim, please use nim in these examples in the future rather than Rust, please. Otherwise, you make inaccurate comparisons, like you do here.

kamac2• 11 years ago

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.

flohofwoe5• 11 years ago

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)

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

fauigerzigerk4• 11 years ago

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.

uxcn• 11 years ago

    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.

Clang/LLVM are meant for this. I haven't personally written anything that parses the AST yet, but there are tools that do (clang-modernize, clang-format, YCM, etc...).

What I think some people are overlooking is the practicality of C++. From a language standpoint, there are various inconsistencies, multiple ways to do things, arguably dubious design choices, etc..., but there isn't a genuine reason those can't be avoided.

I personally would probably prefer writing all my code in Haskell, but C/C++ is still vastly more productive.

stinos• 11 years ago

once you poke the ball, you'll be hit by the stench of the rotten meat inside

The whole point of this article seems to be to teach people to by default not poke the ball, unless really really needed, and in such caes do it while wearing a proper mask.

Which is not ideal (that would indeed be to start over I guess), but given the current situation probably the best they can do.

kamac2• 11 years ago

The whole point of this article seems to be to teach people to by default not poke the ball

And it's sad that they have to teach people not to poke the ball and reveal the inner decay, rather than remove the rotten meat itself.

rootlocus• 11 years ago

I love this metaphor. I've been trying to explain to people that the new c++ is just another layer of features on top of the old language. You can't learn c++ by just learning the last layer added.

Modern C++ is just a subset of the language, and nothing prevents the old language from popping up everywhere.

tmaly• 11 years ago

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• 11 years ago

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.

lorenzhs• 11 years ago

I haven't actually tried it, but clang's C++ Modernizer tries to automate some of the boring manual tasks in bringing old code up to speed (such as using nullptr instead of NULL or 0, or more the for(T x : c) loop construct). See http://clang.llvm.org/extra/clang-modernize.html (integrated into clang-tidy now)

tempodox2• 11 years ago

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• 11 years ago

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?

tempodox2• 11 years ago

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

criddell• 11 years ago

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.

flohofwoe5• 11 years ago

As the old saying goes: "There are languages that everybody complains about, and there are languages that nobody uses" ;)

tonyarkles2• 11 years ago

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• 11 years ago

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?

yeureka• 11 years ago

You are not alone.

It is my favourite language for large scale and high performance projects.

blub• 11 years ago

I like it too and I'm happy to be using C++11 for software development.

It's mature, standardized, cross-platform and has a good tool & library ecosystem. When it comes to shipping something, I'll take C++ any day over the language that just turned 1.0 or the other one which doesn't have a debugger and can barely optimize. I guess there are those non-sexy languages you use to get stuff done and the ones you blog about.

corysama2• 11 years ago

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.

steveklabnik3• 11 years ago

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

corysama2• 11 years ago

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.

Writing Good C++14 by Default [pdf]

Related Stories