3 ms·

> Probably the best example I can think of off the top of my head is Boost.Container: > https://www.boost.org/doc/libs/1_74_0/boost/container/vector https://ww

> Probably the best example I can think of off the top of my head is Boost.Container: > https://www.boost.org/doc/libs/1_74_0/boost/container/vector https://www.boost.org/doc/libs/1_74_0/boost/container/vector... Which I find absolutely hilarious. Thousands of lines of boilerplate for something as simple as an dynamically resizable array. Only for the _header_ which has to be included at each location that uses a vector either directly or indirectly. These are the kinds of things that prevent me from touching C++.

fsloth 6y ago
"These are the kinds of things that prevent me from touching C++" Please don't let boost stop you. At my team we avoid boost like the plague and prefer terse and pragmatic code. IMO C++ is best approached like C but with convenient data structures in the standard library - and tons of patterns that _may_ be taken into use if they simplify the code. That said, unless you are working in a specific setting where C++ is obviously the best tool, you probably should not use C++. Even at best of times C++ is complex and unproductive. But it offers an unbeatable combination of ecosystem maturity, robustness, close to the metal performance and high level concepts to fit few slots better than anything else.
- ncmncm 6y ago
  If you are unproductive when coding C++, you are Doing It Wrong. Good C++ code flows like water. If you are finding it complex, you have gone down a side alley, and need to get back to the wide, sunny boulevard. I frequently sit down and write 2000 lines of C++ code, and when it compiles, it works. Aim for that.
  - fsloth 6y ago
    My 2000 lines of C++ work fine just as well. C++ is unproductive when compared to other languages. C++ can be found to be the best language for a specific class of problems. But. Those 2000 lines of C++? If that code had been python or F# or even C# and the problem had been 'generic' enough it would likely have less lines of code and be done faster. If that 2k lines happened to implement some numerics stuff with hard performance requirements then C++ might come up on top. But my complaint overall is not about a short 2k line program. It's about the whole program lifetime and software complexity of a complex system. For non-trivial programs C++ opens a whole can of worms concerning compatibility, deployment, locales, memory handling, weird bugs due to sometimes obscure lifetimes, integer sizes on different plarforms... etc etc. And the C++ spec is infinite for most mortals.
huhtenberg 6y ago
Indeed. To each his own. I've been using C++ as a daily workhorse since the early 90s and Boost and its standardized derivatives is easily the worst thing that ever happened to the language. It may all make logical sense, but the end result looks, basically, like butt. It is not a refined, thoughtfully evolved language that is a pleasure to use. It has so many features bolted on at so many different angles that it has no distinct shape anymore. Design by committee at its finest.
gpderetta 6y ago
This is quite unfair. Boost.container::vector implements the full standard vector interface (that's already a large interface), plus quite a few non-standard extensions (significantly it has built-in support for default initialization). Boost.container also has support for stateful allocators and custom pointer types so that it can be used, for example, on shared memory (in fact boost container was originally a sub-library of boost.interprocess). That alone will increase the complexity significantly. It also I believe still support pre-c++11 (and substandard post c++11) compilers, so there is a lot of compiler workarounds and emulation of c++11 features. Also, being a template, the whole implementation is just in the _header_.
- jstimpfle 6y ago
  And you don't notice how you're only making my point? As for being a template, that doesn't preclude from having most of the implementation in a .cpp file. In fact that's highly desirable (separate compilation).
  - gpderetta 6y ago
    My point is that you would use boost.container if you need its additional features otherwise just use the equivalent standard containers. The complexity is there for a reason. A separate .cpp would require explicit instantiation. I do not see how that would work for a third party library that has to work for any T. Normally you can at least abstract away the memory management code, but in the case of boost container the use of custom allocators is expected, so you can't even do that.
  - kllrnohj 6y ago
    It's desirable for complication speed, but not for performance. The blessing & curse of templates is that while you pay for them in compilation speed, you're also getting every scrap of localized optimizations possible without needing to run a much slower, and less capable, LTO pass. There isn't a "strictly better" here, it's a trade-off. If you want a split implementation, make one. That's the beauty of C++ - there's nothing special the standard library can do that you can't. Android, for example, has a split implementation: https://cs.android.com/android/platform/superproject/+/master:system/core/libutils/include/utils/Vector.h https://cs.android.com/android/platform/superproject/+/maste... (I wouldn't use it, though, it's pretty outdated & shitty, but you can still do what you're talking about).
