3 ms·

This is somewhat misleading, it's a proposal to add 2D graphics to the C++ standard library which will hopefully die in committee. This isn't something like th

This is somewhat misleading, it's a proposal to add 2D graphics to the C++ standard library which will hopefully die in committee. This isn't something like threading or filesystem access where we need to put it in the standard library because it abstracts platform differences. This isn't something like std::unordered_map or std::sort where it's so universally useful that we want to put it in the standard library. No, this is extra functionality that should be in a third-party library. Honestly, it worries me a little bit that such a prominent member of the C++ committee came up with such an ill-advised proposal, and it makes me worry that the success of C++11 has gone to their heads. What I don't understand is why someone would even be unhappy that this is not part of the standard library, since this kind of stuff has been available in third-party libraries for years. You shouldn't be clamoring for inclusion in the C++ standard, you should be calling for better third-party library support in your tooling!

blablabla123 11y ago
Not sure if that's really because of C++ or because they want to add just more out-of-the-box functionality to the standard libary. Java has been very successful with its large standard library. Also we have seen nows so many 2D graphics library code, it should be possible to come up with functionality that will still make sense in 20 or 30 years.
kamac 11y ago
> You shouldn't be clamoring for inclusion in the C++ standard, you should be calling for better third-party library support in your tooling! This. Honestly after C++11 the stuff they're adding is scarcely useful, it mostly just complicates the language itself even more than it currently is. They're trying to change the way you write C++ code without removing support for the old ways. I feel like they should make a new language instead of adding mostly useless things/stuff that barely anybody will use (could be also because barely anybody will know of that feature's existance)
- m3koval 11y ago
  Concepts, modules, a file system library, and an asynchronous I/O library have all been discussed as additions for C++17 and beyond. Most of these features are standard in modern languages. I would not consider any of these to be "scarcely useful." As someone who uses C++11 on a daily basis, I very much look forward to using these features without a Boost dependency. That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned.
  - kamac 11y ago
    I forgot to add "mostly scarcely useful", instead of "scarcely useful". There are some things that make sense, like file system library and async I/O library that you've mentioned (althrough I don't agree on concepts and modules, but that's up to one's preference), but then comes stuff like constexpr, rvalue reference, Deleted and Defaulted Functions, that aren't essential to most programmers, and mostly just clutter the language, because only like, 1% will use them, and the rest will be like "what the hell is this" when looking at that 1%'s code.
    - sseagull 11y ago
      I disagree. I'm a scientific programmer working mainly in C++ and Python. Deleted and defaulted functions help a lot by reducing the amount of code that needs to be written, maintained, and debugged. Rvalue references help by reducing unnecessary copying, which is a huge benefit when working with large data structures. Before, the workaround was classes that wrapped pointers with shallow copy semantics, which turns into an aliasing nightmare. YMMV, depending on your field, of course.
  - Someone 11y ago
    "That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned." I think that graphics would be a great addition to the standard library. However, it will be tremendously difficult to create a good API that is simple to use for simple cases, yet doesn't limit one to the simple cases, and is flexible enough to fit a wide range of devices and OSes with their favorite graphics libraries. Web developers want all browsers to support CSS, canvas and SVG, so that their applications port easily between platforms. Why wouldn't C++ developers get it as easy? First thing to spend a lot of time on would be what one means with 'graphics'. 2D? 3D? Static or also animated? Windowing system included? I would go for 2D, static, no windowing system, certainly in the first version. That already could be very useful. Imagine having a standardized way to query what bitmap graphics formats the OS supports, and to easily read and write them. Also imagine writing a plotting package on top of such a library. Porting it between various OSes would be way simpler than it is now. But as I said: designing this will be very difficult.
