Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What should go into the C++ standard library (2018)

abseil.io

Post reply on HN
Print view View original

31–40 of 91 posts

Re: What should go into the C++ standard library (2018)

#31

Post by favorited »

mlindner wrote: post #26
favorited wrote: post #19

Earlier quoted context omitted.

There's also some glaring holes. It will be nice to eventually have idiomatic (and cross-platform) support for networking, filesystem operations, maybe more modern format strings, etc.

A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem

Yes, but it is new in C++17 (which a lot of people can't use yet), and I'm not advocating the graphics proposal specifically.

My point is that you can't just use "the standard library is already really big" as a justification for not adding new things which make working with the language much nicer.

Re: What should go into the C++ standard library (2018)

#32

Post by pcwalton »

I've unfortunately been dragged into some of the conversations around the proposed 2D graphics library (despite trying to avoid them), and the proposal is awful. It's a mid-'90s vector graphics proposal that is inadequate for fast GPU-accelerated rendering. A modern library that aimed to be actually used in the industry would probably look more like WebRender (though WebRender's API is admittedly a bit of a mess, the principles are sound). There is no way that browsers or PDF readers or Illustrator or Toon Boom Harmony or whoever else does vector graphics in industry would ever use the C++ proposal.

When I brought this up, the proponents of the library dug in their heels and said that it's not intended for apps like Flash, PDF readers, and browsers, but rather intended for (a) teaching and (b) for companies that have prohibitions on using third-party code. The teaching use case (a) is unconvincing, because while Logo was indeed a good teaching tool and it'd be great to resurrect it, there's no need to do so in the standard library. As far as I could tell, the real reason was (b) for the proponents of the spec, and, needless to say, that's a horrible reason to put something in the standard library. It's effectively an attempt to route around some random dysfunctional company policy by saddling everyone with a burden for all time.

Re: What should go into the C++ standard library (2018)

#33

Post by ryandrake »

ndesaulniers wrote: post #7

Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.

Please, no.

We don’t need yet another package manager. Every language seems to have to have its own package manager, separate from my operating system’s package manager, that does exactly the same thing but in an incompatible way.

Now, if I want to know what software I have on my system, I need to use five different list commands instead of just one. If C++ had its own package manager, that would mean six. Please help to stop this madness, not perpetuate it.

Re: What should go into the C++ standard library (2018)

#34

Post by dleslie »

mlindner wrote: post #26
favorited wrote: post #19

Earlier quoted context omitted.

There's also some glaring holes. It will be nice to eventually have idiomatic (and cross-platform) support for networking, filesystem operations, maybe more modern format strings, etc.

A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem

The Filesystem interface seems to assume the limitations of a Unix-like environment. No mention of extended properties or complex access control beyond what you'd see on a POSIX system.

Seems odd that the standard library for C++ would assume a particular operating environment.

Re: What should go into the C++ standard library (2018)

#35

Post by mlindner »

favorited wrote: post #31
mlindner wrote: post #26

Earlier quoted context omitted.

A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem

Yes, but it is new in C++17 (which a lot of people can't use yet), and I'm not advocating the graphics proposal specifically. My point is that you can't just use "the standard library is already really big" as a justification for not adding new things which make working with the language much nicer.

I agree for the most part, but we should only really be adding standard libraries for things that people normally have to fall back to the C standard library/POSIX code for when writing C++ code. Things like filesystem operations was one of those. Threading was another. Networking is probably another. Format strings I would not include in that, though updating the existing string formatting libraries for the newer C++11 concepts would be a good idea.

Re: What should go into the C++ standard library (2018)

#36

Post by quotemstr »

ndesaulniers wrote: post #7

Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.

There are plenty of ways to organize C++ code, including several package managers. Why should a language -- a specification for a grammar and an abstract machine to run programs using it --- specify things so concrete as the way you download code? It might as well dictate what editor you use.

We need less, not more, conflation between languages, runtime environments, build systems, and package repositories. It's senseless to couple these concepts.

Re: What should go into the C++ standard library (2018)

#37

Post by jeffdavis »

ryandrake wrote: post #33
ndesaulniers wrote: post #7

Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.

Please, no. We don’t need yet another package manager. Every language seems to have to have its own package manager, separate from my operating system’s package manager, that does exactly the same thing but in an incompatible way. Now, if I want to know what software I have on my system, I need to use five different list commands instead of just one. If C++ had its own package manager, that would mean six. Please hel…

It's not madness; each approach has problems.

In particular, distros generally work best when one version is enough, or maybe a few versions. Anything else leads to dependency hell.

Re: What should go into the C++ standard library (2018)

#38

Post by alexkcd »

borland wrote: post #12

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…

Agreed. 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.).

Re: What should go into the C++ standard library (2018)

#39

Post by maxxxxx »

roel_v wrote: post #13
maxxxxx wrote: post #2

I am little sceptical and also curious about the Graphics library. Is this meant as a building block for more advanced graphics? Or do you still need to use things like DirectX if you need speed and features?

Someone motivated could build an implementation that uses Direct2D underneath. I think MS has one already. There are provisions in the proposal to expose handles to the underlying graphics systems, for example if you want to render text with DirectWrite (or Pango/Harfbuzz if you're using a Cairo-based implementation). Of course without the appropriate ifdefs this would make your code non-portable at that point. But y…

After reading other responses I agree that the Graphics library should be done by somebody like Boost. It makes no sense to have it in the standard,

Re: What should go into the C++ standard library (2018)

#40

Post by vlovich123 »

quotemstr wrote: post #36
ndesaulniers wrote: post #7

Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.

There are plenty of ways to organize C++ code, including several package managers. Why should a language -- a specification for a grammar and an abstract machine to run programs using it --- specify things so concrete as the way you download code? It might as well dictate what editor you use. We need less, not more, conflation between languages, runtime environments, build systems, and package repositories. It's sens…

And yet having coded in Rust, Cargo solves all this bikeshedding. You can of course use your own build system but Cargo is pretty consistently used across the board which finally makes developing in a systems language as easy as Python (like virtualenv & pip but better).
Post reply on HN