The Future of Compiz In Question

[phoronix]

Phoronix: The Future of Compiz In Question

Rather than announcing a road-map for 2009 or sharing all of the accomplishments this year that were made within the Compiz development community, Kristian Lyngstol has shared some grave concerns for this project that brought "desktop bling" to Linux. Kristian has outlined a few areas that that he believes need to be addressed otherwise it could mean the death of Compiz...

http://www.phoronix.com/vr.php?view=Njk2Mg

[RealNC]

Maybe the thing Compiz needs is a quality standard for merging code, like that for the Linux kernel. If the code is not documented, looks ugly, changes too many things at once, etc, then reject it. This has worked well for the Kernel.

[makosol]

Compiz was a great experiment about desktop effects, but it has never been stable, well integrated in desktops, especially for KDE or easy to configure. However, the benefits of its existence was to show that the Linux desktop could do what others (Windwos and even MacOS X) couldn't. Futhermore, thanks to Compiz, graphics drivers have much improved in compositing support.
Now it's time to retire and invest in other projects like KWin which is (especially in KDE 4.2) all the same powerful, stable, fast, easy to configure and very well integrated in the desktop (link with energy profiles for example). And also, it works without compositing enabled or with 2D acceleration.
Farewell Compiz !

[Schmaker]

I think that compiz has no future. Compiz had to be just a demo of how can linux desktop look like, now it's on windows managers to do this job. There is no more need of Compiz anymore.

[eric.frederich]

Maybe the thing Compiz needs is a quality standard for merging code, like that for the Linux kernel. If the code is not documented, looks ugly, changes too many things at once, etc, then reject it. This has worked well for the Kernel.

If you want things done like in the Linux kernel then Compiz++ is out of the question ;-)
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

[eric.frederich]

I think that compiz has no future. Compiz had to be just a demo of how can linux desktop look like, now it's on windows managers to do this job. There is no more need of Compiz anymore.

Right, its on window managers to do the job, but now many are doing it? Just 1, KDE. I don't see Gnome or XFce doing it...so I'll still use Compiz as I am an xfce user.

[DanL]

I'm not a big fan/user of desktop effects, but I know it draws many users to Linux and has forced improvement in the major video drivers. I wonder how much of Compiz's stagnation is because of frustration with the X.org model. Perhaps devs see it as a "dead end" to keep working on Compiz until a more flexible X server (i.e. Wayland) is in place.

[Melcar]

Right, its on window managers to do the job, but now many are doing it? Just 1, KDE. I don't see Gnome or XFce doing it...so I'll still use Compiz as I am an xfce user.

xfwm already has a composition manager. Metacity is the only one out, but I think there are plans for one in the future. And yes, I also think that ultimately Compiz will give way to the default window managers as they start to integrate composition effects on their own. I just don't see anything Compiz can offer that can't be done on any of the traditional window managers.

[Eragon]

I use compiz-fusion all the time, so I rather don't see the project die :(

[Jebtrix]

It seems like there is no empathy for Compiz plight what so ever.. wow.. well I for one enjoy using it and would rather it take a stable direction then just leave it in the wind. It makes using Linux fun or isn't that allowed? After reading the Compiz C++ thread from its developer it seems like the way to go. Saying other window managers can do it (if they even want to) isn't very reassuring. I've converted 5 friends to Linux and I can attest Compiz helped alot. If for only that reason it should be at least be maintained until a true replacement is developed.

[curaga]

If people only want the cube, 3ddesk existed before compiz and should still work. It could also spin the desktops in other configs than a cube too :p

[RealNC]

Compiz is useful to a lot of people. With KDE 4 it got competition of course, so less people will be using it from now on and its devs might feel like users are abandoning it. If they can manage to shift the current nature of Compiz - an experimental playground for effects with much overkill - into a stable, functional, well behaving and well integrated window manager, then I'm sure Compiz will have a long healthy life.

If the current state of Compiz doesn't change however, then I guess interest will continue dropping and lead to the project's death. Compiz needs someone to work on the boring stuff to achieve the aforementioned stuff. Coding effects and optimizing them sure is interesting. Coding the integration parts along with testing and debugging is not, but someone has to do it, or else :P

[whizse]

xfwm already has a composition manager. Metacity is the only one out, but I think there are plans for one in the future. [...]

Metacity does have a compositing manager, it was added in 2.22.

It's "only" xrender based, similar to xfwm if I'm not mistaken. There are however ongoing experiments to create a gl-based compositor using Clutter and Metacity, usually refered to as "Mutter". If this will be merged into Metacity proper, or only used in Gnome-Shell I don't know.

[TechMage89]