makecheck 11y ago
And the proposed version already shows signs of being too limited. With a pixel-centered viewpoint, the results will not be reasonable on Apple Retina displays, for example, or when printed. On the other hand, anything vector-based would also become complicated pretty quickly, especially for platforms that may still have APIs that are natively pixel-based. This is not something that can be standardized easily. Besides, there are parts of even the current standard that are broken enough to demand some replacements and deprecations. For example, "std::string" and "std::iostream" are pretty awkwardly implemented and it would be really nice to have something better.
humanrebar 11y ago
> No, this is extra functionality that should be in a third-party library. I've also wondered why so many random number generators and math libraries are being standardized. Maybe there's a good reason for them to be in the standard, but I haven't heard one yet.

blablabla123 11y ago

Not sure if that's really because of C++ or because they want to add just more out-of-the-box functionality to the standard libary. Java has been very successful with its large standard library. Also we have seen nows so many 2D graphics library code, it should be possible to come up with functionality that will still make sense in 20 or 30 years.

kamac 11y ago

> You shouldn't be clamoring for inclusion in the C++ standard, you should be calling for better third-party library support in your tooling! This. Honestly after C++11 the stuff they're adding is scarcely useful, it mostly just complicates the language itself even more than it currently is. They're trying to change the way you write C++ code without removing support for the old ways. I feel like they should make a new language instead of adding mostly useless things/stuff that barely anybody will use (could be also because barely anybody will know of that feature's existance)

m3koval 11y ago
Concepts, modules, a file system library, and an asynchronous I/O library have all been discussed as additions for C++17 and beyond. Most of these features are standard in modern languages. I would not consider any of these to be "scarcely useful." As someone who uses C++11 on a daily basis, I very much look forward to using these features without a Boost dependency. That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned.
- kamac 11y ago
  I forgot to add "mostly scarcely useful", instead of "scarcely useful". There are some things that make sense, like file system library and async I/O library that you've mentioned (althrough I don't agree on concepts and modules, but that's up to one's preference), but then comes stuff like constexpr, rvalue reference, Deleted and Defaulted Functions, that aren't essential to most programmers, and mostly just clutter the language, because only like, 1% will use them, and the rest will be like "what the hell is this" when looking at that 1%'s code.
  - sseagull 11y ago
    I disagree. I'm a scientific programmer working mainly in C++ and Python. Deleted and defaulted functions help a lot by reducing the amount of code that needs to be written, maintained, and debugged. Rvalue references help by reducing unnecessary copying, which is a huge benefit when working with large data structures. Before, the workaround was classes that wrapped pointers with shallow copy semantics, which turns into an aliasing nightmare. YMMV, depending on your field, of course.
- Someone 11y ago
  "That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned." I think that graphics would be a great addition to the standard library. However, it will be tremendously difficult to create a good API that is simple to use for simple cases, yet doesn't limit one to the simple cases, and is flexible enough to fit a wide range of devices and OSes with their favorite graphics libraries. Web developers want all browsers to support CSS, canvas and SVG, so that their applications port easily between platforms. Why wouldn't C++ developers get it as easy? First thing to spend a lot of time on would be what one means with 'graphics'. 2D? 3D? Static or also animated? Windowing system included? I would go for 2D, static, no windowing system, certainly in the first version. That already could be very useful. Imagine having a standardized way to query what bitmap graphics formats the OS supports, and to easily read and write them. Also imagine writing a plotting package on top of such a library. Porting it between various OSes would be way simpler than it is now. But as I said: designing this will be very difficult.

makecheck 11y ago

And the proposed version already shows signs of being too limited. With a pixel-centered viewpoint, the results will not be reasonable on Apple Retina displays, for example, or when printed. On the other hand, anything vector-based would also become complicated pretty quickly, especially for platforms that may still have APIs that are natively pixel-based. This is not something that can be standardized easily. Besides, there are parts of even the current standard that are broken enough to demand some replacements and deprecations. For example, "std::string" and "std::iostream" are pretty awkwardly implemented and it would be really nice to have something better.

humanrebar 11y ago

> No, this is extra functionality that should be in a third-party library. I've also wondered why so many random number generators and math libraries are being standardized. Maybe there's a good reason for them to be in the standard, but I haven't heard one yet.