C++ ISO Standard Committee 2D Graphics Library Discussions

[FRex]

the implementor can do whatever he wants as long as it exposes the same interface as the standard.

ie. instead of using UTF-8 like everyone else, implement the api in wchar_t(which has pretty much random size depending on the current platform) so you can't portably work with unicode command line params, console i/o and filenames. Well done.
Maybe I'm needy but I wish Microsoft(= this 'Microsft c++ centric group' that now 'works' on silly things like std lib 2D apparently) would first focus on bug-free c++11 and treating char as  UTF-8 by default.

[Nexus]

FRex, can you please stop with this silly Microsoft bashing? Hijacking the thread topic repeatedly starts to get annoying.

[FRex]

This is not 'silly bashing' and the fact that Microsoft did poorly in that respect is part of the 'discussion' here.
They failed to implement last standard so far(I actually moved to GCC feature was just missing from 2010 and 2012), they charge money for broken software(unless non c++11 compliant compiler is not broken in 2012/13 in your opinion) and now this stupid idea that can have like billion controversies, choices and pitfalls? We don't even have something as basic as a filesystem yet(yeah, boost might get into standard) and microsoft doesn't allow for code that works with UTF-8 everywhere else to work on their platform.

It's not like GNU c++ centric group said they gonna do that and then we started 'bashing' microsoft for fun for no reason, it's their c++ group's idea, if they were top c++11 implementer I'd be overjoyed with the idea, but now they are just daydreaming about some distant future instead of implementing standard that actually got ratified. And GNU and Apple compiler people actually did (most of) their job correctly so they can be daydreaming about weird and controversial features, not 'c++ experts' from Microsoft(who also dropped support for another 2D API they had recently, has quite a lot non portable things, including C# and Visual Studio and cashes in BIG on their own graphics API that rivals OpenGL in everything except portability which results in most games not being cross platform at all, even though they are in c++, and so: the idea of really cross platform and easy standardized 2D just doesn't stick to Microsoft employees, unless they are acting against the interests of their employer, imagine Kronos Group employees proposing that idea instead, now that'd stick together WAY better in the grand scheme of things, wouldn't it?).

How is the part for loading image from file even gonna look in that imaginary super idealized API? Will everyone (including standard) just make it take const char * which is UTF-8 by default and Microsoft will provide another non standard wchar_t overload that is not compatible with anything else?

And this is not hijacking thread, I'd say you hijack most threads in the entire forum that have code using manual memory management and then get into discussions about RAII(I'm not saying it's wrong or false) instead of what the original thread was about.

In case you can't read my opinion about this '2D API' between the lines of 'silly bashing':

Bad idea, tons of problems(slow software or introduce inconsistencies between platforms DX and GL and implementations of GL) and Microsoft will likely lag behind and butcher the implementation or introduce inconsistencies with rest of the world.
It's good as it is now, I want basic features(like filesystem) in standard and cross platformly implemented first.

[eXpl0it3r]

This is not 'silly bashing' and the fact that Microsoft did poorly in that respect is part of the 'discussion' here.

It was, but the OP brought it back to the topic and you're trying to hijack the thread for your "favorite" topic again.

That being said, this is not about Microsoft, focusing on the point of the library/disussion would be saner than bashing one implementor.

[Silvah]

instead of using UTF-8 like everyone else, implement the api in wchar_t

Sure, hindsight is 20/20. UTF-8 did not exist back when NT development started. And while they could've added either UTF-8-aware locales or a third set of structures and functions later, they decided not to, because the former is very likely to break old programs (remember, it's Windows we're talking about, backwards compatibility matters), and the latter makes maintenance an even bigger nightmare than it already is. Since converting between UTF-8 and UTF-16 is not rocket science, they decided to put the onus upon third-party programmers to convert the strings, which is probably the least of the evils.

Yes, the current situation sucks. But changing it requires a TARDIS.


Regarding the proposal itself, I think it won't fly. There are just too much possible discrepancies between various implementations for a conservative standardized API to be usable in the real world. Staying with third-party libraries is IMO the best solution.

[SuperV1234]

Watching GoingNative: excited to see SFML devs may work with the standard committee

[Klaim]

Indeed, I hope SFML inspire the interface of the graphics/io library to be composable instead of a being a framework in which you inject user code. With a composable library, such a framework is easily constructible.

[Hiura]

Yup, Herb Sutter's talk «One C++» at GN13 was really cool. I hope std:: 2d API sees the light soon!

BTW, 18 LOC to draw «Hello» like he did with Cinder is also possible with SFML. :-D

[binary1248]

BTW, 18 LOC to draw «Hello» like he did with Cinder is also possible with SFML. :-D

#include <SFML/Graphics.hpp>
int main() {
        sf::RenderWindow window{ sf::VideoMode{ 400, 400 }, "", sf::Style::Close };
        sf::VertexArray vertices;
        while( window.isOpen() ) {
                sf::Event event;
                while( window.pollEvent( event ) ) {
                        if( event.type == sf::Event::Closed ) {
                                window.close();
                        } else if( event.type == sf::Event::MouseMoved ) {
                                vertices.append( sf::Vertex{ sf::Vector2f( event.mouseMove.x, event.mouseMove.y ), { 255, 127, 63 } } );
                        }
                }
                window.clear();
                window.draw( vertices );
                window.display();
        }
}

I count 14 .

As for the keynote, I can't help but find Sutter's speeches... all kinds of things. On the one side, you have the fact that he does acknowledge the fact that the C++ standards committee has been more than not conservative and cautious when it comes to exploring new areas. This is contrasted with the current developments regarding language and library evolution, which is being done at a much faster pace than ever before. I also can't help but notice his enthusiasm when talking about the things he finds worth mentioning and why he seems to consider C++ the language for everything, while at the same time remembering at the back of my head that he is employed by Microsoft, the only big compiler vendor that still doesn't have a release version that supports the newest standard. His advocacy for standard C++ also contrasts the fact that he is linked to many non-standard C++ topics and areas including CLI, CX and AMP. Maybe this is a good thing since C++ is trying to extend its library to be more comparable to other more "complete" languages.

If I had to describe Mr. Sutter in a few words, I guess I would call him a "C++ salesman" or "C++ marketing representative" which probably fits well to his position as convener of the standards committee. He is good at selling us these ideas, but the real issues behind them are the work of others on which we will depend to see e.g. the 2D API one day. I can only hope these "invisible people" in those workgroups are independent enough to not incite internal "vendor wars" which might delay or even prevent good things from happening. As he noted, we really don't know how people program in C++, let alone using libraries to get whatever they need done. The same can be said about SFML. We don't have any reliable metrics about its real userbase and the majority of the code written with it might be "dark matter" that we will probably never see. This is why I think standardising a 2D C++ API is going to take longer than what many people might expect. There are so many different ways it can be done, finding a common ground, and one that is true to the "C++ way" is going to go through many iterations until it is written down permanently. I guess they are in the pre-case study phase right now where they collect impressions from existing libraries and see what the general public is used to since one can assume that libraries generally cater to the needs of most users and show some convergence.

One thing that made me wonder: When all those workgroups are done with their work and C++'s library is expanded to what Mr. Sutter said they envisioned, and the platform independence problem is practically solved and the undefined behaviour (which I found surprising they even considered making a workgroup for) is... defined? () What advantages will a language such as Java have over C++ any more? Beginners and experienced programmers always argued in favour of Java because of all those things that C++ currently lacks but is being worked on, so once all those things are in C++ as well, why would anybody even consider Java any more? To top it off, if both languages were truly equal in all aspects, one must not forget that C++ is an ISO standard, whereas Sun decided to keep Java more or less to itself. If Java advocates watched the video, I would expect them to start to asking themselves how things will stand in several years.

[Susana Weigman]

Microsoft is pushing this library, so it may appear faster than having full Ç + +14 execute them. Now, it is true, Microsoft tools, most use Ç + + world, most lacking is a big problem, but at this point, I think they are as much effort as they can be repaired game.Support for C ++！

[Klaim]

binary1248, you're both missing all points and being totally unhelpful here.

To get back on the topic, on the forum open to people interested to help on the graphics library, I already posted a SFML version of the Cinder example, liike two weeks ago.
I think maybe some here didn't understand that if you want to help, you can. It's not a closed system anymore (even if some parts are closed).

[binary1248]

binary1248, you're both missing all points and being totally unhelpful here.

I'm just curious... what points did I miss? I couldn't discern from your original post what would qualify as "helpful" and what would qualify as "unhelpful" considering it consisted of 2 simple statements with links to other pages. Deeming my only post until now as unhelpful without explaining why, on the other hand, is not constructive in helping me correct my errors. Judging by all the previous posts which must have been helpful since you did not comment on them, I would be required to simply express some form of enthusiasm related to the matter without going into deeper thought.

I'm not one who likes to escalate discussions into a mindless flame war. If my opinion on the matter (which I posted in good faith) is not welcome here, so be it. I wish this discussion good luck. Call me when you require my services once more.

[Klaim]

Sorry, I didn't have time to get into details. Sot summup, what you think about Mr. Sutter is besides the point because the C++ standard is an ISO standard which means it's voted by countries, not companies. Companies can push for features but if not a majority agree, it don't get into the standard. That Mr Sutter is from Microsoft doesn't mean the proposed library (which have no proposal at the moment so it's not even a proposed library) will or will not get voted in. However, if an implementation is provided, it have great chances of be evaluated as fast as possible.
The rant about Mr Sutters presentation is besides the point of the thread which is about participating into designing a library to do, basically, what SFML, Cinder, OpenFrameworks and other libraries I forget do. It's not about Microsoft, it's not about Sutter, it's about the standard.
For the first time in C++'s history, people who didn't pay to get "official" can contribute to the standard. We have an opportunity to provide input so I'm saying let's focus on that input instead of discussing who sells what, other than language and library features.

That hopefully clarified, I didn't meant to be offensive but I'm getting tired of rants about an aspect of the issue at hand (designing a library) that can easily drive disucssions unhelpful, like both mine and your posts.

The first part about the code is the interesting part in your post. I am officially giving you my most sincere excuses and hope you will contribute again.

Just to get back to one of your questions:

When all those workgroups are done with their work and C++'s library is expanded to what Mr. Sutter said they envisioned, and the platform independence problem is practically solved and the undefined behaviour (which I found surprising they even considered making a workgroup for) is... defined? () What advantages will a language such as Java have over C++ any more? Beginners and experienced programmers always argued in favour of Java because of all those things that C++ currently lacks but is being worked on, so once all those things are in C++ as well, why would anybody even consider Java any more?

Java and other languages still have benefits in specific domains. For example, setting up Java server nodes automatically is incredibly easy. Not having to "think" about the end of life of objects can help quickly getting to the point (before maybe an optimization by converting to C++). C++ will not have a big library as Java does, not before at least 10 years at the speed we're adding libraries. C++ lacks a lot of reflection features (and apparently work in reflection group can't go fast because they need to have C++14 out first to know what they can or cannot consider) which means it's still problematic to use in a lot of cases like server applications.

Basically, there is room for other languages. Also C++ stumped under Rust or D invasion, if they manage to fix some major problems compared to C++.
Also, C++ isn't "pure", which is both an advantage and a problem depending on the specific context.

So basically, it's not important. What's important is that at the moment, using C++ for prototyping is not efficient enough because it takes too much time. In the same time, it's still certainly the best language for infrastructure.

Does someone around read a bit the first example of potential proposal that have been posted? https://bitbucket.org/brechtkets/graphicscpp So far I'm not satisfied at all but I think it just need some clearer design guidelines.

[Hiura]

C++ will not have a big library as Java does

My main fear about the current acceleration of the development of C++ standard is that, in a "few" years we have a good core language but a huge s(t)l with a lot of deprecated features – that's how I see Java: a relatively good language with a crippling library... I hope this fear is unfounded.

Does someone around read a bit the first example of potential proposal that have been posted? https://bitbucket.org/brechtkets/graphicscpp So far I'm not satisfied at all but I think it just need some clearer design guidelines.

Yup, the current design is really clumsy, I think. But it's just a draft and Micheal said comments are welcome so there is still hope. 

But it's clear that the design task won't be easy: how do you create a nice abstract API for completely different backend (OGL/DX/...)? Also the specific goals of the API is not yet clearly identify.

[Klaim]

C++ will not have a big library as Java does

My main fear about the current acceleration of the development of C++ standard is that, in a "few" years we have a good core language but a huge s(t)l with a lot of deprecated features – that's how I see Java: a relatively good language with a crippling library... I hope this fear is unfounded.

[/quote]
They are aware of the potential problem but I'm not sure if they are looking for a solution to easily change versions in the future or if they just want to rely on genericity.

But it's clear that the design task won't be easy: how do you create a nice abstract API for completely different backend (OGL/DX/...)? Also the specific goals of the API is not yet clearly identify.

The goal is not to provide low level graphic api, but high level. It's not to provide OGL/DX kind of API, but SFML/Cinder/OpenFrameworks kind of API.
So it's not a problem what the backend is. The problem is mainly to decide what features are both generic and useful to draw things on the screen.