[ros-kernel] C++

[Andrew Greenwood]

Thought I'd wait for a little while to comment, to save turning things into
a flamewar :)

> > > The GNU C++ compiler generates crappy code.
> >
> > Compared to ... the GCC C code generator?
>
> Compared to any other C++ complier; you may be right in implying that
> this point is a bit irrelevant, or at best is a side issue.

I was actually quite distraught when told the GNU C++ compiler generates
crappy code as I've spent months working on a personal project in GNU C++
which requires fairly high performance (as it's an audio processing app), so
after hearing this I was considering rewriting the whole thing in C, which
would've taken me probably years to do the same thing.

But I won't.


> > So you created a rigid, multi-layered design that turned out to not be
good
> > enough, hiding bugs, and you claim this as a flaw of the tool? :-)
>
> What I meant to say:  I've inherited crappy C++ code that took me
> forever to fix.

Crappy C++ code probably can result from C programmers not able to "let go"
of their good friends malloc() and free() and such. You can use C functions
in C++, yes, but even I spent a while deliberately trying to "get around"
the compiler to do things I could do in C. But before I could make anything
serious in C, I moved to C++.

I just find C++ a lot more simpler - the code is much more elegant (as long
as the programmer can write elegant code...) There are a number of things
like linked lists, dynamic arrays, strings, etc. which are extremely easy to
use in C++'s STL. When I was doing some w32api conversion stuff for ReactOS,
I noticed quite a few linked list structures - even in the MS DDK there are
a few routines that add/remove things from linkied lists. And they look so
horrible to the point it puts me off coding, just because they're so damn
ugly.

C and C++ are both capable of doing the job, but it's quicker and less
error-prone to do it in C++ than to do it in C, in most cases.


> > I didn't see anyone
> > suggesting to change the language of the kernel to C++. Did I miss
> > something?
>
> This was the misstatement that actually prompted me to reply.  I had
> some wires crossed; of course Andrew was not suggesting that we port the
> kernel to C++.  Regardless, please take my previous comments to mean
> that I don't think C++ should be used in general in kernel-mode
> components or in the kernel itself.

Well you did give me an idea. I was tempted to convert user32, gdi32, win32k
etc. to C++ for my own entertainment and to see which one ends up with the
most bugs ;) If I did do that, I wouldn't commit it to CVS though, so don't
worry. It'd just be purely for the sake of seeing how "clean" the code would
be.


> I guess I meant something slightly more specific here:  C++ people (and
> I admit to being one of them, owning about 250,000 lines of it atm for
> my Real Job) tend to complain that certain things are just harder to
> code in C.  It's definitely harder to do OO in C, but apart from that,
> C99 can handle most of the nice-to-have stuff that C++ has.  C99 is
> another argument, of course.

It's not just that - I'm talking about things like the STL, as well as
classes (objects, I know...), which would make resource tracking easier as
you don't have to think "hmm, I've deleted that from the linked list, now I
need to NULL that pointer and free some memory over here...", the class
could automatically free the necessary memory upon destruction.


> > > Final thought:  if you're not comfortable enough to code drivers in
> > > C, you have no business coding them in C++.
> > To claim such a person has no business driving anything more recent than
a
> > T-Ford seems illogical to me.
>
> I did not make myself sufficently clear here.  C can be regarded as a
> subset of C++.  The Kernel's API, as well as all reference materials and
> almost all sample code (certainly all general sample code) are in C.  It
> therefore stands to reason that the budding driver writer will have to
> learn enough about driver writing to be able to write a driver in C.
>
> The point I was trying to make with my original claim is this:  If you
> cannot write a driver in C, it implies a sufficient lack of
> understanding of driver writing that, while it may be possible to get
> lucky with a C++ toolkit and get a driver working, the author will
> clearly not understand the driver to the extent that I believe to be
> necessary to do a good job.  You must crawl before you can walk, and I
> believe being able to write a driver in C is an absolute prerequisite to
> being able to write one in C++.

My main problem is I don't feel comfortable manually implementing things
that C++'s STL already do. Again, like linked lists. If I have multiple
instances of a driver, and have per-instance data for each instance stored
in a linked list, I don't really like having to worry about how I'm going to
manipulate the list - I just want to be able to do it.

I tend to find I understand a lot more about what is going on with C++. And
it just makes me feel less worried about if my code is going to actually run
as expected or not, which is what I'm always worried about.


In any case, I'll just stick to C for writing drivers and stuff in ReactOS.
Just bear in mind it'd probably be quicker for me to do it in C++, so it may
take a while longer.

-Andrew