5 ms·

> "Unfortunately, there is not a single place to go to look for C++ Libraries." I don't understand this. I code in C++ everyday at the moment (that's a story f

> "Unfortunately, there is not a single place to go to look for C++ Libraries." I don't understand this. I code in C++ everyday at the moment (that's a story for another day) so I know the ecosystem, at least for scientific computing, pretty well. With all the changes and improvements being introduced, what's stopping a package manager from being added? The bane of my existence at the moment is the fact that I have this HUGE Boost dependency in my code, even if I'm only using a few packages. I know the Boost project has now finally migrated to Github and provides individual repositories for libraries. It just startles me that there isn't a single, consolidated package manager to have rolled out of the millions of work-hours that have gone into C++ projects. It's possibly the single biggest criticism of the language that I felt wasn't tackled at all. There is a complete lack of consensus. In trying to accommodate everything and anything, C++ has in my experience overshot the mark.

furyofantares 12y ago
I think that and the previous issue go hand in hand, contributing to each other: > Unfortunately, C++ Libraries are often not designed for interoperability with other libraries And I think it's not just that the libraries don't work well with each other, but they also only work with a subset of C++ projects since any given group of collaborating C++ programmers seems to settle on their own subset of the language to allow in their coding standards. Perhaps I am falling into the trap of thinking about old C++ now -- modern C++ does seem to have more of a broadly understood idiomatic style.
frankzinger 12y ago
The bane of my existence at the moment is the fact that I have this HUGE Boost dependency in my code, even if I'm only using a few packages... It just startles me that there isn't a single, consolidated package manager... Sincerely, I have never understood this common complaint about C++ (applies to C as well, actually). My OS comes with a huge repo of C++ libraries. For example, there is a separate package for each of the Boost libraries you used as your example. Why do I need a C++-specific package manager? What's the use case? Windows?
- ajross 12y ago
  Pretty much. In particular, Boost is already packaged and available for clean dependency management on all Linux distros. And on Windows, you're almost always looking at shipping a statically build binary (or one with the DLLs packaged) anyway, so an external package manager would provide little value anyway. Really the existence of language-specific package management might be considered the bug, and not the feature. In all cases I've dealt with, the OS packaging is superior anyway.
  - sanderjd 12y ago
    I think it's fascinating how wildly differing peoples' experiences are with this. I find system package managers nice for system administrators and applications, but for development, every one I've used is far less convenient than a purpose-built package ecosystem.
  - nawitus 12y ago
    Do you think every Node.js package should be released as an OS level package?
- JonathonW 12y ago
  Windows. OSX (to some degree; Homebrew and MacPorts mitigate this). Linux if you want library versions newer than those supplied by the distro, if you want something that's not supplied by the distro, or if you want to be able to handle your build in a distro-independent manner (those "separate packages for each of the Boost libraries" you reference are provided by your distribution; Boost themselves only distribute one monolithic package from which you can, with some massaging, pull out individual parts if you really need to). The language-specific package managers used with (for example) Python, Ruby, or Node give developers an OS-agnostic way to pull in dependencies, and, since dependencies are being packaged uniformly, avoids the conflicts between build systems that can make it hard for C++ libraries to coexist (this thing needs CMake, this other guy used Autoconf/Automake, and I've got Boost which built with Bjam, and now I need to make it all work on Windows and they're all providing binaries built with different MSVC versions).
enry_straker 12y ago
A package manager is generally not part of the language per se and should not be part of the language, but rather be part of the tooling ecosystem around it. Don't get me wrong. A de facto package manager is extremely important for any major language - and it's high time someone in the C++ community builds and promotes one. It just doesn't belong in the spec.
- Pxtl 12y ago
  I do know of at least one: Microsoft's NuGet now supports C++ packages. Something tells me that isn't the answer folks are looking for.
