[ros-kernel] C++

[Mike Nordell]

(can someone please stop me from writing this large and detailed comments in
the future?)

Vizzini wrote:

> I hate language wars, and I'm not going to start (or at least
> participate in) one.

This is the first time I've seen war mentioned in this thread. The only
flame-fest attempt I've seen is ... Well, more on that below.

> Executive summary: Bad Idea.

At first I read that as if a comment based on strictly technical merits, and
my reply
 became:
As a long-time C++ user, and sometimes an even highly regarded, designer,
mentor et.c., I find that statement insulting to the ones having a greater
understanding of the language, especially in comparison to C. As I know from
experience how much better code it is possible to produce - yes, in
kernel-mode too - using C++ vs. having been forced to use plain C, I can't
find a shred of sympathy for your standpoint.

Then I realized the "executive" part must have been referring to HR
management too, and the previous paragraph just fell flat on its nose. :-)

> Read on for details if you want; I don't plan on posting about this
> again for another six months. :-)

All good things cometh... If a potential reply will delay six months, it
better be good! :-)

> I'll be the first to say that I'm not a fan of C++ in the kernel in
> particular, and in the project in general.  There are considerations for
> C++ in the kernel that most C++ programmers don't know about, and that
> aren't well-documented by Microsoft.

If they are indeed calling themselves C++ developers/programmers, and
consider themselves skilled enough to use C++ in kernel-mode, they should
have such a level of knowledge of the tool they are using and insight into
the problem domain that they indeed would be aware of all issues. I don't
see what Microsoft should have documented here, in conjunction with a
language, unless you were thinking of SEH (but then I think you would have
written it, since SEH is much shorter than Microsoft :-) ).

> All of the core DDK samples
> continue to be in C (KS sample code aside).

Considering the DDK API is C, I'd say that's quite obvious. Had it been a
C++ API I would have expected the samples to be implemented in C++. The same
for Java, assembler, or any other language. However, there is one crucial
difference between all other language combinations, compared to C and C++.
To C++, C is native.

> The GNU C++ compiler generates crappy code.

Compared to ... the GCC C code generator?

> C++ leads to questionable design practices in
> the hands of a less-than-experienced programmer.

This can be said for any language. As a designer of something it is expected
you have a larger understanding of the domain than mere users have. However,
I don't see how this can be interpreted to be a problem with the tool, C++,
as you claim. Design is done by people. Experienced designers are in general
better designers than inexperienced ones.

In my experience, in the hands of an experienced developer the C++ code is
generally (I was about to write always, but I'm sure someone could come up
with an example proving me wrong) shorter, cleaner and more maintainable
than the equivalent C code. Considering the majority of the cost in
softwares life is maintenance, I think it was worth mentioning.

> 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? :-)

> Furthermore:  almost all kernel coders code in C.

Is anyone really exclusively using assembler, the only other language
currently used in the kernel I'm aware of?

> I want to maximize
> the number of people that can perform useful work for this project, and
> that means playing to the strength of most of the population by not
> changing languages on them.

While this is so far the only valid argument I've seen - and make no
mistake, I consider it a heavyweight argument - I didn't see anyone
suggesting to change the language of the kernel to C++. Did I miss
something?

> For the "C++ is a better C" crowd, you're (mostly) wrong.

Flame-fest fuel? Does such grave insults really belong in this discussion?

As a counter-argument I could reply "No we're not. We're right", with 100%
confidence that my statement would be correct and you would be wrong. But
doing so I would probably open the door to a Freudian sandbox, and in a
reply 6 months from now learn that your dad has a larger car than my dad.
;-)

> C++ is a good OO language,

C++ isn't an OO language, at least not only. To me it's a bit like claiming
ReactOS is open source, when it in fact is free software. C++ is a language
supporting multiple paradigms. If you consider its OO capabilities good, I
think that's a proof that Bjarne got some things right, but at the same time
it's making it start to look like an argument in favor of using C++. :-)

> and if you're going to use C++, you should *use* it, not
> just sample its nice-to-have features (e.g. declaring varaibles near use
> -- C99 has that too).

So the only valid way to use any tool is by using all its functionality at
the same time? I'd really love to see you handle a swizz army-knife. Btw,
what's your blood-type?

I think anyone so dumb as to try to use all features of C++ at the same
time, especially in a severely limited environment as a kernel, doesn't have
his/hers head screwed on straight. To use only the parts of a tool that
makes sense, to "sample" its functionality, I consider a good thing. It
displays a quality of the user, to only use what's required to get the job
done.

> It's precisely because good C++ code is very
> different-looking and different-working than good C code that I do not
> want to switch the project to it.

I can easily see a dozen other reasons to not switch to C++, even that I
obviously also can see a handful of reasons in favor. But again you mention
"switch". Has anyone seriously suggested to switch from C to C++?

> For people that want to use it 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
don't see how this invalidates that C++ can be used as a a better C, even
that you with C++ get many other tools at your disposal too.

[snip]

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

> Oh yeah, lest I should forget,
> every indication I have is that the Windows kernel is C too.

As Andrew asked about specific components, I must assume kernel in this
context is not only ntoskrnl+hal, but also drivers.

Well, then I can report with 100% confidence that there indeed runs a bit of
C++ code in Windows. Instead of boring you all to death with even a partial
list, just grep for ".cpp" in the PDB's from any Windows system symbols.

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

if (!person_comfortable_with(T-Ford) {
  disallow person to use Ferrari
}

Is the zen-like tension between the negation of the positive in the
conditional statement, combined with the affirmative restriction applied,
something intended? :-)

Personally I would have written that as:

if (driver_is_comfortable_with(Ferrari)) {
  allow use of Ferrari
}

If anyone feels more comfortable, as in making them feel more "at home",
using roughtly the logical successor to an older tool - for reasons that
perhaps that older tool many times just feels more limiting, and perhaps
even is - then I think it's quite possible, maybe even likely, that using
the more recent tool would create a better end result.

To claim such a person has no business driving anything more recent than a
T-Ford seems illogical to me.


Finally: I'm in no way supporting a _switch_ to C++. That would be a quite
large effort, with just a questionable end-result and the potential to
alienate people not knowing C++. That said, I'm also not against letting
people use what they feel more comfortable with, and produces best
(maintainable) result with.

/Mike