×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about 4 months ago | from the more-than-just-a-city-in-egypt dept.

Programming 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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

430 comments

Sure, why not (4, Funny)

DoofusOfDeath (636671) | about 4 months ago | (#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.

Re:Sure, why not (0)

Anonymous Coward | about 4 months ago | (#45867999)

Yeah. What next, adding the MFC interface?

It's one thing to keep up with processor technology like threads as happened with this language [wikipedia.org] but an interface for drawing? How far do you take this?

Re:Sure, why not (1, Insightful)

Anonymous Coward | about 4 months ago | (#45868065)

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.

Competent programmers stopped being formed a good 10-12 years ago. The JAVA/.NET generation is a fucking disaster.

Re:Sure, why not (3, Interesting)

VanGarrett (1269030) | about 4 months ago | (#45868295)

As something of a .NET programmer myself, I can testify to the veracity of this. .NET does a great deal for you, and I really think the handicap has prevented me from learning what's really going on.

Re:Sure, why not (4, Interesting)

dreamchaser (49529) | about 4 months ago | (#45868323)

It's sad but true. My wife works in the CS department at a major University, and I'm appalled at what they are churning out with regards to graduates. I know I'll probably get modded down and see the inevitable jokes about 'get off my lawn' and such, but it's really true. The vast majority of new programmers are more or less clueless aside from pushing out cookie cutter bloated code.

Re:Sure, why not (4, Insightful)

rsilvergun (571051) | about 4 months ago | (#45868513)

News flash, the vast majority of _all_ people are like that. Very few people are capable of being the sort of 'Rockstar' programmer you're pining for. And what's wrong with that? Is it just me, or do we as a society just have unrealistic expectations of people? If you can't work 70 hours a week banging out amazing code non-stop you're worthless as a human being just because somewhere out there is someone who can. We hold up what are essentially freaks of nature that don't need sleep as the norm and wonder why the rat race is getting so awful...

Re:Sure, why not (1)

DoofusOfDeath (636671) | about 4 months ago | (#45868527)

It's sad but true. My wife works in the CS department at a major University, and I'm appalled at what they are churning out with regards to graduates. I know I'll probably get modded down and see the inevitable jokes about 'get off my lawn' and such, but it's really true. The vast majority of new programmers are more or less clueless aside from pushing out cookie cutter bloated code.

I think the real question is whether or not there's a long-term trend here. I wonder how many of us, who now have a great deal more experience, would have said the same thing regarding 1980's college freshmen.

The JAVA/.NET generation is a fucking disaster. (1)

Anonymous Coward | about 4 months ago | (#45868355)

As someone who learnt C then C++ as my first languages, I agree. If there's such a thing as too high level, we're reaching it.
I'm self-taugh but I know how the metal works and made my own toy OS. Then learning other languages was a piece of cake.
Languages like C#, Python,etc are so easy it almost feels like cheating.

Re:Sure, why not (1, Insightful)

celle (906675) | about 4 months ago | (#45868413)

"The JAVA/.NET generation is a fucking disaster."

      Fucking disasters is more like it and all the coupling is creating a whole new generation of mega disasters.

Re:Sure, why not (2)

jcr (53032) | about 4 months ago | (#45868525)

Before the Java/.net generation, there was the VB generation, and if you keep going back you can find more. Good programmers are still being trained, just as there always were. The difference now is just that there are a lot more of the low-skills chaff to sift through.

-jcr

Re:Sure, why not (1)

StripedCow (776465) | about 4 months ago | (#45868099)

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:Sure, why not (2, Insightful)

rubycodez (864176) | about 4 months ago | (#45868169)

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:Sure, why not (0)

Anonymous Coward | about 4 months ago | (#45868335)

In 2005 a language called SystemVerilog was created and the designers specifically copied the header file system from C++.

Re:Sure, why not (0)

Anonymous Coward | about 4 months ago | (#45868385)

Why can't they just eliminate header files first?

Let's say you've got a library compiled *properly*. It check-sums out so you know it's good. You can link against that with headers. IMHO that might be the "killer app" for headers. Can you come up with a better solution? Sure you could put the equivalent of headers in the compiled binary. I don't see that as being a better alternative. Sure you could just ship the source. Aside from the "evil closed source" problem, there's the aforementioned problem of developers throwing the wrong switch when recompiling the library. There are a lot of compiler switch permutations, and that would be too good a way to create strange bugs that are hard to reproduce--the so called "works on my machine" problem. DLL hell might be annoying, but if the DLL checks-sums out at least you know what you've got.

Anyway, I've got an open mind. What's your alternative for a language that has to compile "to the metal". No, "just make it dynamic" cheats, please.

Re:Sure, why not (2, Interesting)

beelsebob (529313) | about 4 months ago | (#45868449)

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:Sure, why not (1)

radish (98371) | about 4 months ago | (#45868613)

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

Re:Sure, why not (2)

beelsebob (529313) | about 4 months ago | (#45868645)

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.

Re:Sure, why not (0)

Anonymous Coward | about 4 months ago | (#45868569)

Because backwards compatibility and inertia.

Re:Sure, why not (1)

Daniel Hoffmann (2902427) | about 4 months ago | (#45868209)

It's is like the classic "80% of the users use only 20% of the features" also know as the Word Syndrome. But since each user uses a different set of features you need to have everything in there. I'm not saying this is necessarily saying this is a bad thing.

Re:Sure, why not (1)

Anonymous Coward | about 4 months ago | (#45868431)

This is a library only addition. Say what you will about the language itself but C++ has a very small standard library. Compare it to something like .Net or Java which is huge. This is one if the big complaints about the language is any real program written in it will have to use a ton of 3rd party libraries. Everyone uses different libraries and it this makes it difficult to combine code together.

This is just a proposal, it might not go anywhere. I wouldn't see 2D graphics as being the first place to expand the libraries but it doesn't sound unreasonable. Having a standard including software libraries isn't unheard of either. Microsoft did this for .Net and ECMA.

huh? (0)

epyT-R (613989) | about 4 months ago | (#45867985)

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

Re:huh? (0)

Anonymous Coward | about 4 months ago | (#45868003)

Benefits what, or whom? Please complete your sentence.

Re:huh? (1)

carld (460344) | about 4 months ago | (#45868011)

We have stdio.h why not stddraw.h ?? It's not like stdin/stdout are not system/hardware independant.

aaa (0)

Anonymous Coward | about 4 months ago | (#45868347)

Some people see the design of the C and C++ libraries, where file IO is standard and everything else is system dependent, and then start defending it as if it were some kind of blessed design that shouldn't be changed.

It's great that they are finally considering adding more capabilities to the standard library. That will greatly help portability.

If you need to program a microcontroller, C++'s standard library is already too big (files, dynamic memory allocation, etc.), but if you want to make an PC app for end-users, it's too small. I don't see why it coulndn't be expanded.

Re:huh? (4, Informative)

JDG1980 (2438906) | about 4 months ago | (#45868047)

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? (1, Informative)

Anonymous Coward | about 4 months ago | (#45868067)

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

Re:huh? (2)

beelsebob (529313) | about 4 months ago | (#45868111)

The problem is, what's efficient, or nice, is not well defined. Should you antialias lines? If so, what type of antialiasing? Is that type of AA efficient on the graphics card in use? If you don't do that, do certain programs break?

These are all questions that have been answered before by java –yes, everything breaks, because everyone needs to implement graphics subtly differently.

Re:huh? (1)

Anonymous Coward | about 4 months ago | (#45868191)

Except for the glitz backend, Cairo has nothing to do with the GPU - it's all implemented on the CPU, same implementation on all architectures, all platforms.

Antialiasing options are defined as flags.

Re:huh? (2)

beelsebob (529313) | about 4 months ago | (#45868461)

"It's implemented on the CPU" is the first gigantic red flag here. The implication of this is that it's so tightly specified that it's impossible to implement efficiently (i.e. on all vendors different GPUs which do subtly different things re how the exact pixel colours come out).

Re:huh? (1)

epyT-R (613989) | about 4 months ago | (#45868121)

Yes, I know, but it seems to me that those kinds of functions don't belong in the base library as the particulars would be design dependent anyway. For example, we have mpfr for floating point math, which is distinctly separate from the rest of the toolchain, and is an optional piece. Maybe the line is arbitrary, but it seems like feature creep to me.

Re:huh? (1)

beelsebob (529313) | about 4 months ago | (#45868107)

It had better be both damn well specified, and super under specified at the same time.

If it's not well enough specified, different OSes will do different things re (for example) antialiasing, where they decide the centre of a pixel is, etc

If it's too well specified, no OS will be able to implement it efficiently.

My suspicion is that it'll end up under-specified, and useless because of it, in the same way as java's drawing libraries are typically an endless source of bugs (common ones being that the developer assumed that no AA would happen, and then breaking on OS X or more recent windows installs, and rendering nasty looking halos around things, because the developer assumed they could just over-draw something and it would disappear).

Re:huh? (2, Insightful)

Behrooz Amoozad (2831361) | about 4 months ago | (#45868349)

Do you develop for windows? I suspect yes, because in linux we've had this library for years and everyone knows it's a freakin' cross-platform library with very good documentation, coding style, naming convensions, specs, ...
Stop ranting already.

Re:huh? (1)

beelsebob (529313) | about 4 months ago | (#45868453)

You seem to be confusing "this works well on linux" with "this is the perfect solution for all platforms, and it works perfectly across all platforms".

Java, C#, and JavaScript all have graphics libs (3, Informative)

jmcbain (1233044) | about 4 months ago | (#45868247)

Java [oracle.com] , C# [microsoft.com] , and JavaScript [w3.org] all have graphics and canvas component libraries. All these libraries render graphics differently on different systems. In the C++ universe, programmers have had to use 3rd-party libs like Qt, so a C++ standard library for graphics is long overdue.

Re:Java, C#, and JavaScript all have graphics libs (0)

Anonymous Coward | about 4 months ago | (#45868485)

JavaScript began as, and still is mostly, a web browser programming language, so clearly it needs to support 2D graphics.

Java also was originally targeted for desktop applications and browser applets. In addition, Java's collection of standard libraries is infamous for being a "kitchen sink" that stifles innovation and seems to vastly increase the length of time it takes for someone to claim reasonable proficiency in Java.

C# and .NET was just Microsoft's response to Java, just as IE was their response to Netscape Navigator. They had 1000's of developers working for years to make sure it was at least as comprehensive as Java was, only maybe a little bit better with the advantage of hindsight.

That's unfortunate (2, Interesting)

PhrostyMcByte (589271) | about 4 months ago | (#45867995)

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 (5, Funny)

Dahamma (304068) | about 4 months ago | (#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:That's unfortunate (1)

edxwelch (600979) | about 4 months ago | (#45868399)

I can't think of any case where templates would be needed in a graphics library. That's just going to make the code more cryptic and harder to understand.

Re:That's unfortunate (1)

mraeormg (3480869) | about 4 months ago | (#45868579)

Templates are useful when application developers should be able to make low-level, detailed optimizations, like specifying if pixels should be 8, 16, 24-bit. Or even float/double, with/or without alpha.

Re:That's unfortunate (1)

PhrostyMcByte (589271) | about 4 months ago | (#45868635)

AGG uses templates to select all number of things, from component type, colorspace, blending, renderers, and various other things. It is not cryptic at all.

Re:That's unfortunate (3, Interesting)

mraeormg (3480869) | about 4 months ago | (#45868465)

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]

Re:That's unfortunate (0)

Anonymous Coward | about 4 months ago | (#45868641)

Yeah, AGG seems very C++... First example even uses FILE, fprintf, etc...

meh (3, Informative)

Anonymous Coward | about 4 months ago | (#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.

Wrong link. (1)

Anonymous Coward | about 4 months ago | (#45868031)

Link 2 is for a different story.

Please don't (0)

Anonymous Coward | about 4 months ago | (#45868051)

I can see the desire to have common UI/graphics/etc capabilities in a standardized form, but why mash this into C++ itself - why not make a new C++ library of some kind that contains these higher level features.

The way I see it, this is a push to bring C++'s standard library to be more feature aligned with say, the .NET CLR or the standard java classpath - but that's just it, the CLR is not part of the .NET runtime library (mscorlib), it's an additional library - same in Java land.

This should be part of a "Standard C++ Graphics library" or something, just like the STL isn't part of the standard runtime.

Freestanding vs. hosted (1)

tepples (727027) | about 4 months ago | (#45868297)

the STL isn't part of the standard runtime

I thought apart from <iostream> and friends, the STL was the C++ standard library. Are you by any chance referring to the difference between a "freestanding" implementation and a "hosted" one, where a "freestanding" implementation is permitted to leave out standard libraries?

But... why? (2)

zander (2684) | about 4 months ago | (#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.

Re:But... why? (0)

JoeMerchant (803320) | about 4 months ago | (#45868153)

If it's in the standard, it should (slowly) become available on any capable platform.

Write once, run anywhere? Qt doesn't get out much beyond Win/Lin/Mac.

Re:But... why? (4, Insightful)

Gavagai80 (1275204) | about 4 months ago | (#45868383)

Qt doesn't get out much beyond Win/Lin/Mac.

Qt isn't available for enough platforms because it only runs on Windows, Mac, Linux, Android, iOS, Blackberry, Kindle, vXWorks, BSD, Solaris, Haiku, WebOS, OS/2, Tizen and AmigaOS? Anything that passes the "does it run on Amiga?" test is good enough for me.

Re:But... why? (1)

DoofusOfDeath (636671) | about 4 months ago | (#45868535)

Qt doesn't get out much beyond Win/Lin/Mac.

Qt isn't available for enough platforms because it only runs on Windows, Mac, Linux, Android, iOS, Blackberry, Kindle, vXWorks, BSD, Solaris, Haiku, WebOS, OS/2, Tizen and AmigaOS? Anything that passes the "does it run on Amiga?" test is good enough for me.

But can it run on Emacs?

Re:But... why? (2, Informative)

ProzacPatient (915544) | about 4 months ago | (#45868561)

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.

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? (1, Informative)

Anonymous Coward | about 4 months ago | (#45868651)

Wrong. Qt went LGPL years ago, it's properly free for any kind of software.

Re:But... why? (4, Informative)

maztuhblastah (745586) | about 4 months ago | (#45868663)

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

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

Anonymous Coward | about 4 months ago | (#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?

Re:But... why? (1)

TheRealMindChild (743925) | about 4 months ago | (#45868601)

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? (4, Interesting)

mytec (686565) | about 4 months ago | (#45868497)

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.

written in C (0)

Anonymous Coward | about 4 months ago | (#45868061)

"[Cairo] is written in C and has bindings available for many programming languages, including C++, [...]"

Haha, the irony. :)

Cairo has API support for PS/PDF, Win32, Quartz (0)

Anonymous Coward | about 4 months ago | (#45868071)

Ugh. While these are useful features for an API, why do they belong in a standard library of a general purpose programming language?

Graphics libraries and their APIs are Here Today, Gone Tomorrow. The hot thing today will most likely be superseded and irrelevant in 10-15 years time.

Unredirected stdin/stdout is itself superseded (1)

tepples (727027) | about 4 months ago | (#45868251)

Graphics libraries and their APIs are Here Today, Gone Tomorrow. The hot thing today will most likely be superseded and irrelevant in 10-15 years time.

Glass-TTY [catb.org] interfaces, like the implementations of stdin and stdout in C++ compilers targeting PCs when not redirected to a file or pipe, have for the most part been superseded by GUIs. At least Cairo would provide a starting point toward a bare-minimum image manipulation and GUI component that a C++ program can expect, much as Tkinter does for Python.

Uh what? (-1)

Anonymous Coward | about 4 months ago | (#45868089)

Since when do libraries become the "standard"?

Also, what kind of retard thinks passing non-const references is good idea? Nobody with any skill does this.

standard c++ (1, Insightful)

mevets (322601) | about 4 months ago | (#45868105)

Is there anything it cannot do?
The old C++ looks better and better as they nail every bit of crap they can find to her wretched offspring.

Re:standard c++ (0)

Anonymous Coward | about 4 months ago | (#45868175)

Is there anything it cannot do?
The old C++ looks better and better as they nail every bit of crap they can find to her wretched offspring.

Really? I like C++, but you remind me of the old joke:

"Making an object-oriented language by adding classes to C is like making an Octopus by nailing extra legs to a dog."

Re: standard c++ (1)

Nic Wilson (3468773) | about 4 months ago | (#45868257)

what a load of cobblers ALL other languages are C++ wanna-bes

Re: standard c++ (0)

Anonymous Coward | about 4 months ago | (#45868533)

Tell that to smalltalk

Re: standard c++ (1)

phantomfive (622387) | about 4 months ago | (#45868661)

what a load of cobblers ALL other languages are C++ wanna-bes,

This comment shows the limitations of your own knowledge, not anything about languages.

Check out APL sometime if you really want to blow your mind. FORTH is something interesting, too.

Re:standard c++ (4, Insightful)

StripedCow (776465) | about 4 months ago | (#45868207)

Is there anything it cannot do?

Garbage collection.

Re: C++ GC (1)

Anonymous Coward | about 4 months ago | (#45868303)

Is there anything it cannot do?

Garbage collection.

It can, tho. It's not yet in the standard but there are actual garbage collectors for C++.

Re: C++ GC (1)

StripedCow (776465) | about 4 months ago | (#45868315)

Conservative ones, yes.
But accurate ones? Multithreaded? Without "stopping-the-world"?

Re: C++ GC (0)

ProzacPatient (915544) | about 4 months ago | (#45868581)

For me garbage collection is more annoying than its worth.
Any programmer worth his salt is going to make sure his objects are properly cleaned up anyway regardless of garbage collection, but unfortunately most "programmers" these days don't seem to be worth their salt and consequently high-level languages have to compensate for bad programming practices.

Re:standard c++ (1)

phantomfive (622387) | about 4 months ago | (#45868653)

The old C++ looks better and better as they nail every bit of crap they can find to her wretched offspring.

Some people were saying that back in the 80s (specifically, Ken Thompson). It's always been the C++ design strategy.

As usual, fuck the implementation. (2, Interesting)

VortexCortex (1117377) | about 4 months ago | (#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?

Re:As usual, fuck the implementation. (1)

Anonymous Coward | about 4 months ago | (#45868233)

Why should the C++ committee jump through hoops to give you paragraph 3, when you already said you'd rather roll your own polymorphism etc on top of C (paragraph 2)? Unless paragraph 3 was meant as total sarcasm, which is possible too. I skimmed it twice and couldn't tell if you were joking or not.

Re:As usual, fuck the implementation. (3, Informative)

Jeeeb (1141117) | about 4 months ago | (#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.

Windows? (0)

Anonymous Coward | about 4 months ago | (#45868243)

Cairo graphics? Why tie C++ to Windows 95?

Windows? (0)

michaelmalak (91262) | about 4 months ago | (#45868245)

Cairo graphics? Why tie C++ to Windows 95?

Re:Windows? (0)

Anonymous Coward | about 4 months ago | (#45868313)

"Cairo" was actually the code name of a successor to Windows NT which would include an object-oriented file system, a pet topic among researchers in distributed computing in the '90s. Of course that died a horrible death.

I'm sure the irony of Microsoft (Sutter's employer) proposing another 'Cairo' project has not been lost on Herb.

Seems like a bit of a can of worms... (1)

Jeeeb (1141117) | about 4 months ago | (#45868249)

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 library without the ability to handle text seems seriously crippled. On the other hand choices for including text output basically come down to:

  1. 1. Create a standard interface and leave the actual implementation to be platform dependent. In this case rendering results will differ depending on platform.
  2. 2. Choose one library (FreeType) as the standard. In this case rendering results will look natural on platforms that natively use the library (FreeType) but unnatural elsewhere (e.g. OS-X and Windows)

You see "implementation-defined" a lot in C spec (1)

tepples (727027) | about 4 months ago | (#45868281)

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:You see "implementation-defined" a lot in C spe (1)

Jeeeb (1141117) | about 4 months ago | (#45868435)

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.

Floating-point types (1)

tepples (727027) | about 4 months ago | (#45868477)

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 for one (0)

Anonymous Coward | about 4 months ago | (#45868283)

I for one welcome our new 2d graphics overlords

Watch the video (1)

Anonymous Coward | about 4 months ago | (#45868311)

Skip to 1:15:00 and watch Herb Sutter explain why they're doing this stuff.
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond

I hate reading the comments on Slashdot.

WTF? (0)

Anonymous Coward | about 4 months ago | (#45868659)

This is the most asinine idea I hace ever heard of. 2D graphics belongs in a separate library, not part of the language standard. Seriously, I want some of the crazy weed the proposer is smoking.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...