CppCon 2018: Simplicity: Not Just For Beginners [video]

I don't think I tend to be a passionate anti C++ commenter, though I agree with the sentiment.

I've used C++ for around a decade, both professionally and as a hobby, in various domains. I use it because I either need (or merely want, in many cases) the control over the resulting end product that it provides.

The grievances are well known, and most are being addressed in some form, so asking random commenters isn't going to change anything.

But for what it's worth: it just feels like the language is a lost cause.

Everything is so irredeemably hard (without breaking back-compat)- from syntax/name resolution/template expansion, and the accompanying problems with error messages and tooling; to build systems and dependency management, and the impossible task of ever getting anything standard there; to memory+thread safety, where every solution is a partial bandaid and there's no light at the end of the tunnel.

It's a big, important, widely-used language. It's just not pleasant to work with- and while that can and will improve, it will always be tied to its rather painful legacy.

The complexity is just one part of the problem; the constant "fashion" churn --- largely community-driven --- is the other. It's really irritating to see so many changes in the language (and the horde of evangelists seemingly blindly pushing these changes and saying they're unconditionally better, which just smells like snake oil...) and the forcefulness that everyone should continually convert existing --- perfectly working --- code to whatever the current fashion is, when ideally the language should remain static, because I don't think a majority of its users have understood or can make use of most of the features of C++03 or even C++98 yet.

Having worked with C++ for over a decade, I much prefer C. C++ certainly has its useful features, but when I use C I find that I don't miss them much; and sometimes, especially when debugging, the "implicitness" of various things like automatic constructor/destructor calls are better made explicit.

As a rebuttal to the title of this video: "Hidden complexity is NOT simplicity."

> I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)?

I don't usually write negative comments about C++ but I sure sympathize with them.

I write C++ at my day job (and have for years). My team's codebase is in its teenage years. It's code-reviewed and has decent test coverage, but in many cases the author doesn't know C++ as well as the reviewer, and the reviewer is rushed / trying to not be a huge bottleneck, so stuff slips through. New code gets written to mostly C++11 standards (soon, mostly C++17) and the newest company practices. Old code...still exists...and the new code still has to use it. We've modernized some pieces but not as much as we'd like. Company-wide people do a pretty good job of modernizing a lot of the libraries we use, but my team hasn't kept up as well for various reasons.

I hate memory errors. They're super hard to track down. I've spent significant time doing so. Thank god for ASAN and TSAN at least.

I also don't like crashes in general; my service has to be quite reliable (some operations are critical to big parts of the company and have a 99.9995% success within a certain deadline). And fast, so I can't just rewrite it in Java or Go.

A few examples of the sort of foot-guns C++ has:

* Data races: no equivalent of Rust's Send+Sync auto traits.

* string_view/reference/pointer outliving their backing memory: no lifetime annotations. Even the new proposal for them is very incomplete.

* std::optional and equivalents dereferenced incorrectly: no pattern-matching syntax, the decision for the most obvious way to deference (operator*) to be undefined behavior instead of a crash.

I wish the whole thing were written in Rust. Then the parts I have to pay super close attention to would all say "unsafe" in them. That covers memory safety (including data races). I'd also know to pay pretty close attention to "expect" and "unwrap", which cover most (not all) panics. Of course, more mundane logic errors can exist in any language, but freedom from those problems would be a huge relief.

I can choose C or C++ in my workplace.

I prefer primitive rather than clever (i.e. pompous) solutions to problems and therefore choose C.

I also do not want to spend a significant portion of my time in the hallway discussing language features, as I hear many C++-choosers doing outside my office most weeks.

From this perspective, I could only be made happy with C++ if features were removed from it. I admit that I’ve hardly given the language a chance, but that is partly because I know I’ll make solutions even more pompous than the ones I’ve seen. I don’t think humans can help it.

Cannot edit my comment anymore, so am putting this here - wanted to thank everyone who took the time to reply. Signal to noise ratio in the comments was fairly high.

Some more interesting comments here: https://www.reddit.com/r/cpp/comments/9jwdpf/journeys_toward...

You can't make C++ simpler by adding more to the language.

They do it because C++ tempts you to strive for perfect expressive syntax and perfect efficiency at the same time. Most languages have limited expressive power (C, Fortran, Pascal) or limited efficiency (Haskell, ML, any JVM or scripting language), so you accept their limitations and move on.

