3 ms·

There's enough stuff in it already.

favorited 8y ago
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.
- mlindner 8y ago
  A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem
  - favorited 8y ago
    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.
    - mlindner 8y ago
      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.
      - tmyklebu 8y ago
        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.
  - dleslie 8y ago
    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.

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.

mlindner 8y ago
A graphics API is not one of those holes though. Filesystem library already exists. https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem
- favorited 8y ago
  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.
  - mlindner 8y ago
    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.
    - tmyklebu 8y ago
      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.
- dleslie 8y ago
  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.