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.
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.
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.
Congrats, now you're stuck with something like Xwindows or MFC or AWT.
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.
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?
Many C++ targets don't support IO or networking, so lets not burden embedded compiler developers with standard library bloat.
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".
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.
Java is very well served with its library. It would have been nowhere near as successful without it.
No you don't. Read the rest of the sentence you quoted :)
> (and IMO the correct decision)
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_b...
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.
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’.
Why do these functions bother you so much? It can't be namespace pollution; they're under std::. It can't be that you disagree with their interface or semantics, since by your own admission you don't even know what they are.
You named some other features, such as quaternions, that you think would be better for implementors to spend their time on, but surely you can imagine someone like yourself who is tired of having to define the Bessel functions every time they start a new project, and can't imagine why the C++ committee saw fit to include something so useless and obscure as quaternions before getting to Bessel functions.
Yeah. I must have misunderstood your definition of ‘obvious’—I though you meant ‘an obvious inclusion to the standard library’, not ‘having an obvious definition’. The definition is obvious, why they should be in a standard library is not.
> […] since by your own admission you don't even know what they are
I mostly do—I studied mathematics. Or, to be more precise, I learned about them, then never used them in programming, had to remind myself what they were and even after that, I don’t find them useful enough to warrant an inclusion to the standard library. Thus, since they were included, I think that’s a good evidence of C++ committee not trying to keep its standard library concise.
> You named some other features, such as quaternions, that you think would be better for implementors to spend their time on, but surely you can imagine someone like yourself who is tired of having to define the Bessel functions every time they start a new project, and can't imagine why the C++ committee saw fit to include something so useless and obscure as quaternions before getting to Bessel functions.
The thing is, I can’t. If you use them, you want a better support for solving differential equations than C++ offers anyway, so it’s more of a ‘OK, I have this small part already implemented, but I still have to find ways of doing the rest 95%’. This, plus the fact that I’m quite certain that people using C++ to do 3D geometry outnumber people using it for solving differential equations by a few orders of magnitude—a cursory glance at GitHub showed me that the only projects in C++ that mention it are… implementations of a standard library (and forks upon forks of those).
My problems with this is that C++ is now in a very strange place—it implements some very high level, niche features, bloating the language and its implementations (the size of glibc is a practical problem) while still lacking many others, that seem much more ‘obvious’ (i.e. ‘if given an unknown language, I would be much less surprised to find them included in its standard library). In the end, I have a language that both has annoyingly big standard library and heavily relies on other, non-standard ones for quite a lot of things.
(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.)
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.