Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Graphics Technology

Cairo 2D Graphics May Become Part of ISO C++ 430

Posted by Soulskill from the more-than-just-a-city-in-egypt dept.
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.'"
This discussion has been archived. No new comments can be posted.

Cairo 2D Graphics May Become Part of ISO C++ More

Cairo 2D Graphics May Become Part of ISO C++

Comments Filter:

  • Sure, why not (Score:5, Funny)

    by DoofusOfDeath ( 636671 ) on Saturday January 04, 2014 @08:15PM (#45867959)

    C++ stopped being a fully-humanly comprehensible language a long time ago. Might as well just add more crap to it like it's going out of style.

    • You got +5 Funny, I don't know why, this comment is damn insightful.

    • Why can't they just eliminate header files first?
      Why is C/C++ practically the only language that requires headers?
      Why do I need to type each function declaration twice. It is so cumbersome!

      • Re: (Score:3, Insightful)

        by rubycodez ( 864176 )

        don't have to, you could mark everything inline and define in the header without typing each function declaration twice.

        not recommended for general practice 8D

      • Re: (Score:3, Interesting)

        by beelsebob ( 529313 )

        To be honest, I love headers, and I'd love to see more languages use them. Not as a necessity to allow the compiler to see what's declared, but instead, as enforced documentation of what's a public API.

        • Re: (Score:2)

          by radish ( 98371 )

          I find the keywords "public" and "private" work very well for that, no need for a separate file :)

          • The problem is that large proportions of the populace of programmers are idiots, and if you show them the private things, they will rely on them.

            One simple file that says "this is the public interface, and it's documentation" is an extremely useful tool.

            • As much as I'm a fan of C/C++, I expect the headers could be generated at compile time for distribution with libraries or for compiling against - I see no reason for the developer to maintain the header file. That way you can still hide your implementation etc and not have the burden of flicking between headers & source etc.

        • Except that in most cases, headers dont declare just the public API, but bring in a ton of implementation details. Unless you are using PIMPL or bridge design a lot.

          Both come with their own downsides. Or unless you are using .. fast PIMPL without the allocation overhead, but then did C++11 give you out of the box template for implementing fast PIMPL ? Of course not.

          It will give you a pretty dumb version of a 2D rasterization library with outdated narrow usage drawing primitives, which i am going to run on w

          • Oh, also finally coming up with an ABI standard for the thing would be a big help, thank you !

          • In C++, certainly, headers tend to contain way more than it would be nice for them to. That's one of the reasons I don't like C++ much.

        • In my opinion, this is one of the things that Modula-2 got right: a Definition Module for the API, and an Implementation Module for the code. PIMPL just ain't the same.

      • Why can't they just eliminate header files first?
        Why is C/C++ practically the only language that requires headers?

        Because templates.

        But they're working on it - it's called the "modules" proposal. It has been floating around since C++0x days. It won't get into C++14, but it probably will in C++17 - and, given how things are going in C++ standardization land, it'll likely be implemented in gcc and maybe even VC before the final standard is published.

      • Re: (Score:2)

        by Greyfox ( 87712 )
        Headers define the interface and are documentation to other programmers. If you don't care who sees your code, you could just put everything in classes and put all your code inside those classes, just like a Java class. It'll slow down your compilation, but if you break down your code into libraries and unit test all your libraries, you shouldn't have to compile the main project all that often. Most of your maintenance churn can go on in the libraries and once you're sure all those are solid you can roll th

      • Re: (Score:2)

        by anatoli ( 74215 )

        C/C++ is undefined behavior. Don't do that, kids!

        • Re: (Score:2)

          by satuon ( 1822492 )

          I've been programming only in C++, and to tell you the truth, I seldom have crashes, and when I do, 99% of the time they're easy to fix. Most bugs I get are not crashes, just bugs in the business logic, and they would still happen in Java.

          I must admit that I'm kind of envious of how you get a nice stack trace when you have a crash in Java (an unhandled exception).

      • Re: (Score:2)

        by AuMatar ( 183847 )

        I'd rather add headers to all other languages. Most of the time, when I look at a class I want the hilights- the functionality it exports, maybe the major variables it uses. Its damn difficult to tell those at a glance in Java, C#, etc- you need to scroll past hundreds or thousands of lines of code. Headers are absolutely perfect for this. Javadoc was pretty much created to work around the lack of headers in Java.

    • Re:Sure, why not (Score:5, Funny)

      by Gravis Zero ( 934156 ) on Sunday January 05, 2014 @02:11AM (#45869119)

      C++ stopped being a fully-humanly comprehensible language a long time ago.

      That's a lie! BEEP. BOOP. I'm a fully humanly and I can comprehensible language just fine a long time ago. BEEP. BEEP.

    • You don't need to use the aspects you find incomprehensible and those aspects don't negate the value of the bits you can comprehend.

  • That's unfortunate (Score:3, Interesting)

    by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Saturday January 04, 2014 @08:26PM (#45867995) Homepage
    Cairo is a great library, I've used it and found it very easy, but it's not remotely approaching a standards-quality design. The closest I've seen would be Anti-Grain Geometry [antigrain.com], which makes phenomenal use of templates.

    • Re:That's unfortunate (Score:5, Funny)

      by Dahamma ( 304068 ) on Saturday January 04, 2014 @08:42PM (#45868081)

      Cairo is a great library, I've used it and found it very easy, but it's not remotely approaching a standards-quality design.

      Yeah, to make it C++ standards-quality they'll need to make it much less intuitive, add tons of templates to make it unreadable, and change the method names to something that makes much less sense...

      • Re: (Score:3)

        by ameline ( 771895 )

        Why are all the insightful posts in this thread being modded "funny"?

        C++ is *way* too big a language already. It's got the PL/1 problem (yeah, get off my lawn) -- when everyone only understands 0.8 of your language (or some amount under 1.0) it winds up being a different 0.8 for everyone. And this means that virtually any programmer will write code that is unreadable to another. (and if there is one thing that over 25 years of programming has taught me is that code readability trumps almost everything else)

    • Re: (Score:3)

      by Cyberax ( 705495 )
      Unfortunately, Anti-Grain's author had died recently so it's unlikely Antigrain is going to be developed fast enough to be standardized.

    • Re: (Score:3, Interesting)

      by mraeormg ( 3480869 )
      While AGG is one of the most cleanest and high quality 2D rendering APIs, it's improbable that AGG will be accepted by the c++ committee, Herb Sutter works for microsoft, and AGG's author is very critical of many graphical features of windows, like the sub par font rendering. An example of this is the the dialog window for enabling high dpi font scaling.
      http://i1.wp.com/www.istartedsomething.com/wp-content/uploads/2006/12/dpi480_3_l.jpg [wp.com]

  • meh (Score:3, Informative)

    by Anonymous Coward on Saturday January 04, 2014 @08:32PM (#45868021)

    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.

  • But... why? (Score:3)

    by zander ( 2684 ) on Saturday January 04, 2014 @08:37PM (#45868057)

    One of the hallmark problems of design-by-committee is that they extend languages for the sake of doing fun things, not because people need it.

    While everyone needs containers (like vector/hashmap), nobody needs a simple graphics library. There is practically no hardware out there that doesn't have some sort of hardware accelerated graphics and simple operations just make no sense there.

    So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.

    • The main reason is because it's portable. Java has one too.

    • Re:But... why? (Score:5, Insightful)

      by Anonymous Coward on Saturday January 04, 2014 @09:41PM (#45868333)

      So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.

      Firstly, I take issue with your premise that Cairo is no more than a toy and useless in actual work.

      Secondly, One very important usecase for a simple drawing library in the standard is to provide an easy route for novices to write cool, interactive and meaningful programs, without needing to write several hundred lines of scaffolding code and be well-versed in 6 different layers of abstraction from OSes to frameworks and graphics API.

      I don't know how other people learned programming, but in my case, the most engaging things I wrote all those years back in BASIC and Pascal (under DOS) were graphical programs in nature (extremely simple games, GUI-like apps that didn't really need the GUI, function plotting and other graphical toys, etc.) I'm guessing that I'm not unique in the fact that having access to simple, straightforward, inefficient, well-documented, built-in 2D graphics API led me to all sorts of cool experiences in programming and (majorly) determined my pursuit for the rest of the two decades since.

      Now, it is obvious that there will always be more novice programmers than experienced ones, so, I don't see the problem with the ISO C++ committee to explore standardizing such a library. Do you, really? Who is this going to hurt?! For most of us, this is pretty much out of our way, since we either write more serious graphical applications and need platform-specific, performance-oriented APIs that offer much more control and features, or we haven't written anything that needed a 2D immediate-mode graphics API in years. So, I ask the Slashdot readership again, what's wrong with standardizing a simple, straightforward 2D drawing API to help the novices and the occasional non-performance-sensitive drawing needs of the community?

      • BASIC and Pascal of the DOS era wrote to the very standardized and well documented VGA buffer. We don't have that luxury anymore.

    • Re:But... why? (Score:5, Interesting)

      by mytec ( 686565 ) on Saturday January 04, 2014 @10:27PM (#45868497) Journal

      So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.

      There was a keynote done by Herb Sutter this past September and at roughly the 57 minute mark of his presentation Keynote: Herb Sutter - One C++ [msdn.com] he shows a 15 LOC example of numbers being input and then output sorted. He then said, "We need to get past the VT100 era." He continued saying that the standard C++ program cannot even exercise the abilities of the VT100 which has underscore and bold, etc. Pure, portable C++ code cannot even drive a 1970s era VT100.

      If you continue watching you'll see the point Herb is trying to make and that point may help explain why they are looking to do this.

      • Re: (Score:3, Interesting)

        by serviscope_minor ( 664417 )

        "We need to get past the VT100 era." He continued saying that the standard C++ program cannot even exercise the abilities of the VT100 which has underscore and bold, etc. Pure, portable C++ code cannot even drive a 1970s era VT100.

        Not sure I get that, or, Herb is less knowledgable about VT100s than he is about C++. This will work in a VT100 compatible terminal, like just about any common terminal program:

        std::cout << "\e[1mBold \e[0m\e[4munderline\e[0m\e[5m blink \e[0m\e[7minverse\e[0m text\n";

        Works o

  • As usual, fuck the implementation. (Score:3, Interesting)

    by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Saturday January 04, 2014 @09:01PM (#45868163)

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

    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.

    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?

    • One can implement coroutines in C [greenend.org.uk].

    • Re:As usual, fuck the implementation. (Score:4, Informative)

      by Jeeeb ( 1141117 ) on Saturday January 04, 2014 @10:43PM (#45868543)

      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: (Score:2)

      by fisted ( 2295862 )

      C [...] has the moronic assumption that functions should be on the stack and not the heap

      Dear Mr. experienced C programmer,
      There is no such assumption in C.

  • Obviously this is early stages, and I am not outright opposed to the concept of having a standard vector graphics library. The creation of formatted documents (pdf) and images is a low level and common task. The productivity of many programmers could be increased by having a standard library which can be easily linked against.

    However I do feel like this opens up a can of worms. Will they also include a FreeType interface to support text output? What backends will be included by default?

    A vector graphics lib

    • Create a standard interface and leave the actual implementation to be platform dependent. In this case rendering results will differ depending on platform.

      C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.

      • Re: (Score:2)

        by Jeeeb ( 1141117 )

        C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.

        Right. Except that is complexity exposed to the programmer and easily dealt with via int32_t, uint32_t .etc. This is inconsistency exposed to the user.

        • The implementation-defined precision of floating-point types (float, double, and long double) is inconsistency that could end up exposed to the user if the last significant figure is displayed or if a rounding difference causes an if statement to go one way or the other.

        • I think he's referring to signed integer overflow conditions, which don't behave as most people would probably expect and aren't trivial to handle correctly.

Slashdot Top Deals

Pascal is not a high-level language. -- Steven Feiner

Close