I am currently using the metacity compositor (it isn't enabled by default, so it takes a setting in gconf to turn it on). I vastly prefer it to compiz!

Honestly, I think the problem with compiz is that it was a tech demo with usablity and user-interface, let alone well-documented code, as an afterthought. An application can get away with that for a time, as people marvel at the new technology, but ultimately it becomes clear that the application, while impressive, lacks elegence and is gaudy and impractical in its design.

I think compiz falls into this category, and the technology-centered mentallity is something they will have to combat to remain relevant. Fancy effects do not a good window manager make, ask Vista users. Compiz needs to make performance, stablity, and especially ease-of-use primary goals and relegate the technical flourishes to the status of icing-on-the-cake. Their history and philosophy so far, however, do them no great credit to that end. I think it might even be a good idea to rename the project to reflect the change in goals, for it to be more user-centric.

[deanjo]

What I find disturbing about the whole thing is that a window manager seems to get more attention then actual applications do. Eyecandy does nothing when it comes to making up for the lack of application development or actual functionality. Yes there is a lot of applications out there for linux but very few that actually are full featured or even remotely complete. Eyecandy may draw the n00bs in, but you have to have the apps to have them stay.

[energyman]

compiz was doomed from the beginning with its gconf crap. Then came beryl and made compiz bearable. But at one point I realized that wobbling windows and spinning cubes do not make the desktop better. And even transparency gets in my way way too often. Today I am using kde 4.2-svn. Effects are off most of the time - and when I use them the only usefull feature is scaling and video preview in the thumbnails

[etnlWings]

Compiz has changed window management on *nix forever so even if the project can't reinvent itself, it's not as if the death of compiz is necessarily going to be the death of the functionality or effects it's given users.

My personal preference - while perhaps unrealistic - would be for compiz to become a generic architecture with an API that other window managers could utilise.

Basic window management and desirable behaviour has never been compiz's strength so this would give users the more refined and flexible approach of using their window manager of choice, which could utilise compiz in much the same way xfwm4 and metacity utilise xcompmgr. Meanwhile, the focus of the compiz project could be on stability*, compatibility** and in developing a more user-friendly way for users to selectively choose effects/functions plugins (to use a strained analogy - like in, "the fire fox").

Another advantage of compiz becoming essentially invisible is more than just other window managers could take advantage of the API: gnome-panel, xfce4-panel and plasma could provide access to functionality in the humble form of buttons, liberating me at least from either having to use cryptic keyboard shortcuts or a 'hot corner', just to access the functionality I've enabled.

* **granted, much of compiz's stability relies on everything from x.org, the video drivers and the graphic libraries.


Frankly, I'd be happy if xfwm4 could just do the shift-switch, scale, expo and wall plugins. They're about the only plugins I use, anyway.

[bridgman]

Seems to me that Compiz's biggest "problem" right now is that it works fine for most people today and there are no obvious "next steps" other than the big scary ones (see below). Many of the major obstacles holding back wider use of Compiz (eg. flickering 3D) need to be fixed in other areas of the stack, ie there isn't anything for the Compiz devs to do about them. Same for improving integration -- that is arguably something to be done in other projects, not in Compiz itself.

Developers are just as likely to be drifting off because there is nothing obvious to work on rather than because of a fundamental problem with the project.

One of the big questions that needs to be worked out is exactly how video playback should be handled in a compositing environment. There seems to be general consensus that sync-to-refresh should be implemented in Compiz rather than further up the stack, and that some kind of flow control should be used so that video player apps (or any animated app, I guess, including games) can match their rate of frame creation to the refresh rate, but that's as far as it goes.

Nasty scenarios like displaying 24p video on a 72 Hz display (or a 60 Hz display) need to be considered here, and there are relatively few developers who are sufficiently familiar with all the areas to make the next round of design decisions on their own.

In other words, things will probably drift until the next X developers summit :D

[yogi_berra]

Seems to me that Compiz's biggest "problem" right now is that it works fine for most people today and there are no obvious "next steps" other than the big scary ones (see below).

Really? I thought the biggest problem was that the eyecandy was just that, eyecandy and useless for day to day work (with the exception of certain accessibility plug-ins).

If Compiz wants to attract more developers they should consider providing eyecandy that serves a function beyond that of "bling."

[EmbraceUnity]

Compiz does have a few innovative usability improvements, but I agree that it is mostly "bling."

There is a really simple reason for that. As long as the keyboard and mouse are the dominant input devices, user interfaces won't be able to become much more functional.

The virtual reality and gaming industries have produced some nice new interfaces, and perhaps they will one day become standard.

http://ieet.org/index.php/IEET/more/miller20081229/

Beyond that, it is human biology which is the limiting feature, and more radical alternatives for computer interfacing will need to be considered.

[StefanHamminga]

Really? I thought the biggest problem was that the eyecandy was just that, eyecandy and useless for day to day work (with the exception of certain accessibility plug-ins).

If Compiz wants to attract more developers they should consider providing eyecandy that serves a function beyond that of "bling."

I really don't agree here, in my opinion the 'bling' does a lot for the OS, it is the first thing people see and is also the thing 95% of the regular home and office users look at for a great part of the day. Personally I like the things I spend lots of time looking at to be pretty!

A small example: I've my TV hooked up to a HTPC (actually a bunch of parts with really big and silent coolers thrown in the TV furniture) and use it to play movies, play music, browse a bit, that kind of stuff. Now I set this up with the Ubuntu Netbook Remix GUI and it looks absolutely gorgeous and friends (actual non tech ones) who play with it generally really like how it looks and works. The reactions are mostly: "hey, that Linux stuff looks nice, I'd like to have something like that". Much in contrast to the reactions to a basic, dull Gnome desktop. More functionality but no pretty looks. Nobody would have it.

[etnlWings]

Really? I thought the biggest problem was that the eyecandy was just that, eyecandy and useless for day to day work (with the exception of certain accessibility plug-ins).

If Compiz wants to attract more developers they should consider providing eyecandy that serves a function beyond that of "bling."

There is a lot of really useless stuff in compiz (does anyone use, "Paint fire on screen"?) but even some of the eye-candy is useful in it's own way: plugins like expo and cube make using workspaces more accessible by visualising them well; there's various improvements upon alt-tab functionality and then there's the obvious stuff like full-screen zoom and the scale plugin.

Compiz also offers some tweaks which do enhance usability in their own right: resize overlays offer a way around the usually sluggish task of resizing a window and waiting for it's widgets to constantly be redrawn; maxumize speaks for itself. Edit: I'd also argue that window animations are good in the sense that windows don't just pop on and off screen: you can see where they're being minimized to, etc.

Compiz has a lot of fluff/crud but beyond the self-indulgence, compiz makes the *nix desktop more complete.

[yesterday]

This article doesn't say where those developers are going to. If People are leaving Compiz to work on KWIN or a new compositing manager for GNOME, it's fair to say that project isn't in bad shape, but merely evolving. It's not a failure if the tech used in Compiz finds it's way into more integrated solutions (like KWIN), it's a success. If, however, those developers are leaving Compiz because they are sick of the tech, then that is a problem

[Jimmy]

I found this to be interesting and insightful. Why not Compiz?

http://techbase.kde.org/Projects/KWin/4.0-release-notes#FAQ

It's a good read all the way down to the last line,

KWin aims to provide compositing support, focusing on providing useful compositing features and basic visual effects, while keeping its other strengths.

which pings on usefulness bing a key feature. As pointed out by other posts here many experienced Linux desktop users go for useful before bling. Not that bling doesn't have it's place as a marketing tool :D.

[bridgman]

Nearly every software project claims that their priorities are "useful features not bling", and "stability not haste", unlike *competing* projects :D

[RealNC]

I fail to understand how people can live without wobbling windows.

[Jimmy]

I fail to understand how people can live without wobbling windows.

I live with it mostly because it wobbles the performance right out of the applications I use the most. :D

[liam]

I use Compiz(when I can, the latest Nvidia drivers have destroyed compositing-reinstalling older driver helped naught since they won't instal correctly). I RELY on Compiz to get things done in an efficient way.
It allows me to view all open windows on a desktop with a gesture;all desktops with a gesture. Fast, high quality zooming has been really useful when recording tutuorials. Its tiling feature(found in a few other WM, but none that I know of that don't have problems I don't wish to deal with-GNOME user, BTW)is fantastic. The ability to group windows is(while possible by other means)is easier with Compiz, I find.
There is a good bit of fluff, but so what? Some users like it, and as other have said, it draws attention(and I know my gf loves the wobbly windows-and she is most definitely a power user, so such stuff clearly isn't just for noobs).
I believe I read that compiz++ plans on separating the composition from the wm? I believe this would enable one to run the same WM even if the GL requirements weren't met. Besides that, requiring people to code in C for desktop stuff is insanity. More than likely, IMHO, it will bring more problems than it helps, and performance will be hurt since I just don't think the app coders are being careful enough.
The future is, IMO, Clutter, but NOTHING I have either seen, or heard about, comes close to the configurability of compiz.
Regardless, I think IF compiz really does go away, this would be an extremely bad thing for linux. It gave linux something that, at the time, only Mac had, and, most importantly, showed that a linux desktop(or at least a nice looking one) wasn't an oxymoron.
BTW, there is at least one thing I've noticed that can be worked on in Compiz:vectorize things! KDE was ahead of Gnome when it decided to require svg icons. It seems as though icons could be part of what compiz handles.
Best,
Liam

[yesterday]

I'm not sure why you say that coding with C on the Desktop is insanity. I don't want to get into a language war, but C++ allows you to shoot yourself in the foot just as much as C does.

[liam]

Well, very nearly. The biggest thing in C++ favor, IMO, is the most obvious: having a basically modern object oriented design. I would kill myself if I had to deal with only C for gui stuff.
Don't get me wrong, I've nothing against C. There's nothing better if you don't need the overhead of a more modern language, but I find it takes me longer to produce sane code in c. However, I admit that that may not be the case if I focused more on C, regardless, most cs students/coders are more familiar with vm backed/non memory obsessed lanuages like java or python, ime.

Best,
Liam

[deanjo]

However, I admit that that may not be the case if I focused more on C, regardless, most cs students/coders are more familiar with vm backed/non memory obsessed lanuages like java or python, ime.

Best,
Liam

Hey us old farts are efficient and productive with our old ways. I've got to admit I use C heavily because of the years (gulp going on decades now I guess) of experience with it. Sometimes it's just easier for us because we are so proficient at it. You young whipper snappers have it too easy nowdays. :p

[liam]

I wish C had been stressed more for every CS student rather than just those who were on a systems track, but when I was in school, Java was the thing. Now, I never touch the stuff(Java that is).
Anyway, doesn't being so studly with pointers give you more ammo to throw as the Greatest Generation:D

Best,
Liam

[DanL]

You young whipper snappers have it too easy nowdays. :p
You remind me of this one Dilbert cartoon:
Panel 1:
Wally - This GUI programming is for wimps.

Panel 2:
Dilbert - In my day we had to program with 1's and 0's.
Wally - You had 1's and 0's? We didn't have any 0's so we had to use
'ohs'.

Panel 3:
Dilbert - One time we ran out of 1's. I had to write an entire DB
program using only 0's.

[energyman]

You remind me of this one Dilbert cartoon:
Panel 1:
Wally - This GUI programming is for wimps.

Panel 2:
Dilbert - In my day we had to program with 1's and 0's.
Wally - You had 1's and 0's? We didn't have any 0's so we had to use
'ohs'.

Panel 3:
Dilbert - One time we ran out of 1's. I had to write an entire DB
program using only 0's.

hah! in my time a computer was a person doing calculations and you 'programmed' them by yelling at them until they gave you the desired result! :p

[deanjo]

hah! in my time a computer was a person doing calculations and you 'programmed' them by yelling at them until they gave you the desired result! :p

Heh, my dad's tv remote worked the same way. "Kid go change the channel."

[yesterday]

Well I am a CS student who really likes C -- OK I guess I can see what you mean buy a true OO language being more suitable for GUI type/desktop work, but IIRC most of GNOME is in C, so I guess it's not total insanity is it?

Also, I don't believe lack of competence should be a reason to move to another language. Poor C coders will likely make for poor Java coders or Python coders for non-trivial and non-toy applications. Surely a poor C coder will make a poor C++ coder as well. There is definitely a place for languages that make things easier, but I don't think the rationale should be to encourage poor coders to get involved in a project.

[liam]

Well I am a CS student who really likes C -- OK I guess I can see what you mean buy a true OO language being more suitable for GUI type/desktop work, but IIRC most of GNOME is in C, so I guess it's not total insanity is it?

Any KDE people want to answer this?
Seriously, I hope the gtk rewrite might incorporate a change in language. I truly think that an OO language just fits better for large(in terms of memory), oft reused imagey stuff. That and my previous assertion that OO is simply the norm for most, would increase, IMO, participation for these projects.

Also, I don't believe lack of competence should be a reason to move to another language. Poor C coders will likely make for poor Java coders or Python coders for non-trivial and non-toy applications. Surely a poor C coder will make a poor C++ coder as well. There is definitely a place for languages that make things easier, but I don't think the rationale should be to encourage poor coders to get involved in a project.It's not simply lack of competence, but lack of need/desire, I think. Most departments simply don't think most students will have to worry about the things C forces you to think about. Very similar to assembly,IMO. Both are taught to some extent, but they are intro'd more for pedagogical reasons than actual interest in producing practical codes in said languages. Blame the departments, or marketplace, if you will. They teach for the "center", so to speak. Not intending to produce web designers or microcode developers. JMO, based on my experiences and anecdotes from friends(when I was i school, I only took the recommended CS classes for my major).
Lastly, I believe that it takes longer to produce an efficient C programmer than a Java one. Java is a bigger language(have I mentioned that I don't like Java?), but it really lets one look at design more than implementation,IMO. So I don't think it is a question of poor programmers, but CS program tracks and marketplace(how many .NET programming positions are available vs. those asking for expertise with C?).

Best,
Liam

[energyman]

Well I am a CS student who really likes C -- OK I guess I can see what you mean buy a true OO language being more suitable for GUI type/desktop work, but IIRC most of GNOME is in C, so I guess it's not total insanity is it?

Also, I don't believe lack of competence should be a reason to move to another language. Poor C coders will likely make for poor Java coders or Python coders for non-trivial and non-toy applications. Surely a poor C coder will make a poor C++ coder as well. There is definitely a place for languages that make things easier, but I don't think the rationale should be to encourage poor coders to get involved in a project.

yes, gnome is written in C because 'more people know C' - and they jump to a lot of hoops to implement OO in C. That alone explains some of the size and uglyness of glib and gtk. It is pretty much a mess.

If you want oo - why not use an oo language in the first place?

[spykes]

If you want oo - why not use an oo language in the first place ?

What about python instead of C++ then ?
Let the core program being written in C, and do the UI design using Python.

Anyway, I don't think that the size of Glib and/or bad code has something to do with the language itself.
It's as easy (if not easier) to write crap using C++.

[energyman]

because python is dead slow - and not everybody likes forced formatting?

[spykes]

And Objective C ?

[curaga]

Eww. Please tell what is good in OO. Having to type 10x longer function names just to get anything done clearly affects production rates.

[elanthis]

Eww. Please tell what is good in OO. Having to type 10x longer function names just to get anything done clearly affects production rates.

What? OO-style languages usually _reduce_ the length of function call code... at absolute worst, it should be almost same as in procedural-style C code. If you're writing OO code in any sane language that's making things much longer than the C equivalent then you're doing something really off the wall.

That said, Obj-C is probably not the best bet for a low-level component like the X server. It's a relatively dynamic language and incurs a lot of overhead on method calls compared to something like C or C++. (C++ has no additional overhead compared to C for non-virtual method calls, and its implementation of virtual methods is essentially identical to any C code that uses a shared struct of function pointers -- and you can implement any other style of virtual methods in C++ but do it with a shorter and easier calling convention than C would require.)

Here I was thinking this was 2009 and that irrational fear of anything non-C was long dead.

[curaga]

Uhhh... Lets compare.

C: puts("Hi")
Java: system.output.println("Hi")
C++: std::puts("Hi")

C is leading with 4 chars. The same function in Java is measly 22 chars, and in C++ it's 9 characters. And you were saying about shorter functions?

[energyman]

and how many headers do you have to include in your c app?

[Ze..]

Uhhh... Lets compare.

C: puts("Hi")
Java: system.output.println("Hi")
C++: std::puts("Hi")

C is leading with 4 chars. The same function in Java is measly 22 chars, and in C++ it's 9 characters. And you were saying about shorter functions?
actually it's puts("Hi") , you don't need the std bit if you put the namespace std; up the top.

btw that's a trivial example and can easily come up with other trivial examples where c++ wins , just look at operator overloading... matrix3 = 2DMatrixPlus(matrix1,matrix2); versus matrix3=matrix1+matrix2;

There are something that c++ buys you like templates , much better type safety and streams and it's only getting better with c++0x which adds some nice features.

Then we've got the fact that the speed arguments for c++ are bullshit.

A lot of folks use function pointers and structs to emulate objects , then we've got the whole mess with frameworks like GObject.

The fact is that object oriented code in c++ is more readable than object oriented code in c.

Yes you can write hard to read c++ but you can also write hard to read c.

IMHO most arguments against c++ are generally basing their opinion on past compiler support , it's much better now (although the error messages in some cases could be significantly improved).

[elanthis]

IMHO most arguments against c++ are generally basing their opinion on past compiler support , it's much better now (although the error messages in some cases could be significantly improved).

Yeah, C++ on Linux/UNIX has a major stigma thanks to GCC's past with constantly changing language support and its ever-breaking C++ ABI. Those days are thankfully long gone, but the foul taste still lingers in some of the older Linux/UNIX users' mouths. :(

The other half of the C++ hatred is just ignorance and obstinence, really. Linus has his famous mailing list post that people keep quoting as reasons to avoid C++ at all costs, despite the fact that his whole argument comes down to "stupid people write stupid code in C++, so C++ must suck!" By his own logic and by his own complaints against much of the contributed kernel code, C must be an even more horrific language than C++. ;)

C++ isn't the best language for most use-cases, but honestly, here in 2009, I can't think of any reasons to _ever_ prefer C over C++ if you have the choice. And no, language binding modules are not a good reason. Absolutely nothing stops people from writing C modules for Python/Perl/Ruby/whatever in C++. Extern "C" exists for precisely those use cases.

You don't even need to write your code as OO in C++. C++ is NOT an OOP language, it's a multi-paradigm language. If you just want to use some of C++'s features to make your procedural code easier to read and maintain, go for it!

[tmpdir]

C++ versus C? I though i was in a thread about Compiz... but as long I'm here :D

IMHO I don't think C, C++ (or whatever other language) is better or more efficient than the other. We all can give 1000+ examples where the one or the other is more compact or better... the thing is it are just tools and we devs just choose the best tool for the job.

That said, I prefer C++... just fits my way of thinking better ;)

[energyman]

don't forget that Linus talking from a kernel point of view - and C++ isn't that good for kernel work.

[Ze..]

don't forget that Linus talking from a kernel point of view - and C++ isn't that good for kernel work.
Apple uses a large amount of c++ for their systems level code ,so does Microsoft , then we've got the real time OS people that use it , I think it's QNX from memory , although it could be VxWorks.

Anybody who says c++ isn't good for kernel level work is a fool who doesn't understand the language. If c++ is bad for kernel level work then so is c.

The linux kernel has a huge mess where they try to do object oriented c but it's a horrible kludge. They could make their lives easier by using c++. You can still do the low level bit manipulation with c++, but you can also do higher level things with more checking instead of hacky macros and sacrificing some compile time checking.
The other half of the C++ hatred is just ignorance and obstinence, really. Linus has his famous mailing list post that people keep quoting as reasons to avoid C++ at all costs, despite the fact that his whole argument comes down to "stupid people write stupid code in C++, so C++ must suck!" By his own logic and by his own complaints against much of the contributed kernel code, C must be an even more horrific language than C++. ;)
The only useful thing about Linus famous mailing list post on c++ is that the people who use it in an argument make a mockery of themselves.
C++ isn't the best language for most use-cases, but honestly, here in 2009, I can't think of any reasons to _ever_ prefer C over C++ if you have the choice. And no, language binding modules are not a good reason. Absolutely nothing stops people from writing C modules for Python/Perl/Ruby/whatever in C++. Extern "C" exists for precisely those use cases.
The thing is for those language bindings , people end up writing extra macros to help them do language bindings and there are language binding generators for c++.
You don't even need to write your code as OO in C++. C++ is NOT an OOP language, it's a multi-paradigm language. If you just want to use some of C++'s features to make your procedural code easier to read and maintain, go for it!
That's the sad thing most folks don't think like that.

[energyman]

apple using c++?
where? in the bsd layer? I don't think so. Darwin? Do you have sources for your claims?
And Linus (and others) have listed all the draw backs of c++ if used for kernel programming, just search the lkml archives - and we are talking about fundamental technical problems. Not some fancy 'i don't like the syntax' or 'oo is for pussies' stuff. And qnx? I really don't believe that it is c++. Too small. Really, any sources to support your claims?

edit: when I look around at qnx I find gems like this:
http://www.qnx.com/developers/docs/6.4.0/ddk_en/character/about.html
To use this guide, you need to have:
sufficient hardware documentation for your hardware in order to be able to program all the registers
a working knowledge of the C programming language.

[elanthis]

apple using c++?
where? in the bsd layer? I don't think so. Darwin? Do you have sources for your claims?

http://developer.apple.com/DOCUMENTATION/Darwin/Conceptual/KernelProgramming/style/chapter_5_section_2.html

And Linus (and others) have listed all the draw backs of c++ if used for kernel programming, just search the lkml archives - and we are talking about fundamental technical problems.

No, they are not. Linus whole thing against C++ is "stupid programmers write over-abstracted code." That's it. And, frankly, Linus is not the God of Kernel Programming. Dude can be wrong quite often.

[energyman]

no, it boils down to problems with memory managment, compilers fucking you over, problems with bloat, problems with speed, problems with latencies. And a lot else. Stupid people writing stupid code is just the icing on the cake.

[Ze..]

apple using c++?
where? in the bsd layer? I don't think so. Darwin? Do you have sources for your claims?
LLVM , if a compiler isn't systems level code , I dunno what is. I'm sure there'd be other uses of it.

And Linus (and others) have listed all the draw backs of c++ if used for kernel programming, just search the lkml archives - and we are talking about fundamental technical problems. Not some fancy 'i don't like the syntax' or 'oo is for pussies' stuff.
Have you actually read their rants and arguments? and understood them from a computer science perspective. Ie from someone who knows the algorithms underlying operating systems and compilers? and knows enough to have a bloody good idea how to implement them if need be? (btw I do , I'd need to look up some stuff on the OS side on the assembly side for particular chips, but I know about the rest , on the compilers side , I've implemented simple compilers before).

The kernel has hacked together it's own OO framework in c. (kinda like glib in gtk and you don't want to get me started on what an abortion that is , and before you mention Qt , I've got my own thoughts on some of the non-standard c++ in that as well).

They clearly don't mind function pointers , or macros.

Templates are basically macro's with type safety. Whilst the vtables used in dynamic dispatch are just a struct of function pointers with some added type safety.

Operator overloading is syntactic sugar. C++ still has structs and unions , and bit manipulation. Streams are just syntactic sugar. new and delete are just malloc with type safety. c++ supports both dynamic (ie runtime) and static (ie compile time) casts.

When you look at it from a critical point of view you find that the kernel developers arguments against c++ are uninformed rants or based upon old information.

When the c++ frontend for LLVM matures (it's still early days) , a lot of the arguments based upon gcc c++ feedback and errors will probably go away , although they have improved a lot in the last few years.
And qnx? I really don't believe that it is c++. Too small. Really, any sources to support your claims?

edit: when I look around at qnx I find gems like this:
http://www.qnx.com/developers/docs/6.4.0/ddk_en/character/about.html
To use this guide, you need to have:
sufficient hardware documentation for your hardware in order to be able to program all the registers
a working knowledge of the C programming language.
I can't remember whether it's QNX or VxWorks, or maybe my mind is playing tricks on me but that doesn't change the fact that other OS's do you use it (ie Microsoft's).

[TechMage89]

And Linus (and others) have listed all the draw backs of c++ if used for kernel programming, just search the lkml archives - and we are talking about fundamental technical problems.

Really? Explain to me, then, why when OS researchers wanted to reimplement the L4 microkernel that was then implemented in x86 assembly code in a platform-independant way with a minimal hit in performance, they decided to do it in C++. And explain to me why it was a resounding success, and has been used as a kernel for GNU HURD. http://l4ka.org/projects/pistachio/

[Ze..]

no, it boils down to problems with memory managment, compilers fucking you over, problems with bloat, problems with speed, problems with latencies. And a lot else. Stupid people writing stupid code is just the icing on the cake.
Could you elaborate more on these supposed problems?

Do you actually know what you are talking about? ie education or substantial experience in computer science or a related field? or are you just parroting back somebody else's argument? because my experience and education are telling me that there your argument is lacking in substance.

[elanthis]

no, it boils down to problems with memory managment, compilers fucking you over, problems with bloat, problems with speed, problems with latencies. And a lot else. Stupid people writing stupid code is just the icing on the cake.

That is completely ridiculous. C++ is IDENTICAL to C in almost every regard in terms of generated code. Memory management? Use malloc(). Want to use new/delete? Use custom new/delete operators or even more likely (if you're writing kernel code) use a kernel C++ support library intended for that environment.

Compilers? Name a problem. A real one that exists outside of the stupid broken-ass crap GCC had years and years ago.

Bloat? That's a vague, meaningless, hand-wavey term. C++ adds no bloat that you don't ask it to with a two exceptions, both of which can be completely disabled if you feel the additional information generated is not worth the convenience of said features. One of those is the RTTI facility and the other is Exceptions.

Speed? The generated code will be identical to C unless you're explicitly using a facility that C doesn't have. I mean, sure, virtual functions are slower than calling a C function directly, but they're IDENTICAL to looking up a function pointer in a struct referenced by another struct, which the Linux kernel does all over the place! A C++ function call is THE EXACT FREAKING SAME as a C function call, as is pretty much everything else in the two languages.

Latencies? Now you're just making stuff up.

C is nothing more than syntactic sugar on top of assembler, right? C++ is nothing more than syntactic sugar on top of C, with the only true environment extension being Exceptions -- which you can completely turn off if you don't want them in a kernel context.

I refuse to listen to kernel developers who've never even seriously used C++ or made any real effort to understand it try to go on and on about it being unsuited for a task that it was explicitly designed for and has been quite successfully used for. Linus and most of the other Linux developers have their heads firmly lodged in their asses when it comes to this topic. Maybe they got bitten by the crappy GCC C++ support in years past, but it's stupid to confuse one of GCC's many failings with the language itself.

There are many common things found in C++ applications that make no sense in a kernel; this is true. Nothing in C++ forces those things on users, though. The STL is not suited for most kernel tasks... so don't use it! You don't need to include any STL headers in the kernel at all if you don't want them available. Don't want IOStreams? Don't include it! Don't want Regular Expressions (TR1/C++0X)? Don't include them! The C standard specifies a bunch of "required" functions that the kernel doesn't want either (e.g. stdio routines), but I don't hear people bitching about C being "too bloated" for kernel development, do I?

[energyman]

but exactly that is the problem! with every single release (except X.Y.Z+1) c++ is broken by gcc. And gcc is THE compiler used. And for the other 'crap' - if you are so much smarter than the kernel devs, you can certainly write a driver in c++ that is better, simpler, less buggy, has at least the same performance and does not need more memory. Until then I choose to believe the people who
a) do it for their living
b) have tried it in the past and saw it failing badly.

[PuckPoltergeist]

That is completely ridiculous. C++ is IDENTICAL to C in almost every regard in terms of generated code.

Write a simple "hello world" application. Compile it first with gcc and second with g++. You will see that it is NOT identical.

[some-guy]

Hello World means nothing, the language should be decided based on whether on not it's best-suited for that purpose, and whether it is feasible.

python rules
#!/usr/bin/env python
print "Hello World"

[energyman]

exactly, and a group of highly skilled kernel programmers decided that c++ is unfit for their usage scenario. That does not mean that c++ is bad.

[elanthis]

but exactly that is the problem! with every single release (except X.Y.Z+1) c++ is broken by gcc. And gcc is THE compiler used.

Has not been true for years. I believe G++ 2.96 was the last compiler to use a non-standardized ABI. Some of the G++ 3.x have fixed a few bugs in the C++ spec support, but those have only broken things when using non-standard syntax anyway. 4.x has dropped support for a few more G++ extensions while adding support for parts of C++0x.

I have had to tweak a few applications to get them to compile with certain GCC releases since 3.0, but in every case it has either been because the code was wrong and I just didn't notice or because I was relying on a non-standard extension. I haven't had to modify any of my large C++ apps since G++ 4.1, and the 4.1 modification was only because I had accidentally used 'class' in a few places where I should have been using 'typename'.

And for the other 'crap' - if you are so much smarter than the kernel devs, you can certainly write a driver in c++ that is better, simpler, less buggy, has at least the same performance and does not need more memory.

See, this is being unfair. You've now changed your requirements from "not being worse than C" to "being _better_ than C."

Nobody said C++ magically makes things better. I'm just arguing that it does not magically make things worse. It is equivalent in most regards. C++ makes many things easier to write, but that's only true when you have all of that support code written -- which the Linux kernel does not.

I'm also not arguing that Linux convert to using C++. I'm only saying that it's dumb to claim that people are wrong for choosing C++ for their development just because the kernel developers have decided against it based on flawed reasoning.

Until then I choose to believe the people who
a) do it for their living
b) have tried it in the past and saw it failing badly.

See, that's a dangerous line of thinking. :) By that same reasoning, the Linux kernel must totally suck because there are many people who run servers or large desktop/workstation installations for a living and have found Linux to fail badly in their scenarios.

What does that mean? It could mean Linux sucks for those environments. It could mean that Linux sucked 5+ years ago for those environments, but doesn't now. It could mean that the people trying it were just not very familiar with Linux but were very familiar with another system and found the learning curve not worth the potential gain. It could mean that they're bigots.

Form your own opinions based on your own experiences, not on what other people say. Others' opinions make nice guidelines, but other people -- even large numbers of intelligent people -- can be wrong.

Write a simple "hello world" application. Compile it first with gcc and second with g++. You will see that it is NOT identical.

No, I don't. I tried compiling the following two Hello World applications, and found them 100% identical aside from some additional library initialization code for libstdc++ (which wouldn't exist in a kernel context):

