Cairo 2D Graphics May Become Part of ISO C++ 430
An anonymous reader sends this news from Phoronix:
"The C++ standards committee is looking at adopting a Cairo C++ interface as part of a future revision to the ISO C++ standard to provide 2D drawing. Herb Sutter, the chair of the ISO C++ standards committee, sent out a message to the Cairo developers this week about their pursuit to potentially standardize a basic 2D drawing library for ISO C++. The committee right now is looking at using a C++-ified version of Cairo. Sutter wrote, 'we are currently investigating the direction of proposing a mechanically C++-ified version of Cairo. Specifically, "mechanically C++-ified" means taking Cairo as-is and transforming it with a one-page list of mechanical changes such as turning _create functions into constructors, (mystruct*, int length) function parameters to vector<struct>& parameters, that sort of thing — the design and abstractions and functions are unchanged.'"
meh (Score:3, Informative)
i sincerely hope cairo itself remains 1. pure c and 2. as a project, entirely unconstrained by complaince to whatever 'standard' these c++/microsofty goons want. if they want to take a snapshot of cairo's api as a model for some c++ api, fine, whatever, couldn't even stop 'em if we tried. though the effort would be better spent finding more active maintainers for cairomm.
but cairo underlies current versions of major linux gui toolkits. i can't help but view this as some sort of convoluted gambit on microsoft's part to infest it with bureaucracy and c++ architecture astronautism and eventually seize control of the direction or just kill it.
Re:huh? (Score:5, Informative)
This is redundant. High level concepts like drawing graphics are always going to be system dependent, and today's operating systems come with them already. I don't see why having this as part of the C++ base library benefits..
Blitting to the screen may be OS-dependent, but rendering to a canvas need not be.
Re:huh? (Score:1, Informative)
Rasterization is hardly system dependent.
There's a variety of well defined mathematical algorithms for coordinate space transformation, intersection, and ultimately rasterization of polygonal and parametric/polynomial shapes.
No one is saying this graphics library is going to draw to the screen, in fact based on the discussions and proposals - it'd raster directly into memory (and it's up to the user to implement system dependent methods to take it from memory and display it on the screen, if that's even what the user wants).
Java, C#, and JavaScript all have graphics libs (Score:2, Informative)
Re:As usual, fuck the implementation. (Score:4, Informative)
Okay you don't like C++, that much is clear but...
Hey let's get a standardized vector and 2D drawing library going! Fuck the hardware or implementation details which indicate you'd be better off not limiting the dimensions to 2. Never mind the fact that we'll be filling triangles on a GPU for any sort of efficiency at all. Nope. Fuck starting at the actual primitives present and working up from there, let's do the top-down approach yet again -- When the performance conscious folks include messed up limitations, like the Diamond Inheritance pattern (Which has no reason to exist, variable placement should be virtual too, dimwits).
Cairo is not limited to outputing raster graphics. It also supports vector formats such as PostScript, PDF and SVG. You may be doing the work on the GPU, or the GPU may have nothing to do with it at all. Even for raster graphics, it is not guarnateed that a GPU is even present or the fastest option. Seperation of vector 2D graphics and 3D graphics output is a long established tradition and hardly a design descision of the C++ standards commitee.. They are after all only looking to standardise on an existing C library in widespread use.
Yeah, I'll stick with C. At least it doesn't pretend to do anything but present the Von Neumann architectural constructs to me and let me build my OOP, etc atop them. It's still not optimal because it has the moronic assumption that functions should be on the stack and not the heap -- thus hindering or outright preventing closures, co-routines, and arbitrarily limiting recursion despite the system's available RAM -- but it's miles beyond C++ in terms of idealic design splattering all over the hard brick wall of reality's implementations. I mean really, if you can't use method overloading properly with templates and polymorphism then the language is broken by design, and there are no complete implementations.
C++ sure has its warts and I am definitely keeping my eye on Rust and D but what exactly would you consider a good way of handling method overloading + templates + polymorphism, and as a C fan why do you want to introduce such complexity to your code? KISS works well in C++ as well. On a side note C++ does handle the combination of features (http://stackoverflow.com/questions/4525984/overloading-c-template-class-method), albeit it is hardly pretty
Hey! I got an idea. You know what would be nice in C++? How about a standardized ANSI terminal interface, like VT100 -- Get ncurses into the spec. Oh! And you know what else? How about RMI! Yeah! Oh oh oh!! I got one I got one! INTER-fucking-FACES for IPC! Yeah! So you could query a program's interface and pass data between processes transparently in a language independent way -- and the doc comments could be lexical tokens too, so that if the .dat file was present even a terminal mode program could query a program's usage without needing a manually constructed manpage, and other programs could implement the same interfaces allowing us to assemble programs from sets of features. You know, something smarter than STDIN and STDOUT and a char**? Something actually fucking useful for a damn change?
If you want IPC abstractions use Boost (http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess.html). Maybe one day these abstractions will be added to the standard library as well. You could also look at platform specific IPC solutions such as COM, which seems fairly close to what you describe. However, until there is a commonly accepted base set of features which can be supported on all major platforms, looking to the C++ standards committe to provide guidance seems very odd to me.
Re:But... why? (Score:3, Informative)
Last I checked Qt is "free" for open source projects but requires an expensive commercial license for anything else.
wxWidgets on the other hand is licensed under much more liberal terms and not owned by a commercial enterprise looking to make a buck or subject developers to strange licensing schemes.
Re:But... why? (Score:1, Informative)
Wrong. Qt went LGPL years ago, it's properly free for any kind of software.
Re:But... why? (Score:5, Informative)
Unless things have changed I never paid Qt any attention because it is dually licensed and therefore not truly free software and its ownership keeps changing between commercial companies.
Last I checked Qt is "free" for open source projects but requires an expensive commercial license for anything else.
You last checked about a decade ago, then.
Here's how it works now (and has worked for a while now): Qt is Free. Not "free", but Free. It's under the LGPL. And the GPL.
"But it's owned by a commercial company, and they can just close off the source."
Nope. Still stays open. Back a few years ago, the KDE group got a special concession from Nokia. They set up the KDE Free Qt Foundation [kde.org]; if the commercial owners of Qt (Digia) stop releasing Qt under the LGPL and GPL3, KDE has the right to make the whole thing BSD. Irrevocably. And the agreement stays, even if Digia is sold, bought, etc. Read the link if you'd like to know more.
Basically, Qt is Free. If the owners ever stop releasing it for Free, KDE gets to release it under an even more Free license.
Qt has been Free for a while. Qt is still Free. It will remain Free