C++ Has Become More Pythonic (2014)

[nv-vn]

None of these ideas seem outright specific to Python and I don't think it makes sense to attribute all these changes to Python influence. C# and D, for example, have had most of these features for a few years. One could just as easily say "how C++ is becoming Haskell" or "how C++ is becoming Go" (both of which have many of these features). I think a better title for this would be something along the lines of "Python idioms in C++".

[brianberns]

I would say that most of the features in the article (e.g. lambdas) originated in functional languages, not Python. Static type inference, in particular, comes from the functional world. Python's dynamic typing is completely opposite.

[coldtea]

>how C++ is becoming Go

Hmm? Go has almost none of these features.

[incepted]

> C# and D, for example, have had most of these features for a few years

Come on, now. D is 15 years old, C# 16.

Python is more than 25 years old.

[Negative1]

This is the kind of broad generalization that someone that knows a lot about Python but very little about other languages would make. The truth is most of these features have existed in other languages for many years, before C++ adoption and in some cases, before Python adoption.

[sklogic]

Not in "some cases" but in "all cases". Python did not introduce anything new in this list.

[massysett]

auto is type inference. That's not "pythonic", that's something that statically typed languages have had for decades. Indeed, it's nothing like Python, where general practice is to pass around things derived from Object and depend on runtime typing failures.

There's also nothing Pythonic about lambdas. Come on, lisp is ancient and it has lambdas.

This article essentially says C++ got stuff that has been around for decades, and Python has stuff that vaguely resembles them, so C++ is learning from Python.

[catnaroek]

`auto` is just bottom-up type derivation, not really type inference. Type inference lets you recover the type of a variable from how the variable is used, not just from how it is initialized. Implementation-wise, bottom-up type derivation only requires unidirectional type propagation, whereas type inference requires solving arbitrary systems of type equations. The former is a special case of the latter, where all equations are of the form “X = T”, where “X” is a type variable and “T” is an arbitrary type expression.

No type inference: http://ideone.com/fmm92M, http://ideone.com/HzyM2E

Type inference: http://ideone.com/0Gv8fV, http://ideone.com/r9nHUF

[cwyers]

The lambdas one is the one that got me - the best word I can use for Python's lambda support is "grudgingly."

[fndrplayer13]

As a developer who used to build systems in embedded C++ and now spends all of my time building web backends in mostly Python, I have to agree with the premise that C++ is becoming more influenced by Python. That's a good thing, I think. I really think C++ is a wonderful language if properly curated and used by a responsible team of developers.

One tiny thing that would be cool to see built into C++ would be an equivalent to the Python range function. The boost version is nice for now, though.

Finally, I also see this as a nice compliment to Python and the power that it offers as a language.

[sklogic]

I do not think there was a single bit of a Python influence in C++ design. People behind these changes are all seasoned PL researchers and they have far better sources of inspiration than just a poor little Python.

[eplanit]

"As a developer who used to build systems in embedded C++ and now spends all of my time building web backends"

I'm curious, what motivated your switch from embedded to web?

[hliyan]

I wonder if all these languages features are really necessary. I used C++ during the first ten years of my career and what I missed the most were better standard library features and more third party libraries (we used to write everything ourselves).

Language features are nice to have, but I never really missed any specific feature. Almost every sort of syntactic simplification I wanted to achieve, I could do so with a function, class or a template.

[hendzen]

See the range_v3 library, which is on it's way (albeit slowly) to becoming part of the C++ standard. It provides C++ versions of range, as well as most of the iterator combinators in the itertools library.

[netheril96]

After C++11, the bottleneck of the speed of development in C++ is no longer the language. But it has numerous other problems dragging down C++ developers still: std::string is close to useless, no userspace and project-scoped package manager, too long build times, hard to debug templates, etc.

[catnaroek]

> too long build times, hard to debug templates, etc.

These are symptoms of language issues.

[adamnemecek]

Idk dude, after programming in swift for some time, I feel like c++ can't really become a modern language.

[nhaliday]

Preshing is a smart guy but this seems to miss the point in a way typical of C++ devs. Python—as with other languages—isn't just a list of features. It also has a guiding philosophy (made explicit in Python's case in https://www.python.org/dev/peps/pep-0020/).

C++ doesn't seem to have a guiding philosophy besides "be a Swiss army knife backwards compatible with C." That's OK but I would argue it prevents C++ from every being "Pythonic."

[pjmlp]

There are many cultures inside C++, but they basically spit into two.

There is the one that appreciates C++'s abstraction capabilities with ability to go low level when needed. Cares about writing safe code and sees C copy-paste compatibility as a compromise required to get C++ adopted by the industry. Those developers usually appreciate languages like Ada, Modula-3 and Haskell, and would rather kill the pre-processor.

Then there is the culture that somehow had to move from a C compiler into a C++ one, constrain themselves to the C subset of C++ while ignoring the standard library because bloat and write exploit sensitive code as always did in C.

Many on the second culture tend to do micro-benchmark driven development. Each code line is questioned how much fast and memory it takes by gut feeling, without any regard from profiler tools or actual needs from the application users.

[fauigerzigerk]

If there is one guiding philosophy that C++ has it's abstraction without runtime cost.

The (implied) corollary is that compile time cost, mental cost and social cost of language features do not matter.

As long as there is at least one person on the planet who really understands the ins and outs of a language feature, that is sufficient proof of the language being simple enough. There is no need for anyone to understand the entire language.

[sklogic]

C++ got a much stricter guiding philosophy than the Python zen. This is it: "you should never pay for the features you do not use". The entire language is built with this guiding principle in mind.

[santaclaus]

> That's OK but I would argue it prevents C++ from every being "Pythonic."