/* C version */
#include <stdio.h>
int main(int, char**) {
printf("Hello world!\n");
return 0;
}

// C++ version
#include <cstdio>
int main(int, char**) {
std::printf("Hellow world!\n");
return 0;
}

Obviously if you use C++ IOStreams then the C++ version will generate different code, but that's not a useful comparison of compilers. Besides, IOStreams admittedly kind of sucks -- it gives some nice advantages (type safety, extensibility) in exchange for low-level performance and ease of localization. The great thing about C++ is that you're not forced to make that trade-off if you don't want to. :)

On a side note, Java will generate identical code (when using AOT compilation on GCC) to equivalent C code as well. That is, after all, what one would expect when using a single machine code generator for all these language frontends. The Java output will obviously have a lot more library initialization and shutdown code, and there is no direct analogue to printf or many other C functions, but number-crunching code and the like really does result in identical assembly language output.

Real programs don't start and stop over and over. They don't incur the library startup overhead more than once. And, in the case of something like the kernel, which is already non-standard C on account of not including a full ANSI-compliant libc and on account of using a specialized linking process, it's silly to think that using C++ (or Java, or any other GCC-supported language) is going to magically force their standard runtime baggage on the kernel.

[energyman]

if c++ is not better than there is no reason to switch. In fact, allowing c++ would be idiotic because it increases the work. devs must be 'fluent' in both c and c++, you would have to think about interaction of the languages - and if you belief that gcc does not break stuff a lot between releases, you are completly out of the loop.
So to justify c++ it has to be better. It is not? Well, then it is worse.

