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

11–20 of 91 posts

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

#11

Post by kllrnohj »

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?

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 to anything sane. UIs certainly don't behave like that at all, they only redraw on-demand. Even for a game which does refresh "as fast as possible" it still does that with its own game loop which will involve more than drawing, and often pipelined anyway.

Why does rgba_color, even though it's 4 floats, only have a valid range from 0.0 to 1.0 with no mention of color space? It seems like it's supposed to be linear, but in that case it should be linear extended sRGB, which has a valid range of -0.5 to 7.5.

Or like you can query for display_dimensions, but which display?

Adding this to a standard would definitely be a huge mistake. It may make a useful beginners library for just quickly getting up to doodling on the screen, but that's sort of it. You'd never build an actual shipping product off of this proposal.

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

#12

Post by borland »

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.

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

#13

Post by roel_v »

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 yeah, as much as I would love to have an out of the box cross platform (2d) graphics library, I worry that by standardizing it, it'll be susceptible to being left behind very soon. Not even mentioning that there is so much stuff 'missing' in the current proposal - like what other color spaces? Image formats? I'd much rather have a graphics library in Boost that can evolve over time, and for people to stop complaining about / shitting on Boost; and maybe a way to have Boost packages work with a package manager, in a way so that you can pick and choose the components you need.

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

#14

Post by raphlinus »

kllrnohj wrote: post #11
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?

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…

The dirty secret is that it's basically Cairo, a 1990's graphics API, with modern C++ syntax. So all of the work that's happened since then, including HDR color spaces, precise control of swapchain present, dynamic multimonitor support, doesn't exist. I also got a chuckle out of chapter 10, text (basically TBD, like that's not one of the biggest of all possible cans of worms).

In fairness, piet is currently missing the fancy stuff too. But I'm hopeful we'll get there, in part because we can afford to break compatibility.

(Going deep into the weeds, presentation doesn't belong at the piet level, but, in my stack, at the druid-shell level. I'm working on this, using quantitative measurements of latency and power dissipation. But it's all evidence that this stuff is quite hard, and Titus is absolutely right that putting it in to a language standard is folly)

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

#16

Post by favorited »

gowld wrote: post #8

Why does string need/deserve to be in the standard? Doesn't the existence of cord cast doubt on thst?

string is a common-currency type. I don't want to be converting between char* and vector and custom::unicode_string, etc. because each API or library has their own slightly specialized version. (anymore than we already do, anyway)

Most of the time, std::string is fine, so I expect there to be APIs exchanging string data using std::string.

Rope/cord is a domain-specific data structure. If I was building software which was constantly modifying ranges of text, then rope might be a good choice.

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

#17

Post by nicoburns »

jshap70 wrote: post #10
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.

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.

You get just as much trust with officially maintained, but non-std libraries as you do from std...

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

#18

Post by cmrdporcupine »

gowld wrote: post #8

Why does string need/deserve to be in the standard? Doesn't the existence of cord cast doubt on thst?

Back in the dark ages of 1990s C++, it seemed liked every single project had its own custom string class. Things coalescing around std::string, as imperfect as it is, is a huge relief.
Post reply on HN