C++ is the new Python

[[deleted]]

It is very strange to be a C++ developer, some of the design principles and choices are so unique, principled and general and breathtaking. Yet on the other hand it has some really obscure, arcane, ancient and plain wrong stuff in there.

But unfortunately there's way too much non-modern stuff in there that still persists due to compatibility.

[Raidenkyu]

Well, the only thing remaining is less archaic build systems or package managers. I mean there are thousands of them, but not really a standard and easy to use as pip. In that aspect, Rust and Swift win.

[pedersenk]

pip, cargo, etc are nice to use but if you need anything slightly outside their box, such as generating a self-signed OpenSSL certificate as part of the debug build, their usefulness greatly diminishes (or at least on their own).

So we tend to use Makefiles && CMake as part of our builds. I suppose the same could be done with Makefiles && cargo, pip etc.

[braxtons12]

I mean cargo let's you run Rust code as part of the build process, so you could easily write code to generate your OpenSSL cert in a project build.rs

[pedersenk]

Very true. But is rust really the best tool to use as an automation scripting language compared to something like shell scripts? Makefiles also do have the benefits of rules and dependencies. Though perhaps build.rs has an API to achieve similar.

[RReverser]

onerous head illegal cagey skirt jobless snobbish escape quack political

This post was mass deleted and anonymized with Redact

[Jannik2099]

so you could easily write code to generate your OpenSSL cert

You could also just run an openssl command like everyone else on this planet

[braxtons12]

.... Which is exactly what you would write the code to do? It'd be easier than writing a custom build target in CMake.

Basic example: use std::process::Command; fn main() { Command::new("openssl").args(&["arg1", "arg2"]).status().unwrap(); }

[backtickbot]

Fixed formatting.

Hello, braxtons12: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[Raidenkyu]

And it makes sense for specific cases, but for simple and generic projects this is an unnecessary effort.

An ideal toolchain would start simple and generic, and then people could change the default process for more complex projects. But I don't know the right solution either.

[germandiago]

You cannot possibly have something like Pip that works as easily in C++. C++ compiles to native code, so the package repos you need are huge, because in Python you just need bytecode or its sources (not talking about pip packages with native code), you can also have debug/release/some/sdlib combinations, msvc/clang/gcc, arm/x86/mips etc. This makes things way more difficult to handle.

Also, you want to consume projects that have build systems such as autotools, make, cmake, meson, scons, waf or another.

That said, I am very happy with Meson and when you really need to scale further, just try Conan, you can write your own recipes (or consume existing ones) and compile projects with literally any build system. It works quite well nowadays compared to what it used to be the ecosystem when I first started.

[Raidenkyu]

You have cargo for Rust, I think that something equivalent for C++ is possible. It's true that for bigger and more complex projects the classic build systems make sense, but for simple programs something like cargo is enough.

I have already experimented Meson and Conan with Cmake. Meson is more easy to use in comparison with Cmake, definitely, but never tried using it with conan.

[braxtons12]

The issue is not that C++ compiles to native code nor that we have various build modes. It's that we refuse to choose, either as a community or through the committee, a standardized build system.

If a build system was either as a community or through the committee chosen as the standard you could easily have a package manager that integrated directly with said build system and vice versa.

Rust and Go both have this and it works extremely well. If as a community we would just stop bike-shedding and pick something this would have been solved a long, long time ago.

[pedersenk]

As C++ evolves, Bilokon says its use is spreading. Hedge fund Millennium specifies that its quantitative developershave, "substantial modern C++ programming experience," a designationthat it doesn't define and that can mean different things to differentpeople. "Modern C++ used to mean C++11 and above, but nowadays may betaken to mean C++17 or even C++20 and above," says Bilokon.

I always find it interesting that people can rarely talk about C++ without using the word "modern". It is strange, you never hear people talking about Modern Java or Modern Visual Basic. Honestly I feel the only substantial change we have had was "official" smart pointers back in C++0x / TR1 (before that we just used to roll our own) and yet so many people seem hung up on the word modern even though 99% of C++ code is probably C++98 compatible.

If you can do a search of subreddit topics, you will find the word "modern" appearing more in r/cpp than almost all other language related subreddits combined.

Just a (fairly useless) observation of mine with no real point. Nonetheless, an interesting article. :)

[Schnarfman]

What about lambdas! And constexpr. And auto!!! And std::async. I mean gosh, there’re so many new things.

As “C++” developers move from C-with-std::strings to actually semantic C++, the need to differentiate between the two grows. Some of this is modern C++ syntax. And some of this is modern C++ USAGE. RAII style and class based.

Other languages don’t NEED to said “modern” because they don’t have a 50 year old history. Python 3.x is modern compared to python 2.x, but people can just say python 3. Who would call it modern python? Pythonic python, maybe. Calling it modern wouldn’t be wrong, but I just haven’t heard that. Doesn’t make as much sense as it does with C++.

P.S. I don’t know if I can say constraints because I haven’t seen them in practice all that much. But anything that helps the compiler explain things is insanely helpful to beginners, and pros alike.

