Linked by Thom Holwerda on Tue 12th Oct 2010 21:52 UTC
Java "Oracle and IBM today announced that the companies will collaborate to allow developers and customers to build and innovate based on existing Java investments and the OpenJDK reference implementation. Specifically, the companies will collaborate in the OpenJDK community to develop the leading open source Java environment."
Permalink for comment 445147
To read all comments associated with this story, please click here.
Member since:

... Than again, I must wonder, what's the use?

Makes code a lot easier to read and work on for various reasons, enforces separation of the various components.

If you cannot use:- operators (kernel code that cannot be debugged by reading it is a big no-no in my view).

I use operator overloading heavily myself, since I implemented a cout-ish class for debug output (much easier to implement than printf, and more comfortable when it comes to using it IMO).

You can still debug with usual techniques like moving a breakpoint forward and see where things go wrong. If the code crashes after the instruction using the operator, you know who's faulty...

- virtual functions (as above, plus, they may hide a major performance hit due to unknown vtables depth/size).- You are forced to write your own per-class init and close functions (lack of constructor and destructor error code).

In a kernel, if the initialization of a basic component failed, I think it's time to panic() anyway. But if for some reason you really need an initialization/closing function to return an error code, you can just go the C way and use an "errno" global variable.

- You are forced to re-implement new (over, say kmalloc, with some type of fancy error code management).

Well, new is only as complicated as you want it to be. If you want it to be an automatically-sized malloc, you can just write it this way. You're certainly *not* forced to reimplement new each time you write a new (duh) class.
In the end, you're only left with objects and partial inheritance - or in-short, you more-or-less get an automated "this" pointer.

Again, it's essentially a matter of high readability. In my experience, C code gets messy and unreadable a bit too easily, while with C++ it's easier to keep statements short and easy to read.
Call me crazy, but IMO, it's far easier to implement objects in pure C. (As it's already being done, quite successfully, in the Linux kernel)

Every one has the right to have its own opinion ;)
In my opinion, code readability is more important than ease of implementation. And my experience with Linux code is that it doesn't exactly take readability too far.

P.S. Which kernel are you using?

Couldn't get satisfied with the existing stuff (noticeably because I'm allergic to posix, which limits the range of possibilities quite a lot), so I rolled my own.

Edited 2010-10-15 05:56 UTC

Reply Parent Score: 2