4 ms·

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated with the language or compiler, too.

imtringued 1y ago
I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.
- gpderetta 1y ago
  > It's bespoke Makefile nonsense with zero hope of standardization technically Makefile is standardized (by POSIX), contrary to most alternatives. /extremely pedantic
- pjmlp 1y ago
  I would rather deal with Makefiles than Gradle.
  - saghm 1y ago
    I think we can afford to strive for more than just "not quite the absolute worst" (for however we decide to measure quality).
- einpoklum 1y ago
  > I used to write a lot of C++ in 2017... It's bespoke Makefile nonsense 1. Makefiles are for build systems; they are not C++. 2. Even for building C++ - in 2017, there was no need to write bespoke Makefiles, or any Makefiles. You could, and should, have written CMake; and your CMake files would be usable and relevant today. > Meanwhile my gradle setups have been almost unchanged since that time ... but, typically, with far narrower applicability.
  - feffe 1y ago
    CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn. For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makefile than some obscure 3pp CMake module that doesn't do what I want. Plain old makefiles are very hackable for better or worse [1]. It's easy to solve problems with make (in bespoke ways), and at the same time this is the big issue, causing lots of custom solutions of varying correctness. [1]: Make is easy the same way C is easy.
    - einpoklum 1y ago
      I didn't say "easy to deal with", I said it's not bespoke nonsense, and that you could keep it mostly unchanged today, 8 years later. Plus - the "obscure third party modules" have been getting less obscure and more standard-ish. In 2017 it was already not bad, today it's better.
Defletter 1y ago
This is pure Stockholm syndrome. If I were forced to choose between creating a cross-platform C++ project from scratch or taking an honest to god arrow to the knee, the arrow would be less painful.
- CyberDildonics 1y ago
  Why? There are lots of cross platform libraries and most aspects are not platform specific. It's really not a big deal. Use FLTK and you get most of the cross platform stuff for free in a small package.
- AlienRobot 1y ago
  I don't want any arrows in my knees but I agree. The main reason I don't want to use C/C++ are the header files. You have to write everything in a header file and then in an implementation file. Every time you want to change a function you need to do this at least twice. And you don't even get fast compilation speed compared to some languages because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies, and to solve this you use precompiled headers which you might have to set up manually dependending on what IDE you are using. It's all too painful.
  - jstimpfle 1y ago
    It gets better with experience. You can have a minimal base layer of common but rarely changing functionality. You can reduce static inline functions in headers. You reduce data structure definitions, but put only forward declarations in header files. (Don't use C++ methods, at least don't put them in an API, because they force you to expose your implementation details needlessly). You can separate data structures from functions in different header files. Grouping functions together with types is often a bad idea since most useful functionality combines data from two or more "unrelated" types -- so you'd rather make function headers "by topic" than putting them alongside types. I just created a subsystem for a performance intensive application -- a caching layer for millions or even billions of objects. The implementation encompasses over a 1000 LOC, but the header only includes <stdint.h>. There are about 5 forward struct declarations and maybe a dozen function calls in that API. To a degree it might be stockholm syndrome, but I feel like having had to work around a lot of C's shortcomings I actually learned quite a lot that helps me in architecting bigger systems now. Turns out a lot of the flexibility and ease that you get from more modern languages mostly allows you to code more sloppily, but being sloppy only works for smaller systems.
scrubs 1y ago
I agree -- I've been at it long enough -- cmake etc makes stuff pretty darn easy. But in industrial settings where multi groups share and change libs something like debpkg may be used. You add caching and you can go quite deep quickly esp after bolting on cdci. One must cop to the fact that a go build or zig build is just fundamentally better.
- jlarocco 1y ago
  Yeah, I definitely agree the newer tools are better, but sometimes the arguments against C++ get blown out of proportion. It definitely has a lot of flaws, but in practice most of them have solutions or workarounds, and on a day-to-day basis most C++ programmers aren't struggling with this stuff.
- rapidlua 1y ago
  Go build is fundamentally better? How so? Go build is so light on features that adding generated files to source control is a norm in go land.
  - scrubs 1y ago
    Generated files are noise. Newer languages builds have built in version resolution to resolve dependencies together with smarter ways to reference dependencies without #include. And that's better
duped 1y ago
So I come from the C/C++ world, that's part of why I disagree with these takes. I wouldn't say any process involving CMake is "not that big of a deal" because I routinely see veteran developers struggle to edit cmake files to get their code to compile and link.
saghm 1y ago
"It's not really that big a deal once you know how it works" is the case with pretty much everything though. The question is whether the amount of time needed to learn how something works is worthwhile though, and the sheer number of things you need to invest the time to learn in a language like C++ compared to more modern languages is a big deal. Looking at a single one of them in isolation like the build system essentially just zooms in one problem far enough to remove the other ones from the picture.
einpoklum 1y ago
It is a big deal even after you know how it works. The thing is, the languages like Rust only make this easier within their controlled "garden". But for C and C++, you build in the "world outside the garden" to begin with, where you are not guaranteed of everyone having prepared everything for you. So, it's harder, and you may need third-party tools or putting in some elbow grease, or both. The upside is that when rustaceans or go-phers and such wander outside their respective gardens, most of them are completely lost and have no idea what to do; but C and C++ people are kinda-sorta at home there, already.
- steveklabnik 1y ago
  What is "outside the garden" for Rust?
  - einpoklum 1y ago
    Oh, say, use some binary C library with some header, that you found on some system.
    - hiimkeks 1y ago
      That shouldn't be too tricky, assuming the binary is built for the sort of device you want to run on. At least not much more complicated than calling any other C code, using bindgen.
      - steveklabnik 1y ago
        Yep, Rust made design decisions to make this case as zero overhead as it can be.

