5 ms·

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

by geertj 3y ago

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.

freedomben 3y ago
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++
- StopTheTechies 3y ago
  > 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.
- dns_snek 3y ago
  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.
  - bun_terminator 3y ago
    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
- ryandrake 3y ago
  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.
  - JonChesterfield 3y ago
    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.
- Xeamek 3y ago
  >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 https://bitbashing.io/std-visit.html
  - marcosdumay 3y ago
    > 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.
    - geertj 3y ago
      > 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.
- tsimionescu 3y ago
  > 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.
- lmm 3y ago
  > 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.
lmz 3y ago
> 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?
IAmLiterallyAB 3y ago
> GCC 14 Do you have a reference for significant module changes in GCC 14? I see nothing on the changes page for 14
- geertj 3y ago
  https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules....
loeg 3y ago
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.
tsimionescu 3y ago
> 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 https://en.cppreference.com/w/cpp/compiler_support
- dataflow 3y ago
  > 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?
  - tsimionescu 3y ago
    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.

by geertj 3y ago

freedomben 3y ago

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++

StopTheTechies 3y ago
> 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.
dns_snek 3y ago
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.
- bun_terminator 3y ago
  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
ryandrake 3y ago
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.
- JonChesterfield 3y ago
  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.
Xeamek 3y ago
>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 https://bitbashing.io/std-visit.html
- marcosdumay 3y ago
  > 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.
  - geertj 3y ago
    > 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.
tsimionescu 3y ago
> 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.
lmm 3y ago
> 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.

lmz 3y ago

> 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?

IAmLiterallyAB 3y ago

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

geertj 3y ago
https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules....

loeg 3y ago

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.

tsimionescu 3y ago

> 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 https://en.cppreference.com/w/cpp/compiler_support

dataflow 3y ago
> 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?
- tsimionescu 3y ago
  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.