Introducing C++ experimental io2d (2D Graphics in the C++ standard library) | Hacker News Reader

Introducing C++ experimental io2d (2D Graphics in the C++ standard library)

cristianadam.eu

22 pointsingve22 comments

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!

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.

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

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.

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.

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.

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

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.

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

The death of c++ in many universities could be blamed a little on the hurdles you have to jump to create something windowed and interactive (what many would consider a "program"). I saw that happen at my university between 2000-2010, and in the computer graphics department we just ended up using Processing to teach most concepts.

It's in c++'s best interest to have some components whose purpose is to make things easier, especially for newcomers. io2d fills a huge gap there, one that hasn't been filled by any compilers/IDEs in a cross-platform and straightforward way. However, I agree that better c++ package management would have solved this problem, and also eliminated the need for <filesystem> etc.

I'm not happy with the specifics of the io2d proposal (50+ colour constants?) but it's a start.

Why are people trying to turn C++ into python, complete with it's legacy useless cross platform UI library (ktinker).

We know from experience that this is a bad idea, and a waste of everyones time.

Build your application layer logic onto of a robust module ecosystem, don't try to bake it into the standard library.

...but even if you were to say, want to do this, this is a horrible legacy api before it even exists!

Hard coded color constants? (antique_white? alice_blue? Are you kidding me?)

Font support, including (presumably) true type font parsing?

Brushes and gradients?

No mention in the whole document are programmable graphics pipeline? (ie. shaders)

No mention of device independent output scaling?

Maybe we can just fork inkscape and put it into the standard library?

I know this sounds harsh, but have the authors of this proposal actually built anything using a 2D graphics api recently?

This is a high level 2D vector graphics day dream.

Give us more standard datastructures, instead. The answer to everything in C++ involves a boost library right now; focus on fixing that. This looks like an awesome library, but completely unnecessary as a core part of the language. Also Cairo is marred in LGPL. Are we going to get a standard that legally requires the use of a separate, dynamically loadable binary? The actual spec for this is just an ABI for their specific implementation.

Coming into C++ for the first time from QBasic, 16-year-old me would have loved some batteries-included graphics. Instead I had to learn SDL to get something going, combined with trying to use the (aptly named) Bloodshed Dev-C++, which was an unbelievable cluster.

Nowadays, I would never suggest somebody at the level I was at then to pick up C++. It's a different world now than it was then.

I found it always weird that so many languages have a complete lack of graphics support. Even TTYs aren't fully supported.

But I guess if C++ realizes that, other languages may follow.

I assume you mean "so many language standard libraries..."; putting graphics in a language (e.g., having the compiler worry about RGBA and suchlike) would not be a great choice.

Doing cross-platform graphics well is hard. And the landscape changes pretty rapidly. Take a look at PHIGS, for instance. It's a standard . . . and it really sucks.

There's a bunch of common ground at the math level (matrix transforms, quaternions, etc.) and probably some data structures, but actually doing rendering? Whatever you cook up is likely to be a quaint, procrustean bed within five years.

No doubt that it's hard but just imagine how useful this would be.

Setting up a Linux desktop system is notoriously hard, at least if you are not a "computer expert". Configuring hardware that is considered mainstream among Linux professionals most of the times works out of the box. For other hardware too often CLI tools are needed. I would think that these tools often have no graphical interface because there is no standard way to program GUIs in UNIX C.

However, HTML5 seems to become the defacto cross-platform graphics standard that seems to takeover many GUI app writing tasks. It's also a good example of a standard that is actually low performance often using outdated methods. WebGL is OpenGL ES 2, DOM is so slow that people wrote React, CSS is actually designed for documents...

Given how many platforms don't have monitors to show graphics on, any language that supports graphics would have abandon those platforms or end up dividing into a kind of core language, and then add-on third-party libraries to support things on specific platforms... which is what we have now.

While I see the value in having a robust standard library, is it really that hard to apt-get or brew install Cairo or some other 2D drawing library?

In that domain the SFML API is very clean:

http://www.sfml-dev.org/documentation/2.3.2/annotated.php

But I still stick to SDL for rendering mostly because it works everywhere (especially in JS with emscripten).

About pixel manipulation and image processing, VTK (from the companing doing cmake) is my favorite choice:

https://github.com/Kitware/VTK

I think C++ won't have an standart 2D API before reflection :-)

There are so many 2D libraries out there that we should know what basic form that take by now.

https://xkcd.com/927/

about time. the lack of any graphics in standard libraries going back to the crusty old days of qbasic etc. has always been a frustration.

/me hopes for image loading/saving unlike this post suggests, since most libraries are utter garbage for this

Reply on news.ycombinator.com