LWN.net Logo

Quote of the week

Quote of the week

Posted Dec 10, 2004 8:16 UTC (Fri) by aleXXX (subscriber, #2742)
In reply to: Quote of the week by alq666
Parent article: Quote of the week

Among others e.g the kernel of the open source realtime operating system
eCos (http://ecos.sourceware.org) is written in C++.
No problems there (for deeply embedded devices (!) )
And I think there were OSs too , but I can't remember exactly right now
which ones.

Alex


(Log in to post comments)

OSes in C++

Posted Dec 10, 2004 12:12 UTC (Fri) by eru (subscriber, #2753) [Link]

And I think there were OSs too , but I can't remember exactly right now which ones.

ChorusOS is another one (was proprietary, now open-sourced as "Jaluna" under a modified MPL-like license). However, years ago having browsed its kernel code, I got the impression it uses C++ in very limited way as a "better C", using classes mainly to manage name spaces.

OSes in C++

Posted Dec 10, 2004 18:16 UTC (Fri) by daniel (subscriber, #3181) [Link]

"ChorusOS is another one (was proprietary, now open-sourced as "Jaluna" under a modified MPL-like license). However, years ago having browsed its kernel code, I got the impression it uses C++ in very limited way as a "better C", using classes mainly to manage name spaces."

Ahem. Doesn't that make a frightening amount of sense?

Regards,

Daniel

OSes in C++

Posted Dec 11, 2004 12:59 UTC (Sat) by mmutz (guest, #5642) [Link]

> Ahem. Doesn't that make a frightening amount of sense?

Well, either it means that the original authors valued stricter type
checking so much as to use C++ for only that purpose, and/or it means that
the code stems from a time when C++ wasn't really what it is now (e.g.
namespaces are a fairly recent addition) and people understood OOP as a
misspelt oops...

In any case, I don't see the angst factor in that quote, sorry.

OSes in C++

Posted Dec 17, 2004 20:50 UTC (Fri) by zakaelri (guest, #17928) [Link]

I figured that the point of using C++ inside of the kernel would be to take the features that make the code cleaner, without using all of the advanced features that are unnecessary. Anything that has a specific reason to be nasty code (e.g. the function pointer stuff used to increase performance (above)) could keep itself that way.

Meanwhile, you can organize the kernel code better, and clean up someof the grittier parts with C++'s syntactic sugar. This would make it easier to manage in the long run, and new features could be tested and added easially.

Then again, I am not a kernel hacker, and never will be. As long as it works, I don't particulalry care what the code looks like. I can leave that up to the developers. (Furthermore, C++ isn't always faster than C... look at how slow and bulky some of the apps in KDE are... and binding to modules/object libraries is a pain, in my experience.)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds