3 ms·

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious

> 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.
        pjmlp 8y ago
        Everyone that wants a language to thrive instead of dealing with thousand incompatible implementations. Many C++ targets don't support IO or networking, so lets not burden embedded compiler developers with standard library bloat.
    - daemin 8y ago
      They're standard for the OS but not a standard for the programming language library. Granted AWT wasn't great but you could still make a GUI with it straight out of the box. It allowed you to make windows and buttons and start exploring the programming language. Like I said having a standard library option won't eliminate third party libraries, it will just provide something in the box for people to start using straight away.
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 :)

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.
      - pjmlp 8y ago
        Everyone that wants a language to thrive instead of dealing with thousand incompatible implementations. Many C++ targets don't support IO or networking, so lets not burden embedded compiler developers with standard library bloat.
  - daemin 8y ago
    They're standard for the OS but not a standard for the programming language library. Granted AWT wasn't great but you could still make a GUI with it straight out of the box. It allowed you to make windows and buttons and start exploring the programming language. Like I said having a standard library option won't eliminate third party libraries, it will just provide something in the box for people to start using straight away.

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 :)