This got me thinking, what would one call an idiomatic C++ style (which I suppose is part of what the core guidelines are trying to push)? Cppthonic? Bjarnic? Python is 'Pythonic,' I usually hear idiomatic Ruby described as the 'Ruby Way.' Is idiomatic Rust 'Rustic'?

[discardorama]

I'm sure I'm not the only one who doesn't like how these things are bolted on and shoehorned into the existing constructs, resulting in some ugly-ass syntax. Consider:

  auto triple = std::make_tuple(5, 6, 7);
  std::cout << std::get<0>(triple);

Ugh. And don't even get me started on "myList.push_back(5)" . "push" usually means "add to the front"; why not use "append" ?

[leetrout]

Sigh - I know why you got downvoted but I came to post the same thing. I don't program in C++ but specifically the

std::get<0>(triple)

It really doesn't look great. It looks like the template syntax using the <>. I'm sure I would get used to it if I were using it every day but from an aesthetic sense it doesn't win me over.

[SamReidHughes]

In Perl, "push" means "add to the back."

[vitaut]

Also C++ has Python-like formatting: https://github.com/fmtlib/fmt. Disclaimer: I'm the author of this library.

[jordigh]

It certainly has for me.

Here is me translating as literally as I could a bit of nontrivial code (which I originally learned from R's C code):

http://inversethought.com/hg/medcouple/file/default/jmedcoup...

http://inversethought.com/hg/medcouple/file/default/medcoupl...

I'm really happy how almost every Python statement has a nearly equivalent C++ statement. The only one I had trouble with was list comprehensions, but they can be very nearly translated with C++ stdlib algorithms and a few lambdas (kind of looks more like map and filter than a list comprehension, though).

The best part is that the C++ code runs as fast and sometimes faster than the original C code I grabbed this from! (The translation path was C -> Python -> C++.)

[Animats]

It's nice to have a "do this to all that stuff" FOR statement, at last. Remember what it was like declaring iterators over collections in FOR statements before AUTO? That was the original motivation for AUTO. But it's much more useful than that. It becomes the common means of declaring local variables.

[catnaroek]

You could always use `std::for_each` and Boost.Lambda, even before C++11.

[wglb]

Props to python.

However, what idea has C++ not accepted? It seems for it to be a "new" language, it should at least say "no" to something.

[smcameron]

C++ says "no" to readability. Everything that has been added to C to create C++ was added in order to help out the person writing new code. Nothing that was added to C to make C++ is there to help the person trying to read the code. Though I doubt it was deliberate, much of what makes C++ different than C seems actively hostile to the person trying to read the code.

[Tyr42]

It doesn't have yield.

It also doesn't have Concepts yet, as they got pushed back again.

[byuu]

> With range-based for loops, I often find myself wishing C++ had Python’s xrange function built-in.

Built-in to the language would be nice, but C++ is always extremely spartan with its standard library functionality. Thus:

https://gitlab.com/higan/higan/blob/master/nall/range.hpp

37 lines (without the boilerplate header stuff) and you have:

    for(int x : range(20)) ...;  //iterate from 0 ... 19
    for(int y : rrange(myvector)) ...;  //iterate from myvector.size()-1 ... 0

Also supports xrange's offset/stride arguments (it's pretty much exactly Python's xrange object in C++.) And you can add support to do ranges over any class anywhere, eg range(myvector) will pull the length from myvector.size() for you with a simple overloaded function.

Timing tests in extremely critical loops (like convolution kernels eating 100% CPU usage) shows no discernable performance impact at -O2 and above over the traditional C++-style for(int x = 0; x < size; x++) style.

[twiceaday]

I'm still waiting on Pythonic iterators (e.g. coroutines).

[cheez]

http://www.boost.org/doc/libs/1_60_0/libs/coroutine2/doc/htm...

[wmil]

I'll never understand why some people insist on backslashes in paths on Windows.

Windows APIs have always supported using forward slashes, using "C:\\path\\to\\file" is just an ugly mess.

[Quiark]

It doesn't work everywhere, 3rd party libraries would have trouble for sure and I think I had some issues even with Windows or some highe-level Microsoft API too.

[ioab]

those are amazing features I didn't expect C++ to have. I wonder if 'auto' is similar to type inference 'var' in C#.

[catnaroek]

C# does not have type inference: http://ideone.com/fmm92M. Nor does C++ for that matter: http://ideone.com/HzyM2E. This is type inference: http://ideone.com/0Gv8fV, http://ideone.com/r9nHUF. Note how the type checker figures out the list's element type from how the list is used.

[sklogic]

Funny how Python narrows the perspective of its practitioners. To brand as "pythonic" all those decades old concepts that had been well known and widespread long before Python is, well, among the most amusing symptoms of a fanboyism.

[cLeEOGPw]

I think Python's, along with languages others mentioned here, popularity is what influenced and partly driven the rapid change of C++. Lisp was around for decades, yet only now, almost right after Python became popular, these old concepts were incorporated.

[conceit]

The problem is that Pythonicity is exclusive. If the features mentioned do correspond between the languages, that's a common property. Although, C++ couldn't be pythonic, if pythonicity describes the necessity to use these features.

[21]

I would like to borrow some simpler syntax from Python:

"if (a)", "for (...)" -> "if a", "for ..."

"if ((a > b) && (c > d))" -> "if a > b and c > d" (yes, I know C++ supports "and" if you wish)

Or how about accepting a new-line as a ; at the end of a statement (ie: optional ; at line end)

I also love nested tuple unpacking: "for i, (key, value) in enumerate(dict.items())"

[GFK_of_xmaspast]

> Or how about accepting a new-line as a ; at the end of a statement (ie: optional ; at line end)

And have to use backslashes or something for multiline statements? Ugh.