Hacker News Reader

Comment by favorited | Hacker News Reader

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.

View on HN

A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem

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++11 concepts would be a good idea.

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.

The Filesystem interface seems to assume the limitations of a Unix-like environment. No mention of extended properties or complex access control beyond what you'd see on a POSIX system.

Seems odd that the standard library for C++ would assume a particular operating environment.

Reply on news.ycombinator.com