Hacker News Reader

Comment by zabzonk | Hacker News Reader

Maybe just me, but doesn't most C++ code being written today not use inheritance very much, and so make virtual dispatch moot?

View on HN

Only on conference slides maybe, real production code looks quite different, including game engines like Unreal and Godot.

CUDA frameworks, V8, LLVM and GCC, you name it.

> Maybe just me, but doesn't most C++ code being written today not use inheritance very much, and so make virtual dispatch moot

Most C++ code being written today is the same code that has been here for years. What compels you to believe things are rewritten on the spot? I mean, I personally know of flagship C++ projects that are still stuck in C++14 and earlier. Why would this change?

Perhaps people should pay attention to the fact that C++ goes way out of its way to be backwards compatible.

The flagships are the laggards usually! They are large, complex projects with lots of ongoing maintenance and commitments. "Upgrading to the new compiler" is seen as tech debt payback... there are deadlines, new features, and more important things to implement!

Upgrading a compiler in production code is always a major task. It often involves introducing breaking changes in dependencies, some of which are far from trivial to fix.

If you tell a Product Manager that you want to upgrade a compiler just because, and all it will take is a month or two of work including full regression tests on all target platforms and collaboration from all teams, that isn't an easy sell.

Well, back when I wrote C++ for a living I tried to keep up with better practices and newish, more compact and sensible language features. So some code I might have written in the 1990s would almost always have overused inheritance, while when adding a feature in the 2010s, I would have minimised such use. I would expect most C++ devs to do something similar today.

> Well, back when I wrote C++ for a living I tried to keep up with better practices and newish, more compact and sensible language features.

That's fine, but definitely something that does not happen in professional settings. You simply don't look at a codebase with a few million LoC and decide on a whim that you are going on to, say, replace all raw pointers with smart pointers. That is not going to happen. That definitely did not happen at all.

May I remind you that Google's C++ coding guidelines discourage exceptions because they do not have the resources to refactor all their code to be exception safe? Google doesn't have the man power but you do?

Not particularly relevant here, but may I point out that Google's C++ guidelines are generally seen as bad, and really only applicable to someone at Google scale, which you are almost certainly not.

> Not particularly relevant here, but may I point out that Google's C++ guidelines are generally seen as bad (...)

I don't have a dog in the race, but this is the first time I ever heard anyone express this opinion. Google's C++ guidelines are the first thing that critics cite when complaining about exceptions, and they do so as an example and not as something "bad".

They also have nothing to do with scale, really. That's a puzzling statement. I have no idea what compels you to make that claim.

It's still the most convenient way to implement type erasure, so no.

There are codebases out there that don’t use a lot of TMP and prefer Java-like type management.

To each their own, but yeah, your experience matches mine.

90's C++ you mean, a decade before Java came to be, and responsible for famous books like GoF.

90's C++ already had templates, so “Java-like” is a more succinct descriptor, it doesn’t imply the direction of historical ancestry.

Yes, and?

First of all they were extremely buggy back then, as anyone that actually used Stepanov's original implementation, from HP with docs hosted at SGI, will remember.

Secondly, Turbo Vision, OWL, VCL, MacApp, PowerPlant, Tools.h++, RogueWave Collection Classes, MFC, wxWidgets, Gtkmm, Qt, PÖET, COM/OLE/ActiveX, CORBA, Copland, BeOS predate Java, not the other way around.

You were criticizing the use of “Java-like”. IMO it gets the point across much better here than “90's C++”. It has nothing to do with what predates what.

Yes, because it is completely wrong.

It isn't writing C++ as Java, it is writing C++ as it was common between 1990 and 2011, before C++11 and other programming techniques took over in the C++ world, highly influenced by Andrei Alexandrescu's book "Modern C++ Design", published in 2001.

The GoF book came out in 94, and Java in 95.

Yes, have I said otherwise?

It is a book that plenty think it has Java in it, no it has Smalltalk and C++ and was published before Java came to be as you point out.

The decade was about the book publishing date, rather all the C++ frameworks that came to the market since CFront 2.0 was made available in 1989, and yes it was exactly 7 years, if being pedantic.

I think this is unfortunately wishful thinking, a lot of code is still written with traditional inheritance. It just makes unit testing with mocks much easier.

Are C++ concepts not enough?

Reply on news.ycombinator.com