Can anyone recomend a good intoduction to C...

Alex Martelli aleaxit at yahoo.com
Wed Mar 7 05:25:46 EST 2001


"Werner Schiendl" <ws-news at gmx.at> wrote in message
news:983916572.286918 at newsmaster-04.atnet.at...
> > C++ is far more complex that C without being much safer.  Since
> > the safety has to be "inspected" into the program, you want
> > to make things as easy to inspect as possible: a nice simple
> > language.
>
> That is of course a point, if you need to let the program inspect you will
> try to keep it as simple as possible.
> But given the same functionality, I think a C++ program will not be more
> complex.

The program will not be, the language is.  It's a hard-to-judge tradeoff.

> ...as long as it is well designed of course, nobody forces you to use any
> number of features at all possible
>
> don't you think so?

I do not: C++ *forces* "any number of features" on you -- you can't
easily subset it and ENSURE features outside of the subset are not
intruding.

> Think about string operations: I think about 50 % of all security issues I
> read about are somehow related with a (string) buffer overflow. The string
> family of classes does not have that kind of problem.

No, but it does have other issues -- e.g.,
    std::string oneletter('A', 1);
does NOT do what one might expect, nor does it give any warning
in the implementations I have at hand (oneletter becomes a string
of 65 characters all equal to '\001', not one of 1 character
equal to 'A' -- oops, arguments the wrong way around...!-).

The trade-off is no doubt a win for std::string here -- it
removes many more issues than it introduces.  But it's not
so clear overall -- considering that you can't subset, not
really.  I think that C++ (used properly, particularly with
STRONG reliance on GOOD libraries) is a definite net win
over C, but I can well see somebody might disagree, most
particularly when security-crucial applications are being
targeted.  (If I _could_ throw a switch to subset C++,
_ensuring_ at least warnings for a zillion potential errors
and complexities, the picture would of course change).


Alex






More information about the Python-list mailing list