| |||||||||||||
OSes in C++OSes in C++Posted Dec 10, 2004 12:12 UTC (Fri) by eru (subscriber, #2753)In reply to: Quote of the week by aleXXX Parent article: Quote of the week 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.
(Log in to post comments)
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.)
|
|||||||||||||