imtringued 1y ago

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.

gpderetta 1y ago
> It's bespoke Makefile nonsense with zero hope of standardization technically Makefile is standardized (by POSIX), contrary to most alternatives. /extremely pedantic
pjmlp 1y ago
I would rather deal with Makefiles than Gradle.
- saghm 1y ago
  I think we can afford to strive for more than just "not quite the absolute worst" (for however we decide to measure quality).
einpoklum 1y ago
> I used to write a lot of C++ in 2017... It's bespoke Makefile nonsense 1. Makefiles are for build systems; they are not C++. 2. Even for building C++ - in 2017, there was no need to write bespoke Makefiles, or any Makefiles. You could, and should, have written CMake; and your CMake files would be usable and relevant today. > Meanwhile my gradle setups have been almost unchanged since that time ... but, typically, with far narrower applicability.
- feffe 1y ago
  CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn. For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makefile than some obscure 3pp CMake module that doesn't do what I want. Plain old makefiles are very hackable for better or worse [1]. It's easy to solve problems with make (in bespoke ways), and at the same time this is the big issue, causing lots of custom solutions of varying correctness. [1]: Make is easy the same way C is easy.
  - einpoklum 1y ago
    I didn't say "easy to deal with", I said it's not bespoke nonsense, and that you could keep it mostly unchanged today, 8 years later. Plus - the "obscure third party modules" have been getting less obscure and more standard-ish. In 2017 it was already not bad, today it's better.

Defletter 1y ago

This is pure Stockholm syndrome. If I were forced to choose between creating a cross-platform C++ project from scratch or taking an honest to god arrow to the knee, the arrow would be less painful.

CyberDildonics 1y ago
Why? There are lots of cross platform libraries and most aspects are not platform specific. It's really not a big deal. Use FLTK and you get most of the cross platform stuff for free in a small package.
AlienRobot 1y ago
I don't want any arrows in my knees but I agree. The main reason I don't want to use C/C++ are the header files. You have to write everything in a header file and then in an implementation file. Every time you want to change a function you need to do this at least twice. And you don't even get fast compilation speed compared to some languages because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies, and to solve this you use precompiled headers which you might have to set up manually dependending on what IDE you are using. It's all too painful.
- jstimpfle 1y ago
  It gets better with experience. You can have a minimal base layer of common but rarely changing functionality. You can reduce static inline functions in headers. You reduce data structure definitions, but put only forward declarations in header files. (Don't use C++ methods, at least don't put them in an API, because they force you to expose your implementation details needlessly). You can separate data structures from functions in different header files. Grouping functions together with types is often a bad idea since most useful functionality combines data from two or more "unrelated" types -- so you'd rather make function headers "by topic" than putting them alongside types. I just created a subsystem for a performance intensive application -- a caching layer for millions or even billions of objects. The implementation encompasses over a 1000 LOC, but the header only includes <stdint.h>. There are about 5 forward struct declarations and maybe a dozen function calls in that API. To a degree it might be stockholm syndrome, but I feel like having had to work around a lot of C's shortcomings I actually learned quite a lot that helps me in architecting bigger systems now. Turns out a lot of the flexibility and ease that you get from more modern languages mostly allows you to code more sloppily, but being sloppy only works for smaller systems.

scrubs 1y ago

I agree -- I've been at it long enough -- cmake etc makes stuff pretty darn easy. But in industrial settings where multi groups share and change libs something like debpkg may be used. You add caching and you can go quite deep quickly esp after bolting on cdci. One must cop to the fact that a go build or zig build is just fundamentally better.

jlarocco 1y ago
Yeah, I definitely agree the newer tools are better, but sometimes the arguments against C++ get blown out of proportion. It definitely has a lot of flaws, but in practice most of them have solutions or workarounds, and on a day-to-day basis most C++ programmers aren't struggling with this stuff.
rapidlua 1y ago
Go build is fundamentally better? How so? Go build is so light on features that adding generated files to source control is a norm in go land.
- scrubs 1y ago
  Generated files are noise. Newer languages builds have built in version resolution to resolve dependencies together with smarter ways to reference dependencies without #include. And that's better

duped 1y ago

So I come from the C/C++ world, that's part of why I disagree with these takes. I wouldn't say any process involving CMake is "not that big of a deal" because I routinely see veteran developers struggle to edit cmake files to get their code to compile and link.

saghm 1y ago

"It's not really that big a deal once you know how it works" is the case with pretty much everything though. The question is whether the amount of time needed to learn how something works is worthwhile though, and the sheer number of things you need to invest the time to learn in a language like C++ compared to more modern languages is a big deal. Looking at a single one of them in isolation like the build system essentially just zooms in one problem far enough to remove the other ones from the picture.

einpoklum 1y ago

It is a big deal even after you know how it works. The thing is, the languages like Rust only make this easier within their controlled "garden". But for C and C++, you build in the "world outside the garden" to begin with, where you are not guaranteed of everyone having prepared everything for you. So, it's harder, and you may need third-party tools or putting in some elbow grease, or both. The upside is that when rustaceans or go-phers and such wander outside their respective gardens, most of them are completely lost and have no idea what to do; but C and C++ people are kinda-sorta at home there, already.

steveklabnik 1y ago
What is "outside the garden" for Rust?
- einpoklum 1y ago
  Oh, say, use some binary C library with some header, that you found on some system.
  - hiimkeks 1y ago
    That shouldn't be too tricky, assuming the binary is built for the sort of device you want to run on. At least not much more complicated than calling any other C code, using bindgen.
    - steveklabnik 1y ago
      Yep, Rust made design decisions to make this case as zero overhead as it can be.