The Future of Compiz In Question

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

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

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

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

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

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

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.

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

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

[tmpdir]

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

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