[Pesho]

if c++ is not better than there is no reason to switch. In fact, allowing c++ would be idiotic because it increases the work. devs must be 'fluent' in both c and c++, you would have to think about interaction of the languages - and if you belief that gcc does not break stuff a lot between releases, you are completly out of the loop.
So to justify c++ it has to be better. It is not? Well, then it is worse.


There is no "if". Of course C++ is much better (in the hands of someone who understands well both C and C++), and for userspace programs that's not even debatable.

[energyman]

there are a lot of 'ifs'. Just claiming that c++ is better is delusional. And userspace is a completly different story.

[Pesho]

there are a lot of 'ifs'. Just claiming that c++ is better is delusional. And userspace is a completly different story.


All your "ifs" so far have been already debunked in this thread. If you make up additional ones, I'd be happy to debunk them too.

[energyman]

not one single 'if' has been debunked. Instead a group of rabid c++ fanboys spill a lot of bullshit - and while they defend c++ with arguments like 'someone should use the best tool for a job', they attac ka group of highly skilled people who have found that c++ is not the best tool for them.

And my most important point still stands: introducing c++ would increase work load and decrease the amount of people able to understand the code.

so could you stop this bullshitting? All your 'arguments' why c++ is great have been refuted many times on lkml.

Oh - and if you don#t beleif that gcc breaks a lot, just look at the kernel build system and all the stuff that is there just because of all the differently broken gccs. With c++ it would become much worse.

