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

21–30 of 91 posts

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

#21

Post by htfy96 »

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 usability/they want to use this on embedded systems/their own stdlib fork doesn't want to support it. Meanwhile the committee cannot enforce everyone in the community to do something because it has no real-world control on either compiler dev/user community.

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

#22

Post by jepler »

What should go into the C++ standard library? A liberally licensed reference implementation, where possible. A testsuite, where possible.

("Where possible" would certainly cover all the containers, all the algorithms, etc; it's less clear how you'd provide a reference implementation of something that needs to use low level OS functionality for its implementation, such as 'operator new' or 'ofstream')

Of course, it would also be nice if timely bugfixes went into the C++ standard library. For instance, std::generate_canonical was standardized in C++11, had an "issue" lodged in 2015, and the "new specification for std::generate_canonical" is still awaiting proposed wording (last updated a year ago, cough, so ... maybe in C++23?)

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

#24

Post by wvenable »

nicoburns wrote: post #17
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.

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

I disagree. Especially if those non-std libraries are built on other non-std libraries and so on. Trusting a single organization is much easier than trusting a chain of organizations.

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

#25

Post by flatline »

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.

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.

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

#26

Post by mlindner »

favorited wrote: post #19
njbooher wrote: post #15

There's enough stuff in it already.

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

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

#27

Post by 0x8BADF00D »

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.

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

#28

Post by flatline »

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’s conan-center, but it’s still rather sparse.

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

#29

Post by shaklee3 »

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?

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

#30

Post by btmorex »

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 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 (requestAnimationFrame) and many other frameworks, that's not true.

Post reply on HN