5 ms·

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider th

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr). The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), but I think this is a conscious decision (and IMO the correct decision) to include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics. There's rhyme and reason to most of the most commonly used elements that is decidedly lacking from e.g. Python's (much more extensive) standard library.

geezerjay 8y ago
> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no widely adopted JSON or DB library for C++ then who in their right mind would believe it would be a good idea to force one into the standard? And don't get me started on the sheer lunacy of the proposal to add a GUI library. Talk about a brain-dead idea. People working on other programming language stacks already learned this lesson a lot of time ago. There's the core language and there's the never-ending pile of third-party modules. Some are well-made and well thought-out, others aren't. That doesn't matter, because these can be replaced whenever anyone feels like it. This is not the case if a poorly thought-out component is added to an ISO standard.
- barrkel 8y ago
  Standard libraries shouldn't include "leaf" modules, but probably should include interface / adapter modules. So no to JSON, but maybe yes to a serde interface. No to a database driver, but maybe yes to an interface like JDBC. Without common interfaces, flexibility in implementation is much more expensive, and innovation suffers too, as new things are harder to get off the ground without existing code that they can cheaply plug into.
  - daemin 8y ago
    There's an argument to be made for having basic so-called leaf modules in the standard library. That is it makes it far simpler to get a basic installation of C++ and start doing cool things with it. Experienced developers or people that need domain specific features would be using their own specialised libraries anyway. So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. You want to do a HTTP request, then there will be code in the standard library for that. It will also save work trying to figure out which third party library to use when you want to do these things locally on a small test project.
    - geezerjay 8y ago
      > So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. Congrats, now you're stuck with something like Xwindows or MFC or AWT.
      - pjmlp 8y ago
        Which while not ideal, are guaranteed to be present, contrary to third party libs.
        geezerjay 8y ago
        That assertion is disingenuous at best. That guarantee is only achievable at the expense of forcing compiler developers to maintain a GUI toolkig for all platforms. Who in their right mind believes that's reasonable or desirable?
        daemin 8y ago
        So instead of a GUI library what about a HTTP or a network library as part of the standard? Surely handling TCP and UDP connections is an order of magnitude easier to implement and maintain.
- adrianN 8y ago
  I believe that C++ needs a fat standard library because using third party libraries is a bit cumbersome in C++. Alternatively there could be a blessed build system that makes third party library integration as easy as Cargo or Go Modules.
  - Maken 8y ago
    I would say that CMake pretty much covers that. What it lacks is somehow a central registry, but I think C++ never intended to have one.
    - coldtea 8y ago
      What C++ intended and what C++ should have intended are two different things.
- coldtea 8y ago
  >I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. It's not obvious to me at all. In fact, if that was a valid argument, it would be for C++ not having a standard library at all, as everything (including vectors, strings, etc) also exists as "third-party modules".
  - humanrebar 8y ago
    Third party modules would be a huge mess if there weren't at least common interface types like std::string_view and std::unique_ptr.
  - geezerjay 8y ago
    > In fact, if that was a valid argument, it would be for C++ not having a standard library at all Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes. The Boost project is a very good example, so as the wealth of JSON and XML parsers. In fact, this lesson is so blatantly obvious that essentially all mainstream programming languages simply adopt official package managers and leave it to the community to develop and adop the components they prefer.
    - coldtea 8y ago
      >Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes. Java is very well served with its library. It would have been nowhere near as successful without it.
- gpvos 8y ago
  You're not disagreeing with colanderman: > (and IMO the correct decision)
- colanderman 8y ago
  > I strongly disagree No you don't. Read the rest of the sentence you quoted :)
