[khedoros1]

They sound like they're echoing the kinds of things that are normally said about C++11.

> I agree modern C++ is nice but it's the same language still.

Well...in the same sense that any language is the same language after you add a bunch of things to it that weren't there before and shift to using those new features as idiomatic parts of the language. I would expect C++ written in 2004 to use different patterns than C++ written in 2017. Not "completely different"...but different.

[fsloth]

Idiomatic sounds like preference to dogmatism rather than pragmatism which is generally the worse tradeoff.

I would say generally C++ style has evolved through last decades with people understanding class based architecture as an antipattern and data pipelines based on preferably immutable data as the more robust and understandable approach. This has nothing to do with language standards or 'idiomatic' constructs - both can be expressed as perfectly elegant C++, using the '98 or '11 or '17 variant.

But anyway, within this context - refactoring old code - I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++. This is the main reason I find the claim of methods to understand circa 2004 C++ to be outdated to be silly.

[khedoros1]

> Idiomatic sounds like preference to dogmatism rather than pragmatism which is generally the worse tradeoff.

That's never been the way that I've read it, and it's not how I meant it. New language constructs allow for more-natural ways for the code to express the intent of the programmer, replacing the use of older constructs in the places that they were clumsy.

The entire point is to make the language more practical. Patterns of use in a language aren't idiomatic because of dogma (or at least, they shouldn't be). They're idiomatic because they're a clear and elegant way (or at least the most elegant way available) to implement something.

> I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++.

Agreed, but then we come back to the fact that we might refactor a 1997 codebase differently in 2004 than in 2017.

[fsloth]

"Agreed, but then we come back to the fact that we might refactor a 1997 codebase differently in 2004 than in 2017."

Well, if the original code is of the worst kind of a mess, Feather's circa 2004 collection of methods to make it more understandable but functionally the same work just fine for the first part of the refactoring. In my experience this is the most difficult part as well. To what dialect of the language the code is ported after it is understandable, is a relatively trivial syntax transform after this.

I speak from experience from having recently had to implement features to a production codebase with millions of lines of code, some of which date back to Fortran, and that took the final step of evolving into C++ sometimes in the late 90's.

I prefer the definition of legacy code that it's any code that does not have unit tests. In this case every transformation to a production codebase needs to retain the original behavior - without exact understanding what that behavior is.

I think this comment should have been my original response to this thread instead of the relatively cheeky responses I wrote earlier.