The Future of Compiz In Question

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