maxlybbert 12y ago
> what's stopping a package manager from being added? ... > It just startles me that there isn't a single, > consolidated package manager to have rolled out of the > millions of work-hours that have gone into C++ projects. > > It's possibly the single biggest criticism of the > language that I felt wasn't tackled at all. As far as the standard committee: "creating tools" is outside the scope of "defining a language and its standard library." As far as the "millions of work-hours that have gone into C++ projects," it's probably a combination of nobody's come up with a package manager that satisfies enough programmers and nobody's been willing to spend the extra time to create such a tool. It's hard enough to ship code on time. > There is a complete lack of consensus. In trying to > accommodate everything and anything, C++ has in my > experience overshot the mark. It's certainly true that projects that try to take full advantage of C++'s flexibility end up collapsing. Projects generally shouldn't allow "everything and anything" in the code base. And many of the design principles that the committee follows should probably not be applied to software projects in general. But the language has to satisfy more than your project, or more than the average project that programmers believe exists but can't agree on what it is. I've been writing C++ code professionally for years, and while I know how to, I haven't shipped any GUI code. I did write a gtkmm-based stopwatch to help my son with an elementary school science project (because I thought it was more fun to do that than to buy a stopwatch at the local sporting goods store). But professionally I've only written code for back end web services. I know I'm not the average C++ programmer people imagine, but I'm not sure if the average C++ programmer is writing desktop GUI software, or iPhone software, or libraries that will be called from Java, C# or some other language via SWIG. I know they aren't the average C++ programmers, but I do know some people write C++ to run on supercomputers (I used to work with one of them). Regarding a package manager specifically: I personally have been happy to use RPM on my personal Linux system to manage packages. I wouldn't expect people to use RPM on a BSD or Apple system. I'm not sure that we need a special package manager just for C++ libraries. I miss anything like RPM when developing on Windows (edit: another comment mentions NuGet: I'll try it, thanks!). If you write something for Windows, I'll buy a copy. My web services interact with efficient number crunching libraries written in C++. In my case, I don't need things to be as efficient as possible, but others do. I know Dan Bernstein believes the way to get super-efficient libraries is to use different implementations to take advantage of CPU-specific features ( http://www.tedunangst.com/flak/post/some-gripes-about-nacl http://www.tedunangst.com/flak/post/some-gripes-about-nacl ), but this makes package management much harder (at least without function multiversioning -- https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiversioning.html https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiv... -- which isn't required by the standard). Should the committee tell Bernstein he's wrong? Or encourage compiler writers to ship with tools that Bernstein and others have no use for? How should the package manager handle a case where a library could work on my platform, but nobody's compiled it for me yet? What about platforms where the ABI isn't completely nailed down yet? You have identified a real shortcoming in C++ development. There isn't an easy answer. But, seriously, if you write one I'll be sure to send you some money.
revelation 12y ago
Because a package manager for C++ is infinitely more complex than one for a bytecode language like Java or .NET, where theres either a well defined spec (.NET) or a reference implementation (Java, Python) that everyone measures compatibility for? The first obvious problem is that there is no ABI for the C++ standard library. This makes sharing any kind of binaries plain impossible because exchange of C++ standard library objects between your project and a binary from the package manager will very likely just blow up. So the package manager, right from the bat, has to build every library and every (recursive) dependency of that library on demand on your computer using your C++ development environment. That alone is a herculean task if you consider the number of compilers (GCC (MinGW), Clang, VC, ICC), their respective versions and possible C++ standard library implementations used. And remember: you can't mix and match! There is a reason even a C++ library such as ZMQ exposes only a C interface, and it's because things become extremely messy very quickly when you are juggling around native code.

furyofantares 12y ago

I think that and the previous issue go hand in hand, contributing to each other: > Unfortunately, C++ Libraries are often not designed for interoperability with other libraries And I think it's not just that the libraries don't work well with each other, but they also only work with a subset of C++ projects since any given group of collaborating C++ programmers seems to settle on their own subset of the language to allow in their coding standards. Perhaps I am falling into the trap of thinking about old C++ now -- modern C++ does seem to have more of a broadly understood idiomatic style.

frankzinger 12y ago

The bane of my existence at the moment is the fact that I have this HUGE Boost dependency in my code, even if I'm only using a few packages... It just startles me that there isn't a single, consolidated package manager... Sincerely, I have never understood this common complaint about C++ (applies to C as well, actually). My OS comes with a huge repo of C++ libraries. For example, there is a separate package for each of the Boost libraries you used as your example. Why do I need a C++-specific package manager? What's the use case? Windows?

ajross 12y ago
Pretty much. In particular, Boost is already packaged and available for clean dependency management on all Linux distros. And on Windows, you're almost always looking at shipping a statically build binary (or one with the DLLs packaged) anyway, so an external package manager would provide little value anyway. Really the existence of language-specific package management might be considered the bug, and not the feature. In all cases I've dealt with, the OS packaging is superior anyway.
- sanderjd 12y ago
  I think it's fascinating how wildly differing peoples' experiences are with this. I find system package managers nice for system administrators and applications, but for development, every one I've used is far less convenient than a purpose-built package ecosystem.
- nawitus 12y ago
  Do you think every Node.js package should be released as an OS level package?
