Slashdot Mirror
Compiz Project Releases C++ Based v0.9.0
werfu writes "Compiz 0.9.0, the first release of Compiz rewritten in C++, has been announced on the Compiz mailing list. See the announcement for more info." Compiz has for years been one of my favorite ways to make Windows users envious, despite my (Linux) systems' otherwise low-end graphics capabilities. Besides the switch to C++ from C, this release "brings a whole new developer API, splits rendering into plugins,
switches the buildsystem from automake to cmake and brings minor functionality improvements."
I'm excited to learn about more software using this new programming language of the future!
Beware: In C++, your friends can see your privates!
But the easiest way of making a windows user envious is to use a mac
So they switched from a sensible programming language to language that is fundamentally broken and to a build system that is incomprehensible for human beings? Wow, what an upgrade!
CAPTCHA: Virtual... How fitting.
This is a good move. I found it surprising that C was still more popular than C++, given C++ benefits. See http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.
The language and dependency changes aside, how much do you want to bet there will be problems in every package distro?
After 2 and a half years of getting Compiz sorted in SuSE, RH, Slackware so you have a 50% or better chance of it working out of the box when you install a distro, not having to dig through massive tweaking to get it operating... I'm expecting a step or two backwards in the "installability" department for a while.
The relevant words from the announcement are "complete rewrite". Or in simpler terms for the users, you do not want to run this until it reaches 0.10 (also as per the article.) This is a development and not stable release. (Sure would be nice if they would go 1.0 instead of .10 if it's going to be a stable release...)
Here's the stuff from the announcement interesting to users:
Everything else is of interest only to developers...
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I had compiz working great in Ubuntu 8, made using Linux fun and is great for adding the "wooo" factor when demoing it for potential switchers, then i installed Ubuntu 10 and it no longer works :(
so i no longer show it to anybody as frankly there isnt much of a visual woo factor over other OSs without it,
and as we know every self-repecting hipster fashionista judges a book by its cover (look at the iphone)
and in order for Linux to be popular with the mainstream it has to do stuff better, that includes making it look "cool" Compiz is a step there.
FOSS has to be able to say "look at how slick this looks AND it can do [task here]"
be proud of your GUI
Would the coding switch gain any speed increase?
Since having the enforced change from the ultra fast, ultra stable Beryl to the not very fast Compiz, I have not been very impressed with Compiz. The developers told me they didn't change anything to get the Beryl fork back into Compiz, but the fact on _MY_ system is simple.
With Beryl I could run whatever effect I wanted and even multiple effects at the same time, and the CPU was barely used, about 98% of the work was offloaded to the graphics card. Now with Compiz if I do something like rotate the cube or some other effect, the CPU ends up doing most of the work, which is ridiculous. Same distro, same graphics card. Obviously something changed.
Actually looking at the process usage right now, Compiz is using 3.9% of the CPU just doing nothing AND with an upgraded CPU. Under Beryl with a same type of processor but slower processor, the maximum CPU usage was 5% doing whatever effect you wanted. This is not right.
Enforcing a change from Beryl to Compiz was wrong.
Take Nobody's Word For It.
This is a first release after the reunification of the Compiz, Compiz++, NOMAD and Compiz Fusion branches. It's unstable, but at least it's good to see all the effort coming under the same roof again.
It'd be nice if the summary contained at least a sentence describing what the software actually does.
Mod me down if you want to, but I've yet to have Windows drop me to a command prompt after an video card driver update, OS update (Ubuntu anyone?) or had to recompile sound drivers after every OS update (Ubuntu on that one too). My file manager will display in a column what date pictures were taken so I can categorize them accordingly, can yours do that? It couldn't the last time I checked.
My Tech Posts on Twitter
Gnome and KDE were imperfect Desktop environments so that F/OSS unix could have one. Now that we are getting a good one at long last (Android). Why stick with the old an obselete?
Why does this feel like another awesome WM that will be crowed about forever, used by few and will shortly stop releasing new versions?
I hate X.
Free-nix needs a new GUI and the only way that's going to happen is through a private company. Why?
BECAUSE GUIs ARE HARD.
They are gigantic systems that require a lot of development AND continuing support. Look how long it took Apple to get Mac OS X right.
X is terrible and anything that continues the zombie life of X is bad.
#getoffmylawnyoukids
I have to agree that the cube is useless (and I don't use it).
There are a number of plugins that increase productivity a lot though, namely the scale, desktop wall, expo, app switcher and zoom plugin. Problem is: the default configuration is not designed to be useful, but to be easy.
While installing new systems, I install the CompizConfig Settings Manager, and then set up the plugins for efficiency: I basically map common window functionality to screen edge/corner clicks with the mouse.
Base setup is 6 (2x3) desktops. I move between these desktops by clicking one of the edges (depending on which direction I want to go - up/down/left/right) of my screen with the right mouse button.. See the overview (expo) with right click to the top-right edge. Alt-tab/Alt-shift-tab with mouse button clicks to the top left edge (app switcher), and see open window overview with right/left clicks to the bottom-left corner of the screen (scale).
This (combined with select - emulated middle button pasting) effectively enables me to do all activity you'd normally need mouse+keyboard to do with keyboard only.. and that very fast and instinctively.
Guess what you wanted to say is: the default configuration could use some tuning. Problem is: though this improves baseline productivity and is very fun when being used to it, it violates the common desktop paradigm that every desktop function has to be an icon, or context menu. In other words, setting it up in a useful manner involves thinking and learning a bit, which most folks seem to avoid by all means. (no offense).
Classes (not virtual)
Sugar for functions that take this as their first argument. But as Micropolis showed, these are useful for taking legacy code that uses global or module-scope variables and allowing it to be instantiated multiple times. I'll grant you this one.
References
Sugar for pointers.
You have other problems when your code runs out of memory that often
Only if you consider running on a microcontroller or a handheld device a "problem". In such a case, running out of memory means the allocator has to purge items from the cache. Then you run into other classes that use new as their factory, for which new might throw for reasons unrelated to memory: TCP connections, file system access, file format parsers, etc.
which means c sucks too once you find hardware which does not support all functions of the c standard lib?
You're referring to 8-bit microprocessors, I take it. But there's still a lot of interesting hardware that runs C well but doesn't do so well at virtual and <iostream> of C++.
as I understand it c has no better alternative to templates
It appears you're not as much of a fan of C++ as a fan of the subset of C++ including C and templates.
if you remove the templates by hand-instantiating them, you'd still have the same issue of code duplication.
The difference is that algorithms and containers in C or Java encourage the use of erasure to a higher type (e.g. void * or java.lang.Object). C++ templates can be used this way, but they can also be instantiated once for each T* (by pointer) or even once for each T (by value). I can think of a few things to watch out for when using templates:
So some people aren't big fans of C++ templates because templates are so easy to misuse.
if you follow ODR then you'll have at most 1 template instantiation for each combination of type parameters.
The problems come when A. programmers become unaware of how many combinations of type parameters they're actually using, or B. programmers can't decipher template type names in compiler diagnostic messages.
Also, libstdc++ is a beast. But so is glibc. If you compile for embedded devices - don't use it.
Newlib is better than glibc for embedded devices. What C++ standard library implementation do you recommend for these?
It's certainly possible to make 'Hello world' to be about 1kb in C++.
I've done so with std::fputs of <cstdio>, but there are still a lot of self-proclaimed C++ purists who apply the no-true-Scotsman fallacy on C++ code using <cstdio>, claiming that <cstdio> isn't in the spirit of C++.
I would imagine that the biggest performance hit for C++ vs C is just the fact that most objects make extensive use of memory allocations. C++ makes this 'safer' than in C, and so most C++ users use it. In C, I tend to avoid memory allocation. You end up defining arrays sized to some reasonable maximum, but there's no performance penalty for that. Occasionally, this does cause problems when that maximum was underestimated, but most of the time it's pretty effective.
Where I work, we have a transaction processing system that was developed in C. Most of the library code is in C, and multiple attempts to build applications in C++ have resulted in something much more complex and less supportable than the 'standard' C apps. I don't know if this is due to unskilled C++ programmers, or if maybe the particular environment, being highly optimized for C coding, just doesn't gain many of the advantages C++ could provide had the platform been object oriented in the first place.
For example, our standard apps maintain state persistence by simply writing out one or more C structures to a temp file on disk. These files are simply read back in on the next transaction, requiring no code and no serious overhead (the data's usually in cache anyway). It sounds crude, but it's amazingly effective. C++ coders could continue to do this, of course, but they've assumed they needed to use objects for this purpose, leading to complex schemes for streaming those objects out to disk for persistence.
Then you get the programmers that attempt to build a pseudo MVC view around a platform that was designed to be a back-end system with a smart terminal front end. In this platform, all the code is on the back end, and the 'view' and the 'controller' are pretty much intertwined. But they persist and build these arbitrary separations which have to then communicate back and forth and each have to persist their own states. After the fact, they've all agreed that what they've built is harder to support than the C stuff they were building before. .Again, maybe this is bad coding or a misunderstanding of the OOP model, but it does point out a problem with C++. Unless you're just building code around an existing, well defined C++ framework, you're not likely to implement a great object model on the first (or fifth) try.
Posted from my Android phone. Oh, I can change this? There, that's better...
you can always use nothrow new
As I understand it, the standard library uses throw new, not nothrow new. So if you use the standard library, you get the exception handlers linked in.
What is the performance overhead of namespaces, [...] references, [...] use of const ints for array sizes (more efficient than C), non-virtual methods, protected/private modifiers
True, these features allow one to use C++ as "a better C". But a lot of C++ fanboys will claim that if a program doesn't use virtual, throw, and <iostream>, it's not in the spirit of C++.
typesafe object creation, STL (the word "virtual" does not appear anywhere in the STL sources)
Exception overhead. Or is the entire C++ standard library also available in a nothrow version?
function and operator overloading
No runtime overhead, but especially operator overloading is easy for a programmer to do wrong. People see += and think "cheap"; they see .addAll (Java) or .extend (Python) and think expensive.
support for wide characters
Doesn't <wchar.h> aka <cwchar> have these too?
Many C++ programmers use printf instead of iostream.
I agree, but C++ fans who write things like C++ FAQ Lite section 15 disagree. See both sides of the story in C++ FQA Lite section 15.
Note that C++0x has features specifically designed to support a typesafe printf
That will be interesting once LLVM and GCC actually implement it. Have they yet?
Big deal, C++ sucks hard if an amateur tries to write in it when he's used to C.
Guess I won't be upgrading.
For example, our standard apps maintain state persistence by simply writing out one or more C structures to a temp file on disk.
Of course, the C standard explicitly states that the layout in memory of structures is implementation-dependent, so doing things like that sets yourself up for serious pain when you do things like change compiler versions, optimization options, or run on different platforms.
In my experience, a lot of programs run without crashing only through sheer luck.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
References
Sugar for pointers.
And C is sugar for assembler, which is sugar for writing machine code directly using a hex editor.
The whole point of any language feature is to make it easier to use machine features. Calling them "sugar" doesn't negate that.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
C++ coders could continue to do this, of course, but they've assumed they needed to use objects for this purpose, leading to complex schemes for streaming those objects out to disk for persistence.
My PoV on C v C++ coding comes down to this kind of stuff. In C, you'll have a function that takes a struct parameter and writes it to file. In C++ you put that function inside the struct and remove the parameter.
so Persist(struct Data d); becomes d.Persist(); simples!
In effect, no difference - except to handily keep methods and data together and easier to understand. Obviously a decent C programmer will put the persistence routines and data struct together in a module... which is roughly the same thing.
The benefit to C++ is that you get all the above type of coding (ie no difference but a bit of easier code organisation) and you can, if you want to, use some nice new features like the STL.
Any coder who thinks that C++ is a great place to go fully OO is miguided, IMHO. I've seen object hierarchies and exception hierarchies that are totally confused, difficult to debug and understand. In fact, you could say that this kind of app should not be written in C++, but written in UML instead! In other words - confused, difficult to understand, debug and fragile as any other "Enterprise" app.
So - keep it simple and you're golden, try to go crazy with every little feature and you're stuffed. I have a feeling that many a coder who tries the latter and fails then moves on to Java or C# thinking its the language that is at fault.
i have an orange afro you insensitive clod
Is way too low for me to have contributed to Compiz anyway. But I do worry when I see simpler projects converting to C++, because I feel that it locks me out along with so many people that might otherwise contribute. I look at C++ and the whole thing may as well be encrypted or written in perl for the amount that I can understand it. I could at least struggle through what the C was trying to tell me.
Nullius in verba
XRandR still broken for multiple video cards? Seriously, it's 2010 and they still haven't fixed that shit. People with three monitors are far more common then they once were, and we still get left out in the cold. Hell, it's shameful that Nvidia's flagship quad monitor cards utterly fail with Compiz because of the little detail of a PCIe switch on the card connecting two GPU's.which are EXACTLY THE SAME. ATI is no better either, and the pain will only increase with the Eyefinity rigs.
I've seen Compiz, and I must admit that a user like me simply not impressed by the bells and whistles. I use my computer to get stuff done. I want the primary interface to get to my apps to stay out of the way and NOT take up the memory I would rather my apps have. In Windows, I set the performance options to maximum performance. Yes, I turn off all of the animations and -- as I see it -- completely unnecessary visual effects. I use my computer for the apps, not to waste time with pretty-pretty icons, swoopy sound effects and transparents fade-ins/outs. For me, it is about the utility of the device. I want the OS to be stable and do its job efficiently. Just get me to my applications and leave my CPU to making my app faster.
Bearded Dragon
or had to recompile sound drivers after every OS update (Ubuntu on that one too).
I wish I could. Sometimes vendors take years to get their sound drivers working. Google realtek, imac, and Windows 64 bit.
I know this is horribly off topic, but I have to say this. This concerns user experience. Recompiling and patching by hand is IDIOTIC thing to require a user to do. Two reasons:
Patching can also go wrong very easily. For instance, if user decides that he seems to have a choice of downloading newer sources. Patch might do something horribly wrong to a wrong version. I know that an experienced user won't do silly things like that, but the inexperienced have no idea why the exact version matters so much. Even when explained to them.
Compiling usually ends in tears also. Most users who have a certain problem with, for instance a wifi-card, and try a certain patch follow a guide that is usually at least an year old. In that year many packages required to build the package you need to patch have changed. Because distro maintainers are not demigods who find every little compile-time bug, you usually get at least one package that simply won't compile with out fiddling. Or you get the same result because the user skipped/forgot one command from the guide. Even if everything went well, you still might end up with a version that screws up your configs.
I had all these problems + crash course to mercurial patching em28xx-driver on Ubuntu 8.10. Even after that my video capture device wouldn't still work other than randomly.
Let's take a car analogy. Say your car's engine is low on power and makes horrid noise. Your friend and an expert tells you that crankshaft bearings need to be replaced (hypothetically). They give you some instructions how to do it. Let's assume you live in a communist country where you can get all necessary parts and tools for free. Now all you need to do is to dismantle the car enough so that you can get the engine out. Then you have to dismantle the whole engine to get to the crankshaft. After replacing the bearings you have to assemble the engine and put it back in the car. Then you only have to assemble the car. Now you have fixed the bugs in your car.
Except that usually when you do things the hard way you hit a dead end somewhere (rusted bolt) and you give up. Or you end up with an engine that has a dozen new problems.
Now I ask you. Would you do all this? Would a normal person do all this? No, they hire someone else to do it i.e. automate the process. Of course, there are people who would do all that. They are called enthusiasts.
Don't design your user experience for enthusiasts.
Both sides of this argument are quite good. Thanks to you both for a well thought out and civilized discussion comparing the strengths of two popular operating systems.
However, this is Slashdot. There is no room for this sort of cerebral and informed debate so I'll have to ask you to leave.
That there is a performance overhead for exceptions is mostly a myth.
There might not be a time overhead, but there sure is a space overhead. Adding a single throw and try...catch to a program compiled with g++ resulted in 64 KiB of additional library code. This is a lot more significant on a handheld device from mid-2001 with 288 KiB of RAM than on its successor from three and a half years later with 4 MiB, so I guess nowadays it isn't enough to worry about.
If the generated code ends up being equivalent instructions, a competently written compiler can eliminate the additional code
For one thing, I don't see how often templates instantiated for types of different sizes would result in equivalent instructions. For another, which free C++ compilers are competently written in this respect?
a defect in one particular implementation isn't a legitimate complaint against the language.
A language is only as good as its best free implementation.