mehrdadn 6y ago
This was not intended to be an advertisement for C++. Nobody is begging you to use it. If you hate it, or otherwise don't understand its values and trade-offs, please don't use it.

fsloth 6y ago

"These are the kinds of things that prevent me from touching C++" Please don't let boost stop you. At my team we avoid boost like the plague and prefer terse and pragmatic code. IMO C++ is best approached like C but with convenient data structures in the standard library - and tons of patterns that _may_ be taken into use if they simplify the code. That said, unless you are working in a specific setting where C++ is obviously the best tool, you probably should not use C++. Even at best of times C++ is complex and unproductive. But it offers an unbeatable combination of ecosystem maturity, robustness, close to the metal performance and high level concepts to fit few slots better than anything else.

ncmncm 6y ago
If you are unproductive when coding C++, you are Doing It Wrong. Good C++ code flows like water. If you are finding it complex, you have gone down a side alley, and need to get back to the wide, sunny boulevard. I frequently sit down and write 2000 lines of C++ code, and when it compiles, it works. Aim for that.
- fsloth 6y ago
  My 2000 lines of C++ work fine just as well. C++ is unproductive when compared to other languages. C++ can be found to be the best language for a specific class of problems. But. Those 2000 lines of C++? If that code had been python or F# or even C# and the problem had been 'generic' enough it would likely have less lines of code and be done faster. If that 2k lines happened to implement some numerics stuff with hard performance requirements then C++ might come up on top. But my complaint overall is not about a short 2k line program. It's about the whole program lifetime and software complexity of a complex system. For non-trivial programs C++ opens a whole can of worms concerning compatibility, deployment, locales, memory handling, weird bugs due to sometimes obscure lifetimes, integer sizes on different plarforms... etc etc. And the C++ spec is infinite for most mortals.

huhtenberg 6y ago

Indeed. To each his own. I've been using C++ as a daily workhorse since the early 90s and Boost and its standardized derivatives is easily the worst thing that ever happened to the language. It may all make logical sense, but the end result looks, basically, like butt. It is not a refined, thoughtfully evolved language that is a pleasure to use. It has so many features bolted on at so many different angles that it has no distinct shape anymore. Design by committee at its finest.

gpderetta 6y ago

This is quite unfair. Boost.container::vector implements the full standard vector interface (that's already a large interface), plus quite a few non-standard extensions (significantly it has built-in support for default initialization). Boost.container also has support for stateful allocators and custom pointer types so that it can be used, for example, on shared memory (in fact boost container was originally a sub-library of boost.interprocess). That alone will increase the complexity significantly. It also I believe still support pre-c++11 (and substandard post c++11) compilers, so there is a lot of compiler workarounds and emulation of c++11 features. Also, being a template, the whole implementation is just in the _header_.

jstimpfle 6y ago
And you don't notice how you're only making my point? As for being a template, that doesn't preclude from having most of the implementation in a .cpp file. In fact that's highly desirable (separate compilation).
- gpderetta 6y ago
  My point is that you would use boost.container if you need its additional features otherwise just use the equivalent standard containers. The complexity is there for a reason. A separate .cpp would require explicit instantiation. I do not see how that would work for a third party library that has to work for any T. Normally you can at least abstract away the memory management code, but in the case of boost container the use of custom allocators is expected, so you can't even do that.
- kllrnohj 6y ago
  It's desirable for complication speed, but not for performance. The blessing & curse of templates is that while you pay for them in compilation speed, you're also getting every scrap of localized optimizations possible without needing to run a much slower, and less capable, LTO pass. There isn't a "strictly better" here, it's a trade-off. If you want a split implementation, make one. That's the beauty of C++ - there's nothing special the standard library can do that you can't. Android, for example, has a split implementation: https://cs.android.com/android/platform/superproject/+/master:system/core/libutils/include/utils/Vector.h https://cs.android.com/android/platform/superproject/+/maste... (I wouldn't use it, though, it's pretty outdated & shitty, but you can still do what you're talking about).

mehrdadn 6y ago

This was not intended to be an advertisement for C++. Nobody is begging you to use it. If you hate it, or otherwise don't understand its values and trade-offs, please don't use it.