C is better than C++ for small projects, right?

[Steven T. Hatton]

You can scroll down to the last line of this post in order to find the
question I really want to discuss.

I was just pondering the competing applicability of C vs. C++ in certain
problem domains. Then I saw this as Stroustrup's FAQ of the day:

http://www.research.att.com/~bs/bs_faq.html#C-is-better
Q:"C is better than C++ for small projects, right?"

A:"Not in my opinion. I never saw a project for which C was better than C++
for any reason but the lack of a good C++ compiler."


What I was thinking about was not the size of the project, but rather the
level of the project in terms of abstraction. Here are some products I
know of which are written in C, and I wonder if there is any compelling
reason that C++ could not be used, or any significant advantage to using
C++.

DBus, OpenSSH, the Linux kernel, OpenGL, Emacs (first implemented in C by
James Gosling).

If I were asked what the biggest problem with using C++ for a project is, I
would say the difficulty in learning C++. Linus Torvalds has used some
strong words to state his opinion on using C++ in the Kernel.

<quote>

>
> This is the "We've always used COBOL^H^H^H^H" argument.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

Feel free to make up (d).

Linus
</quote>

OTOH, we have this more scientific sounding assessment suggesting there /is/
merit to using C++ in the kernel:

http://netlab.ru.is/exception/LinuxCXX.shtml


My own opinion is that I think C code is ugly. That really is a bit more
reasoned than it may sound. A good example is OpenGL and its hundreds of
flags used as parameters to functions all in one flat namespace. I will
however, concede that C++ programmers often fail to make effective use of
namespaces, especially when communicating with humans. I am at fault in
the area.

A good example of what I mean here is the common practice of talking about
"global" functions in the std namespace. There are many times when text,
or code could be made more clear by being explicit about, e.g., which
getline is being described or invoked. IOW, rather than writing getline in
a tutorial, or other context where the meaning may not be clear it may be
more effective to write std::getline. I sometimes get the sense that C++
programmers feel mildly embarrassed about namespaces. Many also fail to
see namespaces as a means of human-to-human communication. They think of
them exclusively as a means of avoiding naming collisions.

I do wonder if the abstractness of C++ does (or can) make C++ more difficult
to work with when it comes to code that's close to the metal. That is,
code which depends closely on the exact memory addresses being accessed,
and order of machine instruction invocation?

Is C++ a good language for writing device drivers and other OS components?

 

[Alf P. Steinbach]

* Steven T. Hatton:

Is C++ a good language for writing device drivers

C is, and C++ incorporates essentially all of C while
adding little or no overhead, and much better abstraction. But
that assumes a reasonable interpretation of the question. The
reasonable interpretation: we're talking about specific implementations
that provide the necessary functionality (types, linkage, and so on),
because standard C and standard C++ only allow _programs_ to be
created, and in that perspective it really boils down to QOI.

and other OS components?

A good part of Windows is, AFAIK, implemented in C++.

 

[Steven T. Hatton]

* Steven T. Hatton:

C is, and C++ incorporates essentially all of C while
adding little or no overhead, and much better abstraction. But
that assumes a reasonable interpretation of the question. The
reasonable interpretation: we're talking about specific implementations
that provide the necessary functionality (types, linkage, and so on),
because standard C and standard C++ only allow _programs_ to be
created, and in that perspective it really boils down to QOI.

It's conceivable that a compiler built strictly for C might use different
strategies more suited to low-level programs than a C++ compiler. But the
question of using C verses C++ is really a question of whether the C++
specific parts of C++ are useful or harmful in implementing low-level
components.

Another example I could have mentioned is sun's implementation of Java.
Much of that code is written in C. That is, it would compile with C
compiler.

A good part of Windows is, AFAIK, implemented in C++.

Windows NT started out being written in C with special OO constructs. Where
it's gone since, I don't know. As to whether Windows is an example of the
right way to do things, that is a mater of opinion.

 

[benben]

A good part of Windows is, AFAIK, implemented in C++.

I would say only Windows GDI, GDI+, and COM related portions (OLE, MTS,
DCOM, etc) are written in C++. Although, they use the same compiler for both
C and C++ source.

ben

 

[Phlip]

DBus, OpenSSH, the Linux kernel, OpenGL, Emacs (first implemented in C by
James Gosling).

They lack a good C++ compiler. The authors of those systems started before
C++ had grown up and standardized. And we still don't have a
standards-compliant compiler.

The answer to your Subject line is that C++ is always better for small
projects with small markets, because when you use the Standard Library
correctly (and a little Boost) you can write code that looks just like it
was written in a Very High Level Language.

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.

Linus likes to know what opcodes he's getting. But I don't see Bjarne with a
gun to his head forcing him to use those language features.

C++, ultimately, is nothing but C with the ability to call statically typed
virtual functions. If you don't need all the extra syntactic sugar and
exception-handling salt, you are free not to use them.

So Linus's argument is just "lack of a good C++ compiler".

A good counter example here is an ORB, such as COM/ActiveX. MS maps
published object methods onto their implementation of the C++ vtable system.
Because MS knows what opcodes they are getting (and because C++ provides
vtables robustly in a way that hides the fragile details), we have an aspect
of C++ pushed down to the kernel level. (ActiveX is indeed bloatware, but
you don't need to use all the extra stuff if you don't want it. IUnknown and
IDispatch are enough...)

So in between snarling and foaming at the mouth, Linus needs to confess how
ORBs on Linux typically work...

Is C++ a good language for writing device drivers and other OS components?

Those in love with C are really enamored of portable assembly. They like
knowing what opcodes they get at each juncture.

C++ has a different set of tricks and traps, but fundamentally it's also
portable assembly.