6 ms·

C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks t

C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.

AnimalMuppet 4y ago
Given that gunpowder was invented in the 9th century, fifth century fireworks were probably pretty uninteresting...
pjmlp 4y ago
Use Visual C++ and you will have modules today. I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch.
- joshuamorton 4y ago
  > I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch. To be fair, if you're using a language that has a reasonable compilation story, this is only every a concern the first time you compile.
  - pjmlp 4y ago
    Sure I always need an excuse to go out for lunch.
StillBored 4y ago
"C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing. I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution. Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code? Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.
- boardwaalk 4y ago
  You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all. Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the Rust ecosystem doesn’t have as many duplicate libraries as C++? (of course it doesn’t?)
  - StillBored 4y ago
    The problem is that cargo gets in the way (as does rustc) if you try and use it in anything other than the simple import this dependency mode. I spent a hell hole of a day or two, trying to pick up a dependency outside cargo because it didn't behave in a way that meshed with the rest of my build environment. So, yes it handles a couple of the basic cases, but then your out of luck, stuck in a version hell/etc because rustc and cargo are so tightly integrated and the flags needed to emulate some of the behavior with just the compiler are poorly documented and/or version dependent. It dictates, you conform (which is basically the rust way).
  - germandiago 4y ago
    The problem with the typical rants about C++ is that you guys are outdated. With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.
    - flohofwoe 4y ago
      The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.
      - 4y ago
germandiago 4y ago
Besides having lsp (language server protocol), Visual C++, CLion and others, I have been successfully using CMake/Meson paired with Conan and I can tell from experience that it is amazing what you can achieve. Someone will say Cargo or whatever, which is nice and simple. But with these tools you can choose all details and optimizations as well, something that other tools just hide. But you can still keep it simple with a conanfile.txt for your dependencies and the stock add_executable etc. in CMake/Meson and get done with it. If you feel CMake is subpar (bc its syntax and DSL are terrible, I agree with that) then you can use Meson. It works pretty well.
adev_ 4y ago
> C++ has virtually zero tooling and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memtracers, profilers, thread sanitizers, debuggers, disassemblers, static analyzers, packages managers, bindings generators, ABI checkers, crash analyzers, loggers and I am sure I forget still many others.
- fouronnes3 4y ago
  Yeah what I meant was build system tooling, sorry for the approximation.
- flohofwoe 4y ago
  Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).
  - adev_ 4y ago
    They do work below the language level but have been generally explicitly made for C and C++ programs. e.g abi-compliance-checker The other languages benefit of them currently because they leverage LLVM (also made in C++), because their interpreter/VM are made directly in C. How is it already ? Standing on the shoulders of giants ? :)
- deleted 4y ago
  [deleted]
mbrodersen 4y ago
Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.
- flohofwoe 4y ago
  Most of the tools you mention are actually language agnostic (debuggers and profilers). And static analyzers are much more important for C and C++ than other languages.
- int_19h 4y ago
  Java has far more extensive tooling in all the categories that you've mentioned. I don't know if it's "the best tooling in the world", but if I had to make an educated guess, I'd bet on Java - and I don't even like it as a language.
germandiago 4y ago
> C++ has virtually zero tooling CMake, Meson, Waf, Conan, Visual Studio Code, Visual Studio, CLion, Intel VTune, GDB, LLDB, XCode, Artifactory, SonarQube, clang-tidy, clang-format, astyle, Incredibuild... > Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :) > and the committee is not interested in ever working on that https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0822r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p08... Interoperability effort for modules: https://github.com/GabrielDosReis/ipr https://github.com/GabrielDosReis/ipr

AnimalMuppet 4y ago

Given that gunpowder was invented in the 9th century, fifth century fireworks were probably pretty uninteresting...

pjmlp 4y ago

Use Visual C++ and you will have modules today. I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch.

joshuamorton 4y ago
> I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch. To be fair, if you're using a language that has a reasonable compilation story, this is only every a concern the first time you compile.
- pjmlp 4y ago
  Sure I always need an excuse to go out for lunch.

StillBored 4y ago

"C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing. I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution. Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code? Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.

boardwaalk 4y ago
You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all. Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the Rust ecosystem doesn’t have as many duplicate libraries as C++? (of course it doesn’t?)
- StillBored 4y ago
  The problem is that cargo gets in the way (as does rustc) if you try and use it in anything other than the simple import this dependency mode. I spent a hell hole of a day or two, trying to pick up a dependency outside cargo because it didn't behave in a way that meshed with the rest of my build environment. So, yes it handles a couple of the basic cases, but then your out of luck, stuck in a version hell/etc because rustc and cargo are so tightly integrated and the flags needed to emulate some of the behavior with just the compiler are poorly documented and/or version dependent. It dictates, you conform (which is basically the rust way).
- germandiago 4y ago
  The problem with the typical rants about C++ is that you guys are outdated. With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.
  - flohofwoe 4y ago
    The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.
    - 4y ago

germandiago 4y ago

Besides having lsp (language server protocol), Visual C++, CLion and others, I have been successfully using CMake/Meson paired with Conan and I can tell from experience that it is amazing what you can achieve. Someone will say Cargo or whatever, which is nice and simple. But with these tools you can choose all details and optimizations as well, something that other tools just hide. But you can still keep it simple with a conanfile.txt for your dependencies and the stock add_executable etc. in CMake/Meson and get done with it. If you feel CMake is subpar (bc its syntax and DSL are terrible, I agree with that) then you can use Meson. It works pretty well.

adev_ 4y ago

> C++ has virtually zero tooling and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memtracers, profilers, thread sanitizers, debuggers, disassemblers, static analyzers, packages managers, bindings generators, ABI checkers, crash analyzers, loggers and I am sure I forget still many others.

fouronnes3 4y ago
Yeah what I meant was build system tooling, sorry for the approximation.
flohofwoe 4y ago
Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).
- adev_ 4y ago
  They do work below the language level but have been generally explicitly made for C and C++ programs. e.g abi-compliance-checker The other languages benefit of them currently because they leverage LLVM (also made in C++), because their interpreter/VM are made directly in C. How is it already ? Standing on the shoulders of giants ? :)
deleted 4y ago
[deleted]

mbrodersen 4y ago

Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.

flohofwoe 4y ago
Most of the tools you mention are actually language agnostic (debuggers and profilers). And static analyzers are much more important for C and C++ than other languages.
int_19h 4y ago
Java has far more extensive tooling in all the categories that you've mentioned. I don't know if it's "the best tooling in the world", but if I had to make an educated guess, I'd bet on Java - and I don't even like it as a language.

germandiago 4y ago

> C++ has virtually zero tooling CMake, Meson, Waf, Conan, Visual Studio Code, Visual Studio, CLion, Intel VTune, GDB, LLDB, XCode, Artifactory, SonarQube, clang-tidy, clang-format, astyle, Incredibuild... > Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :) > and the committee is not interested in ever working on that https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0822r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p08... Interoperability effort for modules: https://github.com/GabrielDosReis/ipr https://github.com/GabrielDosReis/ipr