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

71–80 of 91 posts

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

#71

Post by th3l3mons »

tmyklebu wrote: post #48
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…

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

It'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.

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

#72

Post by th3l3mons »

flatline wrote: post #25
jshap70 wrote: post #10

Earlier quoted context omitted.

You also inherit an entire chain of trust over code you yourself didn't write nor did anyone actually validate. The issue with leftpad.js wasn't that it was stupid, it was that it was dangerous.

That concern is somewhat orthogonal to the utility of a package manager itself. If you are using OSS in any way you need to pick and choose what you take on as a dependency. The package manager solves problems like distribution, dependency resolution, and discovery. The ease of use may contribute to poor decision making, which should not be wholly discounted.

To piggy back, this also goes down the dependency chain. Leftpad wasn't bad because it was being used directly. Projects imported other libraries which either directly pulled leftpad or, more likely, pulled another library which may be the calling party or not.

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

#73

Post by kllrnohj »

btmorex wrote: post #30
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 would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor. Also, who says the game will control the loop? In Javascript (requestAnimationF…

> I would guess that io2d::refresh_style::as_fast_as_possible means as opposed to Vsync. Vsync times drawing or at least buffer swapping so that you don't get video artifacts due to the monitor reading say half of one frame and half of another. Vsync is not as fast as possible assuming you can render faster than 60 fps on a typical monitor.

That'd be a reasonable theory except it's not how any of this works anymore. Unless you are exclusive fullscreen it's not possible to get tearing on any modern compositor. Window's DWM, Android's SurfaceFlinger, Linux's Wayland, etc... on all of those you're drawing to an offscreen surface, and when you flip it doesn't go directly to the display it goes to the compositor. You're basically always vsync'd by the compositor. So for a windowed application what you really want is more like Android's Choreographer, or JavaScript's requestAnimationFrame - a callback that just says "hey if you want you could redraw now" for rate limiting purposes more than anything else.

And even if you are exclusive fullscreen there's things like adaptive vsync or even just choosing an alternate refresh rate.

> Also, who says the game will control the loop? In Javascript (requestAnimationFrame) and many other frameworks, that's not true.

requestAnimationFrame is simply a callback and entirely optional. That'd be backpressure control more than anything else, and you'd still have things like input intermixed with it.

Also C++ has threads, so discussing games or loops in JavaScript vs. C++ doesn't really apply in the same ways.

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

#74

Post by pjmlp »

pcwalton wrote: post #69
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…

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.

I pretty much doubt that, many apps would be already well served with a BGI like library.

Plenty of application developers are more than happy with a Swing/GDI like canvas.

Not everyone needs to be an OpenGL shader guru to draw a couple of lines.

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

#75

Post by 0x8BADF00D »

shaklee3 wrote: post #29
0x8BADF00D wrote: post #27

I’ve had many discussions with my coworkers about this. The standard library is scary to me, completely over engineered. We should be dumping shit from the standard library that makes no sense (ostream anyone?). Don’t get me started on iterating over containers. C++20 is shaping up to be the way to hell paved with good intentions.

Can you elaborate on iterating over containers? What don't you like?

Pretty much everything about it is unwieldy. We had std::begin and std::end, now we have legitimate ranges. It is still difficult to iterate over customized STL containers, or even generic ones you specify. I’m looking for something like takeWhile.

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

#76

Post by coldtea »

pcwalton wrote: post #69
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…

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.

>The number of apps that would use a bad 2D graphics standard, however, is zero.

You'd be surprised. Just because they would be there, readily usable, and portable, would make them be adopted.

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

#77

Post by coldtea »

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…

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

And why, pray tell, are those "pretty bad"?

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

#78

Post by coldtea »

flukus wrote: post #44
azhenley wrote: post #9

Earlier quoted context omitted.

Couldn't agree more about package managers. I just went back to C and have spent too many hours trying to get small libraries to build and link properly. I'm pulling my hair out.

I'm guessing your on an OS without a package manager or not making use of it? Having the OS handle it is a much better solution than having every single language come up with it's own solution.

>I'm guessing your on an OS without a package manager or not making use of it?

That's really irrelevant, and not the proper way to install programming dependencies for developers. It's for installing system dependencies (including libs) and to build software for the system (e.g. as a system admin/user you want to build X and it needs the -devel package installed), not for developers on their projects.

Nobody (or very few) in Rust, Python, Ruby, Go, Java etc would ever use the "system package manager" for installing their language's third party libs.

For one, you don't want to pollute the system with your program's deps.

Second, you want to have isolated, different versions, of various dependencies, only visible to this or that project you work on, not to the whole system.

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

#79

Post by Reelin »

kllrnohj wrote: post #70
Reelin wrote: post #51

Earlier quoted context omitted.

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…

Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern API absolutely must be able to support the use of other color spaces when requested.

> Most APIs that do [0, 255] are assuming sRGB

I admit that I've almost exclusively used OpenGL so my impression is far from expert, but I don't think this is correct. My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified. In particular, my understanding is that OpenGL works almost exclusively in a linear color space except for a few specific sRGB image formats and a few specific functions. For arbitrary non-linear color spaces I would generally expect to need to select a backing format of the necessary bit depth, output linear values, manually apply a conversion function, and then somehow indicate to the underlying hardware what color space to use when displaying my image data to the user.

> OpenGL actually works like I said - the float values are not limited to [0.0, 1.0].

Agreed, I never meant to imply otherwise. However, do note that when outputting values from a fragment shader their range (and type) has to match what the GPU is expecting. So in practice, unless you're using a floating point image format (such as GL_RGBA32F) your output range is going to be limited. Personally I almost always use unsigned normalized formats.

> This all matters because there is no longer any platform on which sRGB can be safely assumed to be the overwhelming majority.

I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use. Of course it goes without saying that all conversions must be handled correctly! Importantly, I'm not trying to claim that such a limited design would be a good one. Rather, my point is simply that conversions between color spaces are purely an implementation detail provided you have sufficient bit depth to work with.

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

#80

Post by kllrnohj »

Reelin wrote: post #79
kllrnohj wrote: post #70

Earlier quoted context omitted.

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…

Apologies, what I wrote wasn't very clear. I didn't mean to imply that an API should only be able to handle such values, just that a linear color space is the only sane default in my opinion. And I most certainly didn't mean to imply that color channels should be limited to only 8 bits, just that it's a very common default (and often sufficient for simple tasks). As you very rightly point out, any even semi-modern AP…

> My (admittedly limited) experience is that a linear color space is assumed unless otherwise specified.

Non-linear blending is very common. Do a CSS gradient, for example, and it'll happen in sRGB gamma space not linear space, giving you incorrect results.

Linear should be used more than it is, though, definitely.

> I'd just like to point out that in principle, a hypothetical API could handle all programmer interactions in a single color space (eg linear) and then transparently convert as appropriate for the display device currently in use.

Linear isn't a colorspace. Linear is about the gamma function, which is independent of the actual colorspace.

sRGB can be both linear & non-linear. In the absence of something specifying sRGB assumes a non-linear gamma function of 2.2, but it doesn't always. Linear sRGB is very much A Thing. If you're from the OpenGL world then you may be thinking of EGL_GL_COLORSPACE_LINEAR_KHR? If so, that's linear sRGB. If you wanted to output, say, Display_P3, then you need to use EGL_GL_COLORSPACE_DISPLAY_P3_LINEAR_EXT instead.

But you can very much do a single color space. That'd be the linear extended sRGB I originally talked about, which is float in the range of -.5 to 7.5. Also called scRGB. Microsoft makes use of this as of Windows Vista.

Post reply on HN