4 ms·

Does C(++) still not have a broadly used package manager? If not, that's mind blowing. The header only fad seems to because of a lack of one? IIRC they're more

Does C(++) still not have a broadly used package manager? If not, that's mind blowing. The header only fad seems to because of a lack of one? IIRC they're more costly compilation wise too.

ChrisMarshallNY 2y ago
The STL was originally header-only. Not sure if it still is.
quietbritishjim 2y ago
Conan and vcpkg are the two big ones, and there are several smaller ones. Since they picked up in popularity about a decade ago, it's become increasingly unusual for "header only" to be a selling point for a library (though of course some naturally are if they're fully templated).
avodonosov 2y ago
I also wonder why "header only" is advertized. As for the compilation cost, modern C++ tries to adress that with modules.
- 01HNNWZ0MV43FF 2y ago
  If a third-party dep has a build process any more complicated than dropping the cpp files into your own project, integrating with their build system is going to suck. (No two C++ projects use the same build system)
  - avodonosov 2y ago
    Thx for the explanation, makes sense.
jjmarr 2y ago
There isn't as big of a boost as you'd think, since for a templated function you have to #include the entire definition of said function in whatever source file is using it.
- v1ne 2y ago
  Yup, which is why a project that is serious about compilation time splits off type-independent parts into .cpp files that can be compiled separately, improving the speed of compilation for users of that template. I consider being a header-only "library" a code smell. It's purely for convenience, at the cost of compilation speed.
pjmlp 2y ago
It does, vcpkg and conan, but some folks refuse to learn how to use compiled languages and treat C and C++ as if they were Python or JavaScript.
zifpanachr23 2y ago
Every project handles this differently, and because of the huge variety of environments and potential build complications in comparison to pretty much every other language, I think it would be very hard to get a supermajority of the C and C++ communities in agreement on a package manager. That being said, there are package managers like vcpkg and conan that work just fine. They will just never be ubiquitous like pip or npm or cargo. Projects are going to continue to want to manage these sorts of issues themselves in a lot of circumstances. For new projects on a supported platform, I'd recommend going ahead and just using vcpkg. But that's just my opinion. And there is code I work on where that wouldn't be possible. Plus some people just don't like the things that package managers tend to encourage.
yupyupyups 2y ago
>The header only fad seems to because of a lack of one? IIRC they're more costly compilation wise too. Templates cannot be compiled. They have to necesserily be distributed as header files. Furthermore, header files, unlike compiled code are easier to support on a wider variaty of platforms. They are more constly to include, as you said. You could technically create concrete classes or functions from the templates by supplying all the necessary type arguments, and compile that. But then the developer using your library will only be able to "use the template" with those particular type arguments. The flexibility that the templates offer is removed.

Does C(++) still not have a broadly used package manager? If not, that's mind blowing. The header only fad seems to because of a lack of one? IIRC they're more costly compilation wise too.

ChrisMarshallNY 2y ago

The STL was originally header-only. Not sure if it still is.

quietbritishjim 2y ago

Conan and vcpkg are the two big ones, and there are several smaller ones. Since they picked up in popularity about a decade ago, it's become increasingly unusual for "header only" to be a selling point for a library (though of course some naturally are if they're fully templated).

avodonosov 2y ago

I also wonder why "header only" is advertized. As for the compilation cost, modern C++ tries to adress that with modules.

01HNNWZ0MV43FF 2y ago
If a third-party dep has a build process any more complicated than dropping the cpp files into your own project, integrating with their build system is going to suck. (No two C++ projects use the same build system)
- avodonosov 2y ago
  Thx for the explanation, makes sense.

jjmarr 2y ago

There isn't as big of a boost as you'd think, since for a templated function you have to #include the entire definition of said function in whatever source file is using it.

v1ne 2y ago
Yup, which is why a project that is serious about compilation time splits off type-independent parts into .cpp files that can be compiled separately, improving the speed of compilation for users of that template. I consider being a header-only "library" a code smell. It's purely for convenience, at the cost of compilation speed.

pjmlp 2y ago

It does, vcpkg and conan, but some folks refuse to learn how to use compiled languages and treat C and C++ as if they were Python or JavaScript.

zifpanachr23 2y ago

Every project handles this differently, and because of the huge variety of environments and potential build complications in comparison to pretty much every other language, I think it would be very hard to get a supermajority of the C and C++ communities in agreement on a package manager. That being said, there are package managers like vcpkg and conan that work just fine. They will just never be ubiquitous like pip or npm or cargo. Projects are going to continue to want to manage these sorts of issues themselves in a lot of circumstances. For new projects on a supported platform, I'd recommend going ahead and just using vcpkg. But that's just my opinion. And there is code I work on where that wouldn't be possible. Plus some people just don't like the things that package managers tend to encourage.

yupyupyups 2y ago

>The header only fad seems to because of a lack of one? IIRC they're more costly compilation wise too. Templates cannot be compiled. They have to necesserily be distributed as header files. Furthermore, header files, unlike compiled code are easier to support on a wider variaty of platforms. They are more constly to include, as you said. You could technically create concrete classes or functions from the templates by supplying all the necessary type arguments, and compile that. But then the developer using your library will only be able to "use the template" with those particular type arguments. The flexibility that the templates offer is removed.