Althorion 8y ago
> include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics Can you, from the top of your head, tell me what irregular modified cylindrical Bessel functions are and the last time you needed to use one? And yet, they were included in the standard library in C++17: https://en.cppreference.com/w/cpp/numeric/special_math/cyl_bessel_k https://en.cppreference.com/w/cpp/numeric/special_math/cyl_b...
- colanderman 8y ago
  I can't, but I bet they have a standard and well-accepted definition in the mathematical community. In fact, pretty much any real-valued mathematical function passes the test. The interface is settled, almost by definition since C++ functions are inspired by mathematical functions: pass in arguments, return result. Use range/domain exceptions or NaN for reporting such errors. The semantics are obvious: compute the named function. The interface is lowest-common-denominator: include float, double, and long double overloads. In fact, the same or similar interface is used in almost every language I've encountered. To contrast, the same is absolutely not true of e.g. a database module. I don't think I've ever seen two alike, disagreeing over even basic things such as whether the cursor or the transaction is the basic unit of interaction.
  - Althorion 8y ago
    There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those. If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could potentially think of to implement, there are hundreds of things that are orders of magnitude more useful to have and equally well-defined and standardized—even if we limit ourselves to mathematics alone, I’d much rather see basic constants like π or e included, or quaternions, or arbitrary precision integers, or decimal numbers… or dozens upon dozens of other things before that. But mainly, I find it impossible to maintain the claim that any general-usage language, like C++, that implements such niche functions is trying to keep its standard library small and ‘include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics’.
