learning C

[Alex Martelli]

"Steve Holden" <sholden at holdenweb.com> wrote in message
news:j6kr6.68748$ML1.3282888 at e420r-atl2.usenetserver.com...
    [snip]
> > > This is nothing more difficult than in C.
> >
> > Sorry but it is. There's just so much less lurking under
> > the hood in C.
> >
> But by this argument, assembly code is even better!  It's always a
question
> of selecting language features because they are appropriate to your
problem
> domain.

Like with political parties, you can't really pick and choose
features with programming languages -- they come as a package.

C++ is a very big package, which IS the essential problem with
it -- and you can't really subset it effectively.  Its designer
chose very challenging design-goals, and managed to meet them,
but simplicity and linearity of the resulting language was not
compatible with the large set of goals.

Modern-day assembly language also has a lot "lurking", for very
different detailed reasons (although the need to get 100% of the
potential performance is a "common-mode factor" to the complexity
of both today's machine-code and C++:-).  But, mostly, the issue
there is one of portability -- the finely tuned code you write
today will be badly mistuned (if it even works at all) tomorrow,
or even this afternoon if you need to run it on another box.  But
this is really a red-herring, and I think you know it -- maybe
mentioning assembly in a discussion of programming languages should
be considered to apply a variant of Godwin's rule...!-)

"A simple and easily predictable semantic model"; "potential for
100% machine-speed exploitation"; "convenient high-level usage";
pick any two.  C gives you 1 and 2, but definitely not 3; C++
gives you 2 and 3, but definitely not 1; Python gives you 1 and
3, but definitely not 2.  The choice among them will depend on
the relative importance of the three desirable goals.

In _most_ cases, programmer productivity is paramount, speed of
the resulting code isn't -- which is why Python dominates (or,
rather, _should_ dominate:-), as the two nice things it offers
are both highly conducive to such productivity.  If speed IS a
big issue (e.g., in low-level components, meant to be scripted
by Python of course:-), then one needs to evaluate whether the
convenience of C++, OR the simplicity of C, serves one's goals
best.  My opinion is that, *in security-critical code*, a
language that is too complex (does stuff behind your back,
is prone to buggy compilers, etc) may be too big a minus; that
10% of 10% that is crucial for both speed and security should
thus probably be best coded in C.  When security is not that
big an issue (you're worried about errors rather than deliberate
exploits), then the _ability_ of C++ to be used in a safer way
(exceptions, std::vector & std::auto_ptr rather than any use
of explicit memory allocation, etc) makes it a better choice.

But you still can't pick-and-choose feature.  And C++ has so
MANY foot-level tripwires that it almost seems that must have
been one of its design goals... although in fact it's clear
that compatibility with C is what caused most of them.  E.g.,

struct foop {
    foop();
    void flip(int i);
    // some other stuff here
};

void flipthefoops(foop fooparray[], int nFoops)
{
    for(int i=0; i<nFoops; ++i)
        fooparray[i].flip(i*23-42);
}

struct biggerfoop: public foop {
    int addafield;
};

void flip17biggerfoops()
{
    biggerfoop severalfoops[17];
    flipthefoops(severalfoops, 17);
}

and "bang you're dead" -- nor would recoding flipthefoops() in
a style closer to the standard library (with a begin and an end
parameter, rather than begin and number-of-elements) help in
the least.  So, OK, this is just "typical tripwire number 83 in
a cast of thousands" -- "inheritance (extension) and arrays do
NOT play together well", and in this toy case this is quite easy
to see.  But, IS it easy when it happens in a less overt way and
as one tiny part of a complicated software system?  Nope.

I'm still a C++ "paladin" (well... I _do_ consider it the least
of evils in most speed-needed circumstances -- guess that's not
much, as far as language advocacy goes:-) mainly because of the
splendid power that frameworks can give the C++ developer -- the
standard C++ library to start with, ATL if you're into COM, the
Boost Python Library (and all of the rest of Boost)... the lack
of templates (and, secondarily, OO) in C just doesn't let any
C-specific "frameworks" be ANYWHERE close to what is available
for C++.  But don't kid yourself -- it IS going to trip you up
(have LOTS and LOTS and LOTS of unit-tests...!!!-).


Alex