[Pesho]

And my most important point still stands: introducing c++ would increase work load and decrease the amount of people able to understand the code.


The first statement is not true, and the second is a tradeoff (less people, but more skilled).


so could you stop this bullshitting? All your 'arguments' why c++ is great have been refuted many times on lkml.


Stop using LKML and the Linux kernel developers as arguments. They're irrelevant in this case. In kernel programming you are generally afraid of any hidden memory allocations, and also hate any high-level abstractions which hide low-level complexities. In userspace programming, such abstractions are a good thing.


Oh - and if you don#t beleif that gcc breaks a lot, just look at the kernel build system and all the stuff that is there just because of all the differently broken gccs. With c++ it would become much worse.


I know when GCC does and doesn't break very well, thanks. Once again, we are not talking about kernel development here.

[energyman]

of course qwould it increase the workload! People would have to KNOW and USE TWO languages to do, what they can do with ONE at the moment. They would have to READ two languages, UNDERSTAND pretty complex code in TWO languages. At the end: much more work for NOTHING.

So would you please come out of your little fanboy world and smell the roses?

'We are not talking about kernel development? Really? It was not me who brought up the kernel. It was not me attacking Linus for dismissing c++ for the linux kernel.

[elanthis]

if c++ is not better than there is no reason to switch.