int_19h 8y ago
Surely JSON does have a settled, obvious, lowest-common-denominator semantics?
- colanderman 8y ago
  Of the design of a parsing and encoding library? Not at all. Do you parse as a stream or all in one go? Are values represented as a special "json" type, or as built-in types? How should arrays and objects be represented? Are integers and reals different types? Are trailing zero decimals significant? Do you allow construction of arrays and objects in any order, or only sequentially? (Granted, I've written my own C++ JSON library which I believe answers all these questions in an intuitive way, following both the design principles of the C++ standard library, and the lowest-common-denominator semantics of JSON, but it's sufficiently opinionated that I doubt I could convince any significant portion of C++ users that it's the "right" way to do things. Even if it "is", demonstrating such is nowhere near as easy as it is for unique_ptr, vector, string, thread, etc., each of which are more or less the "obvious" designs given certain constraints such as RAII to which the standard library adheres.)

geezerjay 8y ago

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no widely adopted JSON or DB library for C++ then who in their right mind would believe it would be a good idea to force one into the standard? And don't get me started on the sheer lunacy of the proposal to add a GUI library. Talk about a brain-dead idea. People working on other programming language stacks already learned this lesson a lot of time ago. There's the core language and there's the never-ending pile of third-party modules. Some are well-made and well thought-out, others aren't. That doesn't matter, because these can be replaced whenever anyone feels like it. This is not the case if a poorly thought-out component is added to an ISO standard.

barrkel 8y ago
Standard libraries shouldn't include "leaf" modules, but probably should include interface / adapter modules. So no to JSON, but maybe yes to a serde interface. No to a database driver, but maybe yes to an interface like JDBC. Without common interfaces, flexibility in implementation is much more expensive, and innovation suffers too, as new things are harder to get off the ground without existing code that they can cheaply plug into.
- daemin 8y ago
  There's an argument to be made for having basic so-called leaf modules in the standard library. That is it makes it far simpler to get a basic installation of C++ and start doing cool things with it. Experienced developers or people that need domain specific features would be using their own specialised libraries anyway. So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. You want to do a HTTP request, then there will be code in the standard library for that. It will also save work trying to figure out which third party library to use when you want to do these things locally on a small test project.
  - geezerjay 8y ago
    > So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. Congrats, now you're stuck with something like Xwindows or MFC or AWT.
    - pjmlp 8y ago
      Which while not ideal, are guaranteed to be present, contrary to third party libs.
      - geezerjay 8y ago
        That assertion is disingenuous at best. That guarantee is only achievable at the expense of forcing compiler developers to maintain a GUI toolkig for all platforms. Who in their right mind believes that's reasonable or desirable?
        daemin 8y ago
        So instead of a GUI library what about a HTTP or a network library as part of the standard? Surely handling TCP and UDP connections is an order of magnitude easier to implement and maintain.
adrianN 8y ago
I believe that C++ needs a fat standard library because using third party libraries is a bit cumbersome in C++. Alternatively there could be a blessed build system that makes third party library integration as easy as Cargo or Go Modules.
- Maken 8y ago
  I would say that CMake pretty much covers that. What it lacks is somehow a central registry, but I think C++ never intended to have one.
  - coldtea 8y ago
    What C++ intended and what C++ should have intended are two different things.
coldtea 8y ago
>I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. It's not obvious to me at all. In fact, if that was a valid argument, it would be for C++ not having a standard library at all, as everything (including vectors, strings, etc) also exists as "third-party modules".
- humanrebar 8y ago
  Third party modules would be a huge mess if there weren't at least common interface types like std::string_view and std::unique_ptr.
- geezerjay 8y ago
  > In fact, if that was a valid argument, it would be for C++ not having a standard library at all Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes. The Boost project is a very good example, so as the wealth of JSON and XML parsers. In fact, this lesson is so blatantly obvious that essentially all mainstream programming languages simply adopt official package managers and leave it to the community to develop and adop the components they prefer.
  - coldtea 8y ago
    >Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes. Java is very well served with its library. It would have been nowhere near as successful without it.
gpvos 8y ago
You're not disagreeing with colanderman: > (and IMO the correct decision)
colanderman 8y ago
> I strongly disagree No you don't. Read the rest of the sentence you quoted :)

Althorion 8y ago

> include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics Can you, from the top of your head, tell me what irregular modified cylindrical Bessel functions are and the last time you needed to use one? And yet, they were included in the standard library in C++17: https://en.cppreference.com/w/cpp/numeric/special_math/cyl_bessel_k https://en.cppreference.com/w/cpp/numeric/special_math/cyl_b...

colanderman 8y ago
I can't, but I bet they have a standard and well-accepted definition in the mathematical community. In fact, pretty much any real-valued mathematical function passes the test. The interface is settled, almost by definition since C++ functions are inspired by mathematical functions: pass in arguments, return result. Use range/domain exceptions or NaN for reporting such errors. The semantics are obvious: compute the named function. The interface is lowest-common-denominator: include float, double, and long double overloads. In fact, the same or similar interface is used in almost every language I've encountered. To contrast, the same is absolutely not true of e.g. a database module. I don't think I've ever seen two alike, disagreeing over even basic things such as whether the cursor or the transaction is the basic unit of interaction.
- Althorion 8y ago
  There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those. If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could potentially think of to implement, there are hundreds of things that are orders of magnitude more useful to have and equally well-defined and standardized—even if we limit ourselves to mathematics alone, I’d much rather see basic constants like π or e included, or quaternions, or arbitrary precision integers, or decimal numbers… or dozens upon dozens of other things before that. But mainly, I find it impossible to maintain the claim that any general-usage language, like C++, that implements such niche functions is trying to keep its standard library small and ‘include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics’.

int_19h 8y ago

Surely JSON does have a settled, obvious, lowest-common-denominator semantics?

colanderman 8y ago
Of the design of a parsing and encoding library? Not at all. Do you parse as a stream or all in one go? Are values represented as a special "json" type, or as built-in types? How should arrays and objects be represented? Are integers and reals different types? Are trailing zero decimals significant? Do you allow construction of arrays and objects in any order, or only sequentially? (Granted, I've written my own C++ JSON library which I believe answers all these questions in an intuitive way, following both the design principles of the C++ standard library, and the lowest-common-denominator semantics of JSON, but it's sufficiently opinionated that I doubt I could convince any significant portion of C++ users that it's the "right" way to do things. Even if it "is", demonstrating such is nowhere near as easy as it is for unique_ptr, vector, string, thread, etc., each of which are more or less the "obvious" designs given certain constraints such as RAII to which the standard library adheres.)