4 ms·
In the past the argument against putting things like this in the standard library was always that it is non-portable. C and C++ are meant to run on systems whic
by copx 13y ago
In the past the argument against putting things like this in the standard library was always that it is non-portable. C and C++ are meant to run on systems which do not even have a monitor, much less a GPU (think embedded). The logic was that standard library functions should work on all systems. That is also the reason why the "file system" API of ISO C/C++ is so severely limited. It is designed for the lowest common denominator. There are no functions for handling directories because of the assumption that some platforms do not even have directories. In fact the file system API does not even assume a hard disk but can be implemented by returning handles to RAM.
Now that this principle seems to be abandoned why not go all the way and give us a full GUI toolkit? That would be so much more versatile than just a 2D drawing API.
I do not see much use for this except maybe making ISO C++ tutorials more exciting because your programs can show something else than console output.
And I mean Cairo is not a simple framebuffer, it is quite complex so why not make another step and give us a full GUI?
I read that the C++ guys want a standard library comparable to those of modern languages like Java, C#, Python etc. and they all come with GUI support.
Oh, and before they even think about adding graphics they should beef up the file system API. That is an actual issue. Right now every piece of crossplatform C/C++ includes a wrapper around platform specific APIs just to handle something as basic as getting a list of all files in a directory. They want to give us vector graphics rendering before that?
- pjmlp 13y agoIf you check the working groups there are lots of APIs being worked on, including file system ones. http://isocpp.org/std/the-committee http://isocpp.org/std/the-committee - SG1, Concurrency - SG2, Modules - SG3, File System - SG4, Networking - SG5, Transactional Memory - SG6, Numerics - SG7, Reflection - SG8, Concepts - SG9, Ranges - SG10, Feature Test - SG11, Databases - SG12, Undefined and Unspecified Behavior - SG13, Graphics Any modern language should have a "batteries included" set of libraries, even when targeted for systems programming.
- the_mitsuhiko 13y ago> Any modern language should have a "batteries included" set of libraries, even when targeted for systems programming. I would argue the inverse: modern languages should have a lean standard library but a strong package ecosystem.
- pjmlp 13y agoA standard library is a guarantee that all packages are supported in the target environments for the language. Can you provide the same guarantee with a package system? I don't what to target operating system XYZ only to find out the package does not exist.
- adamnemecek 13y ago>> Oh, and before they even think about adding graphics they should beef up the file system API. It's being worked on. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3335.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333... and I think that it should be part of C++14 or C++17 http://isocpp.org/std/status http://isocpp.org/std/status.
- rat87 13y agoWhy not a full gui? I think I can give a simple reason. Desktop Gui libraries are large and complicated. Assuming you want a full featured cross-platform the choice would probably be qt. But Qt suffers from a lot of api version churn(much faster then c++ standards), includes language extensions(moc) and does a lot of things in a non standard way for c++(including using its own collections and strings). The alternative I can see would be to write a very minimal functionality cross-platfrom gui library or use something other library that might not as cross platform(lacking mobile platforms(recent initial qt support but likely to improve in the future), not as easy to port, not as good looking on some platforms)