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

51–60 of 91 posts

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

#51

Post by Reelin »

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…

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 indicated by the name. That's consistent with at least OpenGL and Java's AWT, but I think also DirectX and most other APIs.

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

#52

Post by kevin_thibedeau »

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't fossilize.

That being said. I'd like to see libAgg get more support as it's somewhat drifting in the wind and it has a nicely designed composable rendering pipeline that aligns well with C++ principles.

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

#53

Post by epage »

htfy96 wrote: post #21
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.

The problem is that the community has already diverted in the way to organize sources, and each of them believes they have the best solution. Similarly, all C++ issues originate from the fragmentation of community: some (maybe 2/3) prefer include a network lib because it facilitates their daily development, while others (maybe 1/3) may have different ideas because they don't use it/they need performance over usabilit…

The concern over fragmentation is why believe conan's approach is the best: decouple dependency management from build rather than forcing everyon to align on build.

Still has its hurdles but it is a step in the right direction for trying to wrangle the wild west of C++.

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

#54

Post by [deleted] »

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…

[deleted]

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

#55

Post by epage »

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…

iirc 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/p110... See also https://www.reddit.com/r/cpp/comments/900dor/stdweb_view_pro...

[1] https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso...

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

#56

Post by erik_seaberg »

jeffdavis wrote: post #37
ryandrake wrote: post #33

Earlier quoted context omitted.

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.

Dependency hell comes from binaries that insist on not using the shared library provided by the distro through the package manager. Windows suffered from not having a package manager in the dark ages, leaving installers to silently clobber each others' changes.

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

#57

Post by ioquatix »

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 argue that you need to have JSON and high level sockets in stdlib?

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

#58

Post by pjmlp »

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.

Only when writing portable code isn't a concern.

No one has time to publish their library into the myriad of OS specific package managers that are out there.

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

#59

Post by pjmlp »

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 have better third party alternatives.

Yet for some magic reason it is ok for them to be part of the standard library, while graphics are not allowed to.

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

#60

Post by pjmlp »

alexkcd wrote: post #38
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 bet…

Which is exactly what the authors are now pursuing.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p138...

Post reply on HN