Hacker News Reader

Comment by geertj | Hacker News Reader

The article is from 2010. C++20 solved the include file issue with modules. The ecosystem is almost there with CMake 3.28 (released) and GCC 14 (some time in H1 this year) providing out of the box support.

For most practical purposes, modern c++ should be seen as a modern language. You need to make some effort to understand what language features not to use, but in my experience that effort is not too bad in the context of the overall development process.

There are also some initiatives (cppfront is my favorite) to create an updated syntax where certain unsafe historic behaviors are not allowed.

View on HN

> C++20 solved the include file issue with modules. The ecosystem is almost there with CMake 3.28 (released) and GCC 14 (some time in H1 this year) providing out of the box support.

According to CPPReference [0], there isn't a single compiler release available today that fully supports C++20 modules. So perhaps "it's fixed" is a bit early. Especially since C++ projects tend to lag the latest release of their compiler by a few years, so even if GCC14 will indeed be the first C++ compiler to support modules fully, you still need to learn to use include guards today if you're going to be working in C++.

This is one of the major problems of "modern C++" by the way. Major features always exist in principle long before they actually exist in practice (concepts being the other feature that took years to fully be supported).

[0] https://en.cppreference.com/w/cpp/compiler_support

> According to CPPReference [0], there isn't a single compiler release available today that fully supports C++20 modules

Seems to me like MSVC does at least? What do you see it missing?

I don't know the details, but the table is saying "partial" for MSVC as well, right?

Edit: at a deeper look, I think I misread the table a bit, I guess it's saying that the feature is partially supported in MSVC 19.00 and 19.10, but full support in 19.28. Sorry about that misunderstanding.

It surprises and saddens me how dismissed C++ is nowadays. It's rarely my first choice (unless writing a gui, then Qt is my go-to), but it is a far more modern and less dangerous language than most people think. With most technology, people don't assume it hasn't changed since the 90s, but for some reason, that's what people do with C++

> but it is a far more modern and less dangerous language than most people think.

I suspect a better answer here is that people have wildly different tolerances for safety and don't discuss the subjective aspects of interactions with programming languages.

I've never written C++ in professional capacity, what turns me off from learning is what I've heard and read about its vast complexity, e.g. you could meet 20 expert C++ developers and they'd all be using a different subset of the language. I don't want to spend more energy learning a language than I do actually solving the problem. Same reasoning turns me off from Rust, too.

As a pure c++ dev, this is true and a good reason. The committee is borderline sabotaging the language. On top of the anti-cpp crows slinging hitpieces

Modern C++ is great and I would choose it today if I were starting a project from scratch. I think people’s problem with C++ is the existing projects/code. If I were to join a random company today working with a C++ code base, it is very likely I’d be dealing with legacy code complete with all the 1990s footguns C++ dismissers dismiss. That code base would also likely have problems like requiring Visual C++ 6.0 to compile, emitting thousands of warnings that have been ignored for decades, and the company shipping the DEBUG executable because nobody can figure out how to get the RELEASE build to not crash. Often existing C++ projects come with 1990s era problems, so detractors can still legitimately use 30 year old arguments.

Modern C++ is mostly syntactic sugar over older C++. If you manage to walk the happy path entirely within said syntax the code looks quite pretty. Lots of the language design is about having a nicer way to express common ideas.

If you stray from the happy path, the demons come for you. Or if your use case isn't met by the existing sugar. Or if you have a dependency which was written a couple of years ago that you need to reach into.

And naturally the project started from scratch today, only using the very nicest C++ features, will be legacy code written wrong in three or six years from now as the language moves on.

I wouldn't want to start a new project in C++ today but I'm not totally confident there's a better choice available.

>more modern and less dangerous language than most people think

Compared to what? Itself from 20 years ago? That's great, but not nearly enough. Cpp just has SO MUCH FRICTION that it's simply not worth it to deal with it. Maybe if you have 20yrs of cpp experience and carved out a specific way for yourself to avoid all of it while still being productive... But that's not really an argument.

And sure, there are still some cases when the alternatives aren't ideal either (ie. Rust also having friction, especially in domain like games, or higher level languages being too slow). But cpp has so much downsides I don't see why should one ever default into choosing cpp, unless you REALLY care about the benefits it brings. But those upsides are usually external (ie. ecosystem), rather then features of the language itself

https://bitbashing.io/std-visit.html

> and carved out a specific way for yourself to avoid all of it while still being productive

I believe such person exists when I see one. All that I see around are people claiming they did that, while ignoring some huge issue with their style that inserts some really nasty bugs on their software.

Instead, the only C++ code that works out there is created by committee and peer-reviewed, so that different styles compensate each other.

> I believe such person exists when I see one. All that I see around are people claiming they did that, while ignoring some huge issue with their style that inserts some really nasty bugs on their software.

The real question is, of 100 bugs in a real-world application, how many were caused or at least influenced by the language, and how many are application level errors. In my practical experience bugs due to C++ behavior have just not been a thing. Maybe your world is different.

> it is a far more modern and less dangerous language than most people think.

I think the opposite tends to be true. C++ is a more dangerous language than most people think, and many who see some nice new constructs end up with a false sense of security. In any major C++ project you will sooner rather than later find pieces that don't strictly respect all of the rules of modern C++, that end up accidentally invoking UB, and that will happily pass code review and de testing before blowing up when something else changes.

People tend to believe they can write safe C++, but outside constrained environments (similar to MISRA C) , this has not been proven true in practice.

> With most technology, people don't assume it hasn't changed since the 90s, but for some reason, that's what people do with C++

Disagree, every technology is like this. Talk to people about Maven and they think the 2005-era reasons not to use it are valid. Mention MongoDB and people think it's 2015. The industry is seemingly only ever willing to progress by adopting new things, not by fixing existing things.

> C++20 solved the include file issue with modules. The ecosystem is almost there with CMake 3.28 (released) and GCC 14 (some time in H1 this year) providing out of the box support.

So it's not widely supported yet in the newest released versions of the compiler and the article probably is still good advice until your project knows it no longer needs to compule using older versions?

C++20 may provide a theoretical solution but we're a long way from "it is practical and everyone easily replaces their headers with modules." In 2024 I am still manually writing C++ headers for my Fortune 100 employer.

> GCC 14

Do you have a reference for significant module changes in GCC 14? I see nothing on the changes page for 14

https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules....

Reply on news.ycombinator.com