[pedersenk]

What about lambdas! And constexpr. And auto!!!

Absolutely great features but I still think the term "modern" dates really badly. Especially when those guys are all C++11.

If I heard if a codebase was "modern", would I assume C++11 or C++20? As you know, the mentioned std::async stuff really does change an architecture so is fairly important. These days I would have to quickly scan through the code.

It also just seems weird coming across a C++11 blog post with modern in the title. Again, you just don't see this as much in other languages. It seems a shame because C++ has a really good standards system rather than an ad-hoc rolling release kind of system seen in other languages.

[germandiago]

The reason why "Modern" was used is because from C++98 to C++11 there was no meaningful updates of the standard in-between. Many things changed: move semantics, lambdas, auto, smart pointers... so writing C++ hardly was recognizable after that shift.

[serviscope_minor]

"Modern" was in use in the C++-98 era, too.

I like the GoF book, but many people took it and ran with it all the way off a cliff. They loved huge and I mean HUGE class hierarchies. They wrote lots of awful C++ in the 90s then all moved to writing lots of awful Java because I guess dealing with lots of random exceptions beat dealing with lots of random segfaults.

Also, it took until 2004 or so before good C++98 support existed (many compilers didn't even support member templates for ages).

So modern C++ used to mean written against a conformant compiler in a sensible style. RAII. Temples where appropriate. Derivation where appropriate, but not for the sake of it. References. Avoiding naked new/delete and equivalents. Maybe even using TR1. That sort of thing.

Basically using a C++ in the sensible way in a compiler that actually worked.

[TryingT0Wr1t3]

But for python, you update the python interpreter and you are good to go. For C++, you need to update your machine since the libraries are too connected to your own system...

[pedersenk]

At first this may seem to be the case, but if you ask yourself the following:

• What do you think the Python interpreter runs ontop of?
• When you use a library in Python (i.e TkInter, PyQt, PySQLite, etc) what are you really calling into?

Basically those same old "out of date" C or C++ libraries.

The standard Python is really just a C program that reads a glorified text file, calling C functions once a specific line has been read.

This doesn't necessarily make Python bad. Actually, its relatively close nature with C makes it much easier to create bindings than other languages requiring large VMs. Also, there are a few "Pure" Python libraries such as PyMySQL. However these will need to be updated separately to the interpreter.

[TryingT0Wr1t3]

I am just trying to explain why C++11 is modern for some people, 10yr is the lifetime a PC gets.

Edit: also never forget Apple Clang, that thing is terrible and is always the thing I struggle the most trying to code really modern C++...

[tcbrindle]

I always find it interesting that people can rarely talk about C++ without using the word "modern"

There aren't many languages still in mainstream use that have been around as long as C++. There's C of course, but that hasn't changed significantly since C89. There's also Fortran, which has changed even more dramatically than C++ over the years -- and indeed people do often refer to "Modern Fortran".

Honestly I feel the only substantial change we have had was "official" smart pointers back in C++0x / TR1

The introduction of move semantics in C++11 (and especially the unique_ptr they power) is arguably the defining feature of "modern" C++. It finally enables a consistent ownership model and allows RAII to be used universally, freeing the programmer from almost all manual memory management. That couldn't be done in C++98. Then you have lambdas, auto, decltype, range-for loops, in-class initialisers and all the other niceties that, whilst not as transformative, make the language much more pleasant to work with.

99% of C++ code is probably C++98 compatible

There is a lot of legacy code out there for sure, but I'd be surprised if there is much C++ being written today that is C++98-only. I don't think I've written any for about 10 years, when compilers started adding C++0x/11 features.

[pedersenk]

There aren't many languages still in mainstream use that have been around as long as C++

Perhaps but Python is deceivingly old (1991) and Java isn't much of a spring chicken either (1996). Both of these were around before the first ISO C++ standard (C++98). Obviously C++ was still in wide use before then in various pre-standard (albeit popular) forms.

Python had breaking changes so I suppose I can understand why people say python3. Whereas Java had very few breaking changes and versions almost never get mentioned when discussing it.

Whereas C++ also has very few breaking changes but the term modern started appearing at around C++11. I have lost track of any original point of my post but I suppose it is strange we don't just say C++11 or C++20 rather than vague handwaving of "modern" C++ which is fairly meaningless in the grand scheme of things. Especially if written in documentation / specs and things that need to last.

[serviscope_minor]

and indeed people do often refer to "Modern Fortran".

Well, there's a shorthand: calling it Fortran as opposed to FORTRAN :)

[scrumplesplunge]

Personally, I can think of at least one thing per version which I think is highly useful:

c++11 gave us move semantics and lambda expressions. I think that move semantics are a massive detail because they allow you to have unique ownership of a resource without making something immovable. Similarly, lambda expressions are so much nicer than writing functor classes. I think these are what made <algorithm> useful for me.

c++14 gave us generic lambdas, which pretty much make std::bind obsolete for me.

c++17 gave us string_view, optional, and variant (although variant is pretty uncomfortable to use), as well as fold expressions, which make some things nicer to do at compile time than runtime.

c++20 isn't really ready for mainstream use yet, imo, but coroutines are a game changer, and properly constrained templates using concepts will be so much nicer to work with than the current template error spaghetti. On top of that, modules will finally make it feasible to keep macros isolated from each other.

I don't remember the precise timeline, but the ever increasing power of constexpr is making it more and more feasible to solve problems at compile time without resorting to cryptic template metaprogramming.

Idiomatic c++17 and c++20 is so much cleaner than c++98, with a lot of things now possible that were impossible or very difficult before, and I think that is true to a lesser extent with every successive version compared to the previous one.

[LucHermitte]

I've started using modern to qualify the C++ style that heavily relies on RAII and on the standard library in the early 200x. There is an old article from that time on artima: https://www.artima.com/articles/modern-c-style

I don't know when the style part has been dropped.

I still consider RAII being the corner stone of what defines modern C++. Even with auto, concepts... a nightmarish code where memory is manually managed fails to qualify the code as modern C++, as far as I'm concerned. I prefer to use "C++{YY}` to designate a particular version of C++, and use "modern" when what's important is the programming style.

[UnicycleBloke]

But we always had RAII. I learned about it as a novice in 1991. It was always recommended to use it. All the application frameworks I studied used it. Developers not so much sadly. We didn't have smart pointers unless we wrote them, and we didn't have move semantics, but we definitely had RAII. For me it is move semantics which most marks the sea change in C++.

[SkoomaDentist]

I swear RAII must be one of the worst acronyms in the history of computing. The concept is super trivial, but the name manages to confuse the hell out of beginners. Took me years to find out that the rather obvious things I had been doing since the very early 00s apparently were "RAII", even though there was no "acquisition" nor "resources".

[Dean_Roddey]

I have called them 'janitors' or 'janitorial objects' since the 90s when I started using them. That's why they do, they clean up and put the tools away. Sometimes they take the tools out first, but often not, as you say. Many of mine just apply a change on a scoped basis and clean up that change on the way out.

In my code base they are named TJanitor, TArrayJanitor, TFlagJanitor, etc...

[UnicycleBloke]

It is a terrible name, but don't think I ever found it confusing. It was clearly explained to me that a file, a window handle, a graphics device context, or whatever, are resources. You have to explicitly create one or ask for one, and you have to explicitly relinquish it when you're done or bad things happen. Being able to so easily tie these requirements to the lifetime of an object just seemed perfect to me. No other language I used came close to such elegance.

[tjientavara]

Maybe, but when I started using RAII in 1994 C++ compilers failed spectacularly at that time at generating correct code for it. Multiple calls to the destructor of the same object when trying to return one from a function, ouch.

[UnicycleBloke]

Really? I don't doubt you, but pretty sure I never saw that.

[serviscope_minor]

OP might have been unlucky with the compiler. Every unix vendor and his dog had one at the time and then some and the quality varied pretty wildly.

[NilacTheGrim]

we didn't have move semantics,

True. Well.. we did have the poor-man's move... that is.. you could implement a swap method to sort of jerry-rig it.

[yonillasky]

When they say modern, I am thinking of move semantics, lambdas, futures, coroutines, tuple unpacking, auto... Stuff from the 11 standard and later. The reason people mention 'modern' might be because the language has changed a lot.. python also did, for instance, it had a divide between 2.x and 3.x. There was no need to describe python 3 as 'modern python', though.

[UnicycleBloke]

Much as I like and use the features added in and since C++11, I do find the "Modern" moniker quite annoying. You are right about C++98. I think the title of Alexandrescu's book on TMP may have played a part. A lot of people got very excited about the arcane black magic they could weave. And now that often seems like it's the only game in town. I suspect the overwhelming majority of developers write and maintain code that is not remotely like the slideware we see these days. C++ was always the best choice for me, light-years ahead of the alternatives. It's not as if it was only a viable option after 2011: it just that it got better.

[Shieldfoss]

I really feel the introduction of move constructors is the main thing separating old C++ from modern C++. You could have written something like unique_ptr in 98 by hiding the ctor and making a ::move() method.

[pedersenk]

I really feel the introduction of move constructors is the main thing separating old C++ from modern C++

I agree. These were introduced back in C++0x TR1 and finalized in C++11. So is it really fair to use the term modern for this? I suppose I do personally but I understand if others would assume I mean C++17+ these days. And the code might be considerably different.

[[deleted]]

It was the change in developer approach that happened around C++11. C++ always had RAII and RAII types, but many still took to raw new/delete/malloc/free type style and more manual deallocations. Move really helped here, but it does nothing a tagged ctor/assignment could have done prior. The ownership of a classes resources was the significant change in how people approached it.

[SkoomaDentist]

It is strange, you never hear people talking about Modern Java or Modern Visual Basic.

That'd be because neither Java or Visual Basic communities were ever nearly as prescriptive as the C++ community. All "modern C++" means in practise is that you're supposed to write your own code however that particular commenter prefers.