JonathonW 12y ago
Windows. OSX (to some degree; Homebrew and MacPorts mitigate this). Linux if you want library versions newer than those supplied by the distro, if you want something that's not supplied by the distro, or if you want to be able to handle your build in a distro-independent manner (those "separate packages for each of the Boost libraries" you reference are provided by your distribution; Boost themselves only distribute one monolithic package from which you can, with some massaging, pull out individual parts if you really need to). The language-specific package managers used with (for example) Python, Ruby, or Node give developers an OS-agnostic way to pull in dependencies, and, since dependencies are being packaged uniformly, avoids the conflicts between build systems that can make it hard for C++ libraries to coexist (this thing needs CMake, this other guy used Autoconf/Automake, and I've got Boost which built with Bjam, and now I need to make it all work on Windows and they're all providing binaries built with different MSVC versions).

enry_straker 12y ago

A package manager is generally not part of the language per se and should not be part of the language, but rather be part of the tooling ecosystem around it. Don't get me wrong. A de facto package manager is extremely important for any major language - and it's high time someone in the C++ community builds and promotes one. It just doesn't belong in the spec.

Pxtl 12y ago
I do know of at least one: Microsoft's NuGet now supports C++ packages. Something tells me that isn't the answer folks are looking for.

maxlybbert 12y ago

> what's stopping a package manager from being added? ... > It just startles me that there isn't a single, > consolidated package manager to have rolled out of the > millions of work-hours that have gone into C++ projects. > > It's possibly the single biggest criticism of the > language that I felt wasn't tackled at all. As far as the standard committee: "creating tools" is outside the scope of "defining a language and its standard library." As far as the "millions of work-hours that have gone into C++ projects," it's probably a combination of nobody's come up with a package manager that satisfies enough programmers and nobody's been willing to spend the extra time to create such a tool. It's hard enough to ship code on time. > There is a complete lack of consensus. In trying to > accommodate everything and anything, C++ has in my > experience overshot the mark. It's certainly true that projects that try to take full advantage of C++'s flexibility end up collapsing. Projects generally shouldn't allow "everything and anything" in the code base. And many of the design principles that the committee follows should probably not be applied to software projects in general. But the language has to satisfy more than your project, or more than the average project that programmers believe exists but can't agree on what it is. I've been writing C++ code professionally for years, and while I know how to, I haven't shipped any GUI code. I did write a gtkmm-based stopwatch to help my son with an elementary school science project (because I thought it was more fun to do that than to buy a stopwatch at the local sporting goods store). But professionally I've only written code for back end web services. I know I'm not the average C++ programmer people imagine, but I'm not sure if the average C++ programmer is writing desktop GUI software, or iPhone software, or libraries that will be called from Java, C# or some other language via SWIG. I know they aren't the average C++ programmers, but I do know some people write C++ to run on supercomputers (I used to work with one of them). Regarding a package manager specifically: I personally have been happy to use RPM on my personal Linux system to manage packages. I wouldn't expect people to use RPM on a BSD or Apple system. I'm not sure that we need a special package manager just for C++ libraries. I miss anything like RPM when developing on Windows (edit: another comment mentions NuGet: I'll try it, thanks!). If you write something for Windows, I'll buy a copy. My web services interact with efficient number crunching libraries written in C++. In my case, I don't need things to be as efficient as possible, but others do. I know Dan Bernstein believes the way to get super-efficient libraries is to use different implementations to take advantage of CPU-specific features ( http://www.tedunangst.com/flak/post/some-gripes-about-nacl http://www.tedunangst.com/flak/post/some-gripes-about-nacl ), but this makes package management much harder (at least without function multiversioning -- https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiversioning.html https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiv... -- which isn't required by the standard). Should the committee tell Bernstein he's wrong? Or encourage compiler writers to ship with tools that Bernstein and others have no use for? How should the package manager handle a case where a library could work on my platform, but nobody's compiled it for me yet? What about platforms where the ABI isn't completely nailed down yet? You have identified a real shortcoming in C++ development. There isn't an easy answer. But, seriously, if you write one I'll be sure to send you some money.

revelation 12y ago

Because a package manager for C++ is infinitely more complex than one for a bytecode language like Java or .NET, where theres either a well defined spec (.NET) or a reference implementation (Java, Python) that everyone measures compatibility for? The first obvious problem is that there is no ABI for the C++ standard library. This makes sharing any kind of binaries plain impossible because exchange of C++ standard library objects between your project and a binary from the package manager will very likely just blow up. So the package manager, right from the bat, has to build every library and every (recursive) dependency of that library on demand on your computer using your C++ development environment. That alone is a herculean task if you consider the number of compilers (GCC (MinGW), Clang, VC, ICC), their respective versions and possible C++ standard library implementations used. And remember: you can't mix and match! There is a reason even a C++ library such as ZMQ exposes only a C interface, and it's because things become extremely messy very quickly when you are juggling around native code.