Re: Processes in UNIX

From: G. S. Hayes (sjdevnull_at_yahoo.com)
Date: 10/06/04 

Date: 6 Oct 2004 07:22:40 -0700

opwv_pspl_test2@yahoo.com (K.M Jr) wrote in message news:<8228b1d2.0410052039.29a3e041@posting.google.com>...
> Not comparing PLs but probably you can tell me the reason why still C
> is so popular for systems programming, I ask this because I do
> maintain that C++ is a better C with many more features (probably
> which aren't required for systems programming).

C++ does have many more features. That's the major problem with it,
IMO; as a language (not library), it's absolutely huge; indeed, it's
so large that very few programmers are able to understand the language
fully (it's hard enough to understand C fully). With a lot of C++
features (exceptions, templates, etc) it's hard to guess what sort of
code is going to be generated; some of those (like exceptions) also
incur a nontrivial run-time penalty.

Less problematically, the typing system is stronger in a lot of cases,
but not always in ways that make _practical_ sense (e.g. requiring
casts of void pointers, which does make _theoretical_ sense) and for
some system tasks I've found myself casting weirdly to get around it
(you can't change the types accepted by core Unix calls).

There's also an argument to be made that the Unix interfaces are often
not the same as "the C++ way". e.g. dealing with TCP sockets doesn't
readily lend itself to an iostream approach, with all the
state/blocking/error conditions you need to deal with. That's
unsurprising since the original Unix guys are also the original C
guys.

For whatever reason, in my experience large C projects (even outside
the realm of systems work) I've worked on have been cleaner and easier
to maintain than large C++ projects. That's purely anecdotal, but
it's worth considering that a relatively large number of open-source
software projects (which need to have clean code that many people can
read and contribute to) have come to the same conclusion. It's
theoretically possible to restrict yourself to a subset of C++ and
give yourself a few nice new features, but in practice what the
compiler offers is going to be used by someone, and the set of
features you want for a lot of systems work turns out to be basically
C anyway.

Note that I'm not arguing against higher level languages in general; I
tend to use a _lot_ of Python in my work (often combined with a small
C extension for a performance-critical corner of the problem), and
I'll often implement portions of a system in other domain-appropriate
languages. I've just found that for me, the kind of middle-level C++
offers hasn't worked out all that well in practice--that's not to say
it can't, if your team is well disciplined.

Relevant Pages

  • Re: Back to VB6 and .NET
    ... I'm not knocking VB.NET - but the only reason it has more "new" features ... retranslated back into another .NET language. ... assembly that acts as a translation layer. ...
    (microsoft.public.vb.general.discussion)
  • Re: The status of C
    ... > programming discipline, but good discipline combined with helpful features ... >> Is C still the language of choice for serious programming? ... > often not the primary reason, why a particular tool is or isn't right ...
    (comp.lang.c)
  • Re: C++ --> C#
    ... The reason for this is that C++ as a language has ... many features which do not translate directly to C#. ... Also, the environments ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: The status of C
    ... >Since C is my language of choice for almost any kind of application, ... Working without these features might be a good way to _learn_ better ... often not the primary reason, why a particular tool is or isn't right ... introduces a bug doing it... ...
    (comp.lang.c)
  • Re: Where does C++ fit in?
    ... Which features are you referring to here? ... your opinions must be tempered ... as systems programming language, ...
    (comp.arch.embedded)