
Introducing C++ experimental io2d (2D Graphics in the C++ standard library) - ingve
https://cristianadam.eu/20160228/introducing-c-plus-plus-experimental-io2d/
======
dietrichepp
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!

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

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

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

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

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

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

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

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

------
santaclaus
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?

------
vmorgulis
In that domain the SFML API is very clean:

[http://www.sfml-dev.org/documentation/2.3.2/annotated.php](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](https://github.com/Kitware/VTK)

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

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

~~~
EliRivers
[https://xkcd.com/927/](https://xkcd.com/927/)

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

