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

61–70 of 91 posts

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

#61

Post by pjmlp »

vlovich123 wrote: post #40
quotemstr wrote: post #36

Earlier quoted context omitted.

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

Not really, cargo still doesn't provide an answer for binary libraries, and depending on how the workspace is configured and the projects one is compiling, it may end up compiling the same crates multiple times.

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

#62

Post by dblohm7 »

pjmlp wrote: post #59
pcwalton wrote: post #32

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, th…

I am on the other side of the fence. First because I have found memories for Borland's BGI and there is hardly something like that for C and C++ that works easily everywhere. Secondly, because the attacks against the graphics proposal, could be equally used against iostreams, filesystem or networking. Not every platform where C++ runs can support them, none of them fully supports modern OS features and all of them ha…

I strongly agree that networking should not be in there either.

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

#63

Post by scoutt »

I always dreamed with a standardized, cross-platform, cross-arch, (sort of) automatic, non-blocking, DMA-based memory copying functions (like a special memcpy) for duplicating or passing big chunks of memory (like for example, H.264 frames or network packets, from a driver to user space).

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

#64

Post by AstralStorm »

kevin_thibedeau wrote: post #52
pcwalton wrote: post #32

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, th…

The 2D effort is a complete waste of time. If they plan to include font support it will be a total nightmare. Anyone that needs graphics rendering can choose from a mature range of libraries that best suits their needs. There is zero need for something like that in the standard lib. They should learn from the example of Python where first class libraries are intentionally left out of the standard lib so that they don…

If they want to steal an API, SDL exists and can be modernized.

Again, no need for this in standard library when there are reasonable libraries with good licenses around.

Agg is weak in comparison, though it has a few cute things going for it.

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

#65

Post by AstralStorm »

dblohm7 wrote: post #62
pjmlp wrote: post #59

Earlier quoted context omitted.

I am on the other side of the fence. First because I have found memories for Borland's BGI and there is hardly something like that for C and C++ that works easily everywhere. Secondly, because the attacks against the graphics proposal, could be equally used against iostreams, filesystem or networking. Not every platform where C++ runs can support them, none of them fully supports modern OS features and all of them ha…

I strongly agree that networking should not be in there either.

It's already there in POSIX C. (Winsocks is almost compatible.) The C++ basic version actually would be good to have. Potentially a basic threaded version too.

Unlike graphics which is a moving target, even 2D. Where do you stop? Bezier paths with subdivision and full blended gradient support for those? Nonlinear projections? Fonts? Text composition?

If you bite off too much, you end up with the OpenGL problem where nobody implemented everything.

The example of a pretty bad implementation of 2D would be a) Cairo b) whatever Android and Chrome uses for drawing.

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

#66

Post by pjmlp »

AstralStorm wrote: post #65
dblohm7 wrote: post #62

Earlier quoted context omitted.

I strongly agree that networking should not be in there either.

It's already there in POSIX C. (Winsocks is almost compatible.) The C++ basic version actually would be good to have. Potentially a basic threaded version too. Unlike graphics which is a moving target, even 2D. Where do you stop? Bezier paths with subdivision and full blended gradient support for those? Nonlinear projections? Fonts? Text composition? If you bite off too much, you end up with the OpenGL problem where…

POSIX C doesn't do HTTP/S, asynchronous networking, and isn't available in all platforms supported by C++ compilers.

Should it handle SSL, TLS, http routing, HTML templates,....

Where do you stop CSS, JS bundlers?

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

#67

Post by Waterluvian »

ioquatix wrote: post #57
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…

None 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 ar…

Can 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?

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

#68

Post by stochastic_monk »

ioquatix wrote: post #57
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…

None 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 ar…

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

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

#69

Post by pcwalton »

pjmlp wrote: post #59
pcwalton wrote: post #32

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, th…

I am on the other side of the fence. First because I have found memories for Borland's BGI and there is hardly something like that for C and C++ that works easily everywhere. Secondly, because the attacks against the graphics proposal, could be equally used against iostreams, filesystem or networking. Not every platform where C++ runs can support them, none of them fully supports modern OS features and all of them ha…

Plenty of industry applications that need to deal with files use iostream. The number of apps that would use a bad 2D graphics standard, however, is zero.

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

#70

Post by kllrnohj »

Reelin wrote: post #51
kllrnohj wrote: post #11

Earlier quoted context omitted.

In terms of the proposal itself it appears to be like an SDL type of thing. It has a basic way to create an output surface and then draw on it. Implementations on Windows may opt to do that with Direct2D. But... it gets a lot of stuff really wrong. Like why does outputsurface have an "fps" argument on the constructor? What on earth is io2d::refresh_style::as_fast_as_possible supposed to mean? That doesn't really map…

I do agree that this sort of thing doesn't belong in a language standard. I haven't looked at the proposal myself, but regarding your complaint about rgba_color float values being on [0.0, 1.0] this is super standard in my experience. I would expect any well designed API to map [0.0, 1.0] to pixel values on [0, 255] unless otherwise clearly noted. Color spaces other than raw pixel values I would expect to be indicate…

Common, yes, but wrong in ways that increasingly matter. Most APIs that do [0, 255] are assuming sRGB or they take a color space but can only really handle slightly-wider colorspaces like DISPLAY_P3.

OpenGL actually works like I said - the float values are not limited to [0.0, 1.0]. There is no clamping in the GPU pipeline, and a transfer function can be applied to choose between linear & non-linear. For details see extensions like https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_... or https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_...

This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority. Nearly all new flagship mobile devices are DISPLAY_P3. Nearly all TVs are already some form of HDR, and desktop monitors are rapidly following suit (Rec. 2020 & 10-bit, so [0, 255] doesn't even cover enough bits).

So anything graphics that doesn't already work with colorspaces in some way is basically abandoned or dying, and anything new that doesn't work with them is going to be DOA.

Post reply on HN