4 ms·
He referenced someone wanting to put a 2d graphics library into the standard library. That seems completely insane. IMHO, something should be in the standard l
by borland 8y ago
He referenced someone wanting to put a 2d graphics library into the standard library. That seems completely insane.
IMHO, something should be in the standard library if a large class of programs would want to use it, and if a "lowest common denominator" approach would be good enough for the majority of those
Example: JSON parsing and generation should be IN.
A tremendous number of programs want to produce and consume JSON, and the bulk of these are not performance critical and don't have too many edge cases. Just boring normal JSON.
Example: Sockets should be IN.
As above, vast numbers of programs want to use sockets and a standard approach would suit almost all of them perfectly well.
Example: Graphics should be OUT.
A lot of programs could potentially use a graphics library, but many of these would not be satisfied by a "standard" approach. Cross platform is the main thing - having to interface with GDI, SDL, Quartz, and whatever else, and doing a bad job of all of that.
- alexkcd 8y agoAgreed. Even if 2d graphics somehow made sense for standardization, it's not the place to start. How about first standardizing a linear algebra library that defines 2d/n-d vectors & matrixes? It's a prerequisite for an ergonomic 2d graphics library. And even such a library, which arguably has way more utility being in a standard, you'd still be hard pressed to find an optimal design (just look at design tradeoffs between glm, Eigen, etc.).
- pjmlp 8y agoWhich is exactly what the authors are now pursuing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1385r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p138...
- mattnewport 8y agoI wouldn't want to see json parsing in the C++ standard library. Sockets yes but not json. That is another domain better addressed with an improved package / dependency management story IMO.
- tmyklebu 8y ago> Example: Sockets should be IN. As above, vast numbers of programs want to use sockets and a standard approach would suit almost all of them perfectly well. I think the BSD socket library is that standard approach...
- th3l3mons 8y agoIt's been a few years but the libraries needed for different OSs changes. The source and imports needed between Linux and Windows differs. Also comes with some other baggage, like I don't recall if Windows offers a Unix socket implementation.
- epage 8y agoiirc the graphics proposal has gone through several iterations, including a std::web_view [0]. Yes, putting a web browser in the stdlib. I think I saw passing reference in a recent trip report that for now they are only focusing on math primitives [1]. [0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p110... See also https://www.reddit.com/r/cpp/comments/900dor/stdweb_view_proposal/ https://www.reddit.com/r/cpp/comments/900dor/stdweb_view_pro... [1] https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso_c_committee_trip_report_c20/ https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso...
- ioquatix 8y agoNone of the things you mention really need to be in stdlib. There are plenty of awesome options, and the great thing is, they all have their own pros/cons and you can choose depending on your requirements. The point of C++ is to avoid burdening you with costs you don't want to incur. Putting this stuff in stdlib is exactly that. If you could focus on modules and package management that didn't suck, would you still argue that you need to have JSON and high level sockets in stdlib?
- Waterluvian 8y agoCan you help me understand your concern? I'm not a c++ person. Is it that there's more stuff that needs to be packaged in even if it's not being used?
- stochastic_monk 8y agoI don’t think C++’s “Pay for what you use” applies here. You don’t have to use something just because it’s in the standard library. The only practical difference for a user is a larger binary when statically linking. (The burden on compiler developers is a very real concern, however.)