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

41–50 of 91 posts

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

#41

Post by nicoburns »

wvenable wrote: post #24
nicoburns wrote: post #17

Earlier quoted context omitted.

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.

If they are officially maintained, then by definition they are written and maintained by the same organisation as the std library.

The difference is, having an external library allows it to be versioned with breaking changes if necessary, without breaking consumers.

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

#42

Post by mattnewport »

I mostly agree with this article and have been of the opinion for a while that graphics has no place in the standard library and that what is really needed is a better cross platform build, packaging and dependency management story.

I would quibble with the hash table example though. I think there is a case to be made not for changing unordered_map but for adding a new standard hash table with somewhat different guarantees that make it suitable for higher performance implementations. Hash tables are so widely useful that a better standard option without breaking backwards compatibility seems worthwhile. Other languages have standard libraries that evolve in this way and while it can get out of hand (looking at you C#) it's a reasonable solution in moderation.

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

#43

Post by sebcat »

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.

I like the absence of a package manager at the language level and the embracing of shared objects and stable ABIs by using the OS package manager. Missing a library? Just install it, and list it as a dependency in the .spec-file, or whatever packaging system you use.

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

#44

Post by flukus »

azhenley wrote: post #9
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.

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.

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

#45

Post by mattnewport »

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…

I wouldn't want to see json parsing in the C++ standard library. Sockets yes but not json. That is another domain better addressed with an improved package / dependency management story IMO.

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

#46

Post by tmyklebu »

Just picking a couple quotes from the article:

> Especially when you compare C++ to other languages, there’s a pretty strong argument to be made for a more inclusive and even all-encompassing standard library - look at the richness of the standard libraries for Java or Python.

What is that argument? And even if you accept that argument, can we execute? That is, will the result be at least of a similar quality, or will it be riddled with subtle gotchas and sharp edges like the existing C++ standard library?

> So, what should go in the standard library? Fundamentals. Things that can only be done with compiler support, or compile-time things that are so subtle that only the standard should be trusted to get it right. Vocabulary. Time, vector, string. Concurrency. Mutex, future, executors.

Can the standard be trusted to get these things right?

- Vocabulary: There's a fair amount of depth to what "right" means for vector and string in many contexts, so the standard can only be trusted to get them "right" in cases that have very few constraints (where it can do admirably). Implementors have been known to break the ABIs of std::vector and/or std::string between compiler/library versions, so they aren't appropriate types to use in interfaces.

- Concurrency: Leaving aside the C++ memory model, the library support should largely be avoided. For an example of why: std::condition_variable's ctor either takes another condvar or no arguments. pthread_cond_init takes a pthread_condattr_t. On Linux, this can specify a clock. On my system, if you want to wait for a second according to CLOCK_MONOTONIC/std::chrono::steady_clock on my implementation, condition_variable::wait_until will convert your time to CLOCK_REALTIME/system_clock (by now()ing both clocks and adding the difference to the deadline you supplied) and sleep until the converted time. That's not what you asked for; it's totally wrong and possibly dangerous.

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

#47

Post by marcus_holmes »

As the title says, put Go in there ;)

Seriously, Go's standard library is the best I've ever used, and would make a great case study for the "batteries included" case.

But it doesn't have a good story at all around graphics, 2D, 3D or UI. That doesn't bother gophers much, because the language was(is) intended to build servers with. But for C++, different story.

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

#48

Post by tmyklebu »

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

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

#49

Post by tmyklebu »

mlindner wrote: post #35
favorited wrote: post #31

Earlier quoted context omitted.

Yes, but it is new in C++17 (which a lot of people can't use yet), and I'm not advocating the graphics proposal specifically. My point is that you can't just use "the standard library is already really big" as a justification for not adding new things which make working with the language much nicer.

I agree for the most part, but we should only really be adding standard libraries for things that people normally have to fall back to the C standard library/POSIX code for when writing C++ code. Things like filesystem operations was one of those. Threading was another. Networking is probably another. Format strings I would not include in that, though updating the existing string formatting libraries for the newer C+…

Threading was a structurally different change from fs operations and networking. You need the compiler to cooperate when you're writing to a location in one thread and reading it from another. You can either get there using hacks built on escape hatches like 'asm volatile' or by specifying some semantics for the operation. Specifying a memory model, however imperfect, means we can move away from the implementation-dependent hacks.
Post reply on HN