4 ms·

If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. You need custom implementations of data structures that mak

If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. You need custom implementations of data structures that make the trade-offs relevant to your needs.

antoineMoPa 7y ago
There is no reason for memory or speed to be different. What I mean is that parts of these libraries could be single small packages that would be as fast. As an example, look at this folder which: https://github.com/facebook/folly/tree/master/folly/compression https://github.com/facebook/folly/tree/master/folly/compress... In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Things don't have to be more or less generic.
- Eyas 7y ago
  So the comment is really about the size of these libraries? This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself. That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.
- forrestthewoods 7y ago
  > Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Because C++ sucks and its dependency story is a nightmare. There are a few competing C++ package managers. They’re all relatively new and none of them are particularly popular. The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. Compiling OpenSSL requires installing Strawberry Perl. This type of garbage of BS is the norm. Source: C++ dev for 15 years
  - asveikau 7y ago
    > The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. I think this has much more to do with templates than anything else. A template can only exist in a header. Then there is also the performance benefit of inlining. (As well as performance hit of inlining, namely code size.) There is a separate, much later movement/phenomenon of C (not C++) developed as header-only libraries, which by contrast I don't think there is nearly as good reason for except for that some people are confused at how a linker works. I have seen use of that technique advocated on Hacker News much more frequently than in production.
    - forrestthewoods 7y ago
      Header only and single file are slightly different. A headery library may include many many files. A single file or single header may be “header only” or it may have an impl define. People who prefer this distribution mechanism are generally ok with 1 header plus 1 cpp. These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.
      - asveikau 7y ago
        Or maybe they don't actually need the dependencies. There is a style of writing code to minimize dependencies and many people value this. I would take the sqlite amalgamation as an example of good use of "few files, few dependencies". First off, it is above all a solid piece of work. It is distributed with one header file and one .c, even though it is developed as multiple files. Iirc the sqlite website cites a ~10% speed improvement or so due to the optimizer being able to do a better job across the whole library. In my opinion this is a better reason than "tracking dependencies sucks" or "omg too many files".
        mratsim 7y ago
        I'm pretty sure it's the (lack of) package managers. The presence of a defacto package manager completely changes the library dynamics. I can't even link and test properly against GMP on Windows :/
msla 7y ago
> If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. The standard libraries should, in that they can have Spooky Deep Knowledge of the compiler and other standard libraries which external code won't, like how there's no way to add two ints which is faster than the standard + operator.
- jeffreygoesto 7y ago
  Well, this argument goes both ways, a generic implementation can never leverage special properties of your data. See i.e. Alexandrecu's talk [0] at about 1:05ff. If as a company you have special use cases or guidelines, you may easily benefit from libraries using these properties. [0] https://youtu.be/FJJTYQYB1JQ https://youtu.be/FJJTYQYB1JQ
- danbolt 7y ago
  I think you're right that some things, such as integer addition, are quick and don't require a lot of thought, but a lot of teams leaning to C++ stems from larger-scale performance considerations that aren't one-size-fits-all. A simple example is `std::vector`. The structure is a nice resizable array, but for a long time you couldn't override the allocator and the performance of your application could be affected by heap fragmentation or even just the performance cost of heap allocations. A lot of C++ shops often wrote their own replacement containers that had a better allocation strategy. The design needs of a PlayStation 2 programmer ended up being different than an x86 desktop computer with virtual memory.

antoineMoPa 7y ago

There is no reason for memory or speed to be different. What I mean is that parts of these libraries could be single small packages that would be as fast. As an example, look at this folder which: https://github.com/facebook/folly/tree/master/folly/compression https://github.com/facebook/folly/tree/master/folly/compress... In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Things don't have to be more or less generic.

Eyas 7y ago
So the comment is really about the size of these libraries? This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself. That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.
forrestthewoods 7y ago
> Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Because C++ sucks and its dependency story is a nightmare. There are a few competing C++ package managers. They’re all relatively new and none of them are particularly popular. The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. Compiling OpenSSL requires installing Strawberry Perl. This type of garbage of BS is the norm. Source: C++ dev for 15 years
- asveikau 7y ago
  > The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. I think this has much more to do with templates than anything else. A template can only exist in a header. Then there is also the performance benefit of inlining. (As well as performance hit of inlining, namely code size.) There is a separate, much later movement/phenomenon of C (not C++) developed as header-only libraries, which by contrast I don't think there is nearly as good reason for except for that some people are confused at how a linker works. I have seen use of that technique advocated on Hacker News much more frequently than in production.
  - forrestthewoods 7y ago
    Header only and single file are slightly different. A headery library may include many many files. A single file or single header may be “header only” or it may have an impl define. People who prefer this distribution mechanism are generally ok with 1 header plus 1 cpp. These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.
    - asveikau 7y ago
      Or maybe they don't actually need the dependencies. There is a style of writing code to minimize dependencies and many people value this. I would take the sqlite amalgamation as an example of good use of "few files, few dependencies". First off, it is above all a solid piece of work. It is distributed with one header file and one .c, even though it is developed as multiple files. Iirc the sqlite website cites a ~10% speed improvement or so due to the optimizer being able to do a better job across the whole library. In my opinion this is a better reason than "tracking dependencies sucks" or "omg too many files".
      - mratsim 7y ago
        I'm pretty sure it's the (lack of) package managers. The presence of a defacto package manager completely changes the library dynamics. I can't even link and test properly against GMP on Windows :/

msla 7y ago

> If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. The standard libraries should, in that they can have Spooky Deep Knowledge of the compiler and other standard libraries which external code won't, like how there's no way to add two ints which is faster than the standard + operator.

jeffreygoesto 7y ago
Well, this argument goes both ways, a generic implementation can never leverage special properties of your data. See i.e. Alexandrecu's talk [0] at about 1:05ff. If as a company you have special use cases or guidelines, you may easily benefit from libraries using these properties. [0] https://youtu.be/FJJTYQYB1JQ https://youtu.be/FJJTYQYB1JQ
danbolt 7y ago
I think you're right that some things, such as integer addition, are quick and don't require a lot of thought, but a lot of teams leaning to C++ stems from larger-scale performance considerations that aren't one-size-fits-all. A simple example is `std::vector`. The structure is a nice resizable array, but for a long time you couldn't override the allocator and the performance of your application could be affected by heap fragmentation or even just the performance cost of heap allocations. A lot of C++ shops often wrote their own replacement containers that had a better allocation strategy. The design needs of a PlayStation 2 programmer ended up being different than an x86 desktop computer with virtual memory.