The Future of Compiz In Question

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

[rant]python rules

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

[/rant]