C++ makes programmers become Icarus. Once they escape from the prison of C syntax, they try to fly higher, towards the goal of code that looks like Python but runs like C. They learn that template metaprogramming can help acieve this goal, so they use it. But template metaprogramming is actually the sun, melting their code into a pile of wax and feathers, sending them crashing back down into the ocean to drown.

Template metaprogramming is the most powerful feature of C++. It's true that the syntax is clunky, but since I started using templates, I've never looked back to the old style of coding. C++20 will be even more powerful by adding concepts to templates.

There isn't a defensible reason for untyped templates. Generics and concepts are a better design all around. It's not only error messages that matter: scoping matters more, as the problems with templates in that regard are the reason why C++ has the ADL mess.

Concepts are one of the most important features C++ needs.

Zero-cost abstraction. In most cases constructs in other languages either lack expressiveness (generics in C#) and/or induce runtime costs (boxing/unboxing, etc.).

The magic moment is when you realize that your month of pain writing something complex saves the company years of writing the simpler version by hand. In the template a fixed bug is fixed once and for all. In the other version fixing a bug in once place doesn't mean anything about anything else.

Note that for the above to apply you need have a domain where there will be enough uses to make the generic version worth it.

Of course, just like it is fun to write code for the IOCCC, there is some perverse fun in writing complex templates.

With regular inheritance, you affect behavior from the bottom up.

With the "Curiously Recurring Template Pattern", you affect behavior from the bottom up and from the top down.

To be honest, I don't know if it has value for most tasks people care about (outside of libraries, I mean). But it was fantastic for optimizing OOP-abstracted desktop applications. If you have some subset of functions that need to be called a lot, then avoiding virtual functions really helps.

I'd note that the nicer constructs you see in other languages were often based on people's experiences with C++. You can pretty clearly see some syntax and ideas copied into Java/C#, but it's true elsewhere as well. It's not surprising that newer languages learn from the past.

That said, almost all of those nicer variants do come with some added runtime costs. The general problem of making efficient generic code, without a bunch of boilerplate, and with a nice syntax, seems fairly difficult.

> you can often solve the problem with more verbose, but simpler code.

Sometimes. Other times, templates are simpler.

> I have the impression that people use it because they can

I think people use template metaprogramming because they see it in standard library, but they don’t understand the requirements for C++ STL were very different from the requirements of the code they’re personally developing.

I use C++ templates for following reasons.

1. For data structures such as custom containers.

2. For zero-overhead polymorphism. E.g. when I write algorithms that must work exactly same way with floats and doubles, or with char and wchar_t strings. Or for zero-overhead lambdas, putting them in std::function causes virtual function call overhead, lambdas are usually inlined.

3. For zero-overhead constants. There’s constexpr in modern C++, also modern compilers are good at propagating constants, but still a template argument is more reliable.

When I need complex metaprogramming, I often use other tools to generate the C++ code I need. On Windows it’s usually T4 templates with C# inside them, on Linux usually python. Compared to C++ templates, both T4 and python have much better support in IDEs (visual studio / PyCharm), including debuggers.

Templates make for the most abusively ugly code, at a glance. The syntax interpetaion to translate to natural problem-domain thought is so brutal.

Because it is the closest that C++ has to something like Lisp macros.

While it will never match the simplicity of Lisp, it is easier to get C++ accepted into most companies than Lisp.

And if one has access to a C++17 compiler, many tricks can now be replaced by more developer friendly constructs.

> Other languages have much simpler and nicer constructs and seem to work just fine.

If you mean ML/Haskell, then I agree.

If you mean other languages filling the same void then I don't. Idiomatic C++ uses templates: They're objectively safer than what preceded them, for one.

metaprogramming is useful (for the same reason programming is, computers are great at transforming data. your program is data and it can be much faster to write it with this in mind) and templates are an existing, portable way to do metaprogramming. despite how bad they are designed, that they already exist and are portable puts them in a position where they can be the most cost effective way to do something

Templates should be applied only when the problem obviously becomes simpler by employing them. You start from the non-template version and then you start to see a pattern emerging, and at some point you realize all that compmexity can be traded for another kind of complexity in the form of templates - and sometimes that trade is worth it.

> still don't understand why people bother with template metaprogramming

Speed.

She is one of the best speakers in the C++ community, really love her work.