Energyman, nobody is asking that the kernel switch. You're arguing against something nobody is talking about. This thread is about COMPIZ switching, not the kernel. :)

I just took affront to the claim that C++ is unsuited for kernel programming.

[Pesho]

of course qwould it increase the workload! People would have to KNOW and USE TWO languages to do, what they can do with ONE at the moment. They would have to READ two languages, UNDERSTAND pretty complex code in TWO languages. At the end: much more work for NOTHING.


For a given task X, it almost always takes less time to implement it just as efficiently in C++ than in C. Besides, there exist developers who are put off by the restriction to just C in the current Compiz, and might consider contributing if it used C++ (I'm such a developer, btw).


So would you please come out of your little fanboy world and smell the roses?


Calling every C++ developer a fanboy doesn't help your argument. I didn't see anybody calling you a C troll.


'We are not talking about kernel development? Really? It was not me who brought up the kernel. It was not me attacking Linus for dismissing c++ for the linux kernel.


Since when is Compiz (a window manager) in kernelspace?

[energyman]

it was not me who started with the 'Linus is stupid because he refuses c++ for the kernel' bullshit. That was you c++ fanboys who started with that. And SUDDENLY you backflip. Well done.

[bitnick]

Since this thread already has gone way off topic...

I'm experienced in C (many years of experience) and have also done some serious coding and debugging in C++ (using operators, templates, exceptions and whatnot).

For me, C is seriously lacking since it does not really support an object oriented approach. (Ok, I know there are ways to more or less use C in an object oriented way - f.ex. there's a document out there called "Object-Oriented Programming With ANSI-C". This is interesting and beautiful in its own way but requires a special pre-processor and other sacrifices. Normal structs containing function pointers does not allow inheritance in a comfortable way, and it gets even worse when you try to encapsulate data. Etc.)

Unfortunately I have not been able to get comfortable with C++ either. Abominations like automatic constructors that try to convert practically anything to something completely different (bye-bye type safety), templates (while macros are sometimes useful I think they should be used sparingly, and templates can really make debugging hellish - trying to debug cross compiled code on a target without gdb and with templates making printf unusable was not much fun - not to mention they mostly exist to enable programmers *not* to do things the correct, object oriented way) - and WHY does C++ still allow C-style casts?!

And what's wrong with Foo foo = Foo()? Why Foo foo()? :confused:

Oh, and operators: here (http://www.artima.com/cppsource/safebool.html) is an interesting description of what you have to do to implement operator bool() properly. It amounts to at least an A4 page of code, with several classes. All this to enable the programmer to use object foo like this:

if (foo) {...}

... which only really makes the code less readable: are we checking if foo is NULL or are we calling foo.operator bool? Compare to

if (foo.is_ok()) {...} // Or whatever, which is crystal clear.


What I'd like is C with 'class' support incl inheritance and encapsulation, new/delete, and C++-style casts ONLY. No operators, friends, templates etc. Is that really too much to ask? ;)

[King InuYasha]

ReactOS uses C++, nuff said.

Explanation:

ReactOS uses C++ for a majority of its code, from kernel, to explorer, to notepad, etc.

It does use C, but C++ is favored.

The reverse is true in Linux kernel programming. There ARE a few bits and pieces of C++ code, but because of the general culture towards C++ (as already debated here), C code is more likely accepted, and so the shift there is toward C.

Honestly, it is just a matter of preference.

Case in point, Java.

A lot of people say Java is crap to work with because it is slow as molasses.

Well, when running as a JIT unoptimized JVM like the official Sun Java build, of course it is slow! However, running optimized builds made from source directly tend to be faster.

And getting around the JVM, you could AOT (ahead of time) compile the code with GCC and get code assembled into a true binary.

Performance is a matter of the runtime. Usability is a matter of preference. Meh.

[tmpdir]

O dear, another language discussion... I'll just sit on my hands this round ;)

I really don't agree here, in my opinion the 'bling' does a lot for the OS

I've my TV hooked up to a HTPC


I agree... but keep in mind that htpc software is something different. Here the bling part is more important than in your everage desktop workplace.

[deanjo]

Well here is what blackduck software has to say about the whole thing:

http://www.blackducksoftware.com/news/news/2009-01-21


In fact, we counted over 17,000 projects from the class of 2008 – those projects that show a creation or registration date in 2008. 47% of these newly created projects used the C language. Java came in as the number two language of choice at nearly 28%. Third was Javascript at over 20%. In the world of scripting, nearly 18% of the projects chose to use Perl while only 11% used PHP. These were both higher than Python at nearly 10% and Ruby at 6%. Note, most projects used more than one language and these results are based on the number of projects using a given language, not the number of lines of code created.

[tmpdir]

Well here is what blackduck software has to say about the whole thing:

http://www.blackducksoftware.com/news/news/2009-01-21

Interesting stats... thanks. Around me I see and hear more and more people use python as their main script language.