[ros-kernel] C++

[Vizzini]

Mike,

The eloquence and entertainment value of your response demand that I
acknowledge it. :-)  You make some good points, as always.

I also phrased some things poorly, so let me take a crack at fixing one
or two of them:

On Wed, 2004-03-10 at 15:26, Mike Nordell wrote:
> I don't see what Microsoft should have documented here

SEH, C++EH, kernel stack space, pageable code/data, new/delete issues,
stuff I'm forgetting because I don't do this... VToolsD handles all of
these issues, as do a few toolkits out there (www.hollistech.com has one
I think).

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

> > In driver programming
> > in particular, it can mask bugs under layers of design that take a very
> > long time to fix.  I'm not just shooting from the hip here, either -
> > I've tried this before.
> 
> 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.

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

> > For people that want to use [C++] as a better C, C does everything you really
> > need it to, if you apply it correctly.
> 
> The same can be said for any language, so long as it's Turing-complete. 

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.

> > This isn't the only project with this view, either.  Our closest ally to
> > our project is Wine, and they're (AFAIK) a C-only project.  Apache is C,
> > as is the APR runtime they are built on.
> 
> What does Apache have to do with the ReactOS kernel? Please tell me you
> aren't planning on putting a web-server in the kernel. Please.

Nope, I was citing major free software projects whose policy is "C-only"
as a vague sort of support for my position here.

> > Final thought:  if you're not comfortable enough to code drivers in
> > C, you have no business coding them in C++.

[snipped ferrari vs model T c/c++ analogy]

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

C++ adds many nice-to-have features to the language, to the point of
enabling a fundamentally different (and arguably improved) programming
paradigm.  However, it is still grounded in good old 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++.

 -Vizzini