Re: c / c++ : is it end of era ?

On Wed, 27 Dec 2006 00:17:46 -0600, jacob navia wrote
(in article <45921009$0$5083$ba4acef3@xxxxxxxxxxxxxx>):
Richard Heathfield a écrit :
1) Zero terminated strings.


That's not a bug. It's a design decision. You might not agree that it's a
good decision, but it's a conscious, deliberate decision nonetheless.

No bugs so far.

Customer: HEY! Your dammed program erased all my data files!
Programmer: Of course. You forgot to read the documentation page 2643
paragraph 76: If the cutomer doesn't check the dialog button
"Do not erase all my data files" in the menu item 8,submenu
26, the program will erase them.

IT IS NOT A BUG! IT IS A FEATURE!

Any bug can be converted to a "design decision", since a design that
is at the root of COUNTLESS buffer overruns, virus attacks, etc, is
obviously correct.

Strawman. These are not equivalent at all. C gives you something
analogous to a Machete. Apparently, you would prefer a machete that is
never sharpened, only available with a special license, and has a hard
clear plastic cover such that it can't cut anything without melting it
off first with a blowtorch.

Some things, in order to serve their design purpose, are inherently
dangerous. That means, the people that use them must be intelligent,
competent in their employment, and not careless if they intend to
survive the usage unharmed. Same is true of cars, airplanes,
chainsaws, even toothpicks.

If you want a super-handholding, ultra-safe language, they are out
there. C is not for amateurs, or those not willing or able to spend
the time to learn where the sharp spots are.

2) Confusion between pointers and arrays.


What confusion? I don't get them confused, and neither does anyone who has
taken the trouble to learn the language.


Of course (see above). This is not a bug, it is a "conscious design
decision". Nevertheless, it is not immediately obvious to anyone outside
the C pros, why

#include <stdio.h>
int array[2765];

void fn(int array[2765])
{
printf("sizeof array is: %d\n",sizeof(array));
}

int main(void)
{
fn(array);
}

This prints:
sizeof array is: 4

Ahhh. OF COURSE. Arrays "decay". This is a C only concept.
And this needs surely a lot of convoluted explanations
as the countless C-FAQ prove.

If you want to fly an airplane, you must first learn how to fly, lest
you crash and die. If you want to program in C, you must first learn
the language, for basically the same reason.

No bugs so far.


Of course. Only "conscious design decisions", like trigraphs...

They served a purpose at the time they were designed in. If you're too
young to understand why, that's not a reason to pretend they were never
needed.

3) From (1) and (2) we obtain as a consequence the inherent
impossibility to make bounds checks when accessing arrays and
strings. This leads to endless bugs.


Since both your premises are false, what hope is there for your conclusion?
But the lack of bounds checking in C does not in fact lead to endless bugs.
What leads to endless bugs is "not knowing what one is doing", and that is
true for any programming language and indeed any engineering discipline.


Of course.

C programmers never have bugs, since, if someone has a bug, it is not
"knowing what he is doing", hence he is not a C programmer.

No. It's far more simpler. If you have a bug in a program that is due
to faulty logic, algorithms, or even a typo, that's a bug, and C can
have them quite often. You can be a very competent programmer and very
knowledgeable of C and still make mistakes. Perfection is not often
attained.

OTOH, if you have a bug due to you as a programmer directly violating
the rules of the language itself, that is not the fault of the
language. That is not knowing what you're doing.

Obviously
only Mr Heathfield qualifies as a C programmer then (maybe with the
company of Mr Dan Pop, that also told me that he never had a bug...)

Did you actually believe Dan? rofl

The fix is proposed in lcc-win32: a few improvements to the language and
we can get rid of zero terminated strings and arrays as pointers.


Getting rid of zero-terminated strings is not a fix or an improvement.
Removing choice is not the best way to persuade a C programmer that you're
on his side.

Who told you that C strings aren't supported? They are supported OF
COURSE.

What I do is to give programmers the choice PRECISELY. The can now
choose between C strings or the String library. In YOUR world there is
NO OTHER CHOICE but C strings!!!

You give navia-C programmers a choice. You do not give standard C
programmers a choice. IIRC, the bstring library (name??) written by
Hsieh gives much the same (if not better) functionality, but without
requiring the compiler to do nonstandard things to get there. A /far/
better approach imo.

Another big problem is the error-prone malloc/free combination.


Why is that error-prone?


Because humans are not machines, and the human circuit (i.e. the brain)
is not a computer, but a vastly more complicated circuit than any
computer in existence.

Such a circuit is able to build circuits (something computers
aren't able to do) and is able to program computers (also
something computers aren't able to do) but it is ERROR PRONE, i.e.
due to the way the brain ciruitry works, it is not able to reproduce
a lot of mechanical acts without sometimes FAILING.

If I tell you to add thousands of digits thousands of times
you WILL make a mistake, even if you are an expert.

That same "brain circuitry" makes mistakes in super-safe,
super-handholding, super-slow languages too. In fact, waiting on
programs written in them to simply complete has been known to cause
programmers to fall asleep too often. 9 out of 10 doctors agree.

If I ask you to keep track of thousands and thousands of memory areas
and never make a mistake when releasing the allocated memory you
WILL make a mistake even if you claim here that it will never
happen to you.

The question is, is the performance and/or memory footprint advantages
of the C approach worth a little bit of extra debugging to achieve a
satisfactory result, or would you rather do it some other way, and take
the tradeoffs implied? That's why there are other languages to choose
from. It's also why you can buy a hybrid car with 15 different airbags
and roll bars, or you can buy a Ferrari F1 car. They achieve different
things, and require a dramatically different amount of skill to use
them effectively.

The problemof malloc/free is that it is not scalable. You can get away
with it in small systems, and in single threaded applications.

In a multi-threaded complex application, where there are thousands or
millions of allocated pieces of memory it is another, completely
different story...

I've been writing multi-threaded programs (not in standard C of course,
since it doesn't have them) in both large and small-scale applications
for many years. malloc/free work fine. Did you have a point
applicable to standard C?


When you want memory, you ask for it, and if possible you'll get it.
And when you're done, you give it back.

How do you know when you are done?
That is precisely the question. You have to know exactly when each piece
of memory is needed, and when not. Since it is SO EASY to make an alias
in C, how do you know that in all that complex code there isn't an
alias for this piece of memory???

You first must be knowledgeable of the language, knowledgeable of the
code, have a good design, follow good practices, good documentation,
and have some form of suitable verification, code review and test
procedures. hint: I wouldn't expect someone with very little real
world application development experience to get this right. It is
hard. Just about anything worth doing is difficult.

What could be easier?

Easier would be:
"When you want memory, you ask for it, and if possible you'll get it.
The system will detect when you are done with it and
release it."

That IS easier...

If you want an /easy/ language, you are in the wrong place. Not
everything /easy/ is /correct/ for the job at hand. There are places
where other languages have merit, and there are places where C has
merit, and it is not important that any one language be good at them
all.

How is this
"error-prone"? You have never satisfactorily answered this.


I can't answer it for you since you claim never to do a mistake...
For all other people however, the reasoning is obvious.

Actually, the "reasoning" seems to be "If I have trouble with it, then
everyone must have trouble with it. Anyone that doesn't have trouble
with it ticks me off."

Memory management is too important to be left in the hands of the system.

Nobody takes memory management from you. Just the finding of unused
memory is taken from you. It is still the programmer that allocates
memory. This is like saying that an automatic car doesn't let the driver
drive the car...

Nonsense

Actually, if you've driven both manual and automatic transmissions
(well), then you wouldn't choose that analogy at all, as it does not
help your argument.

Note that the objective here is not just to say what is wrong but to
propose solutions.


Let me know when you find something wrong.

Nothing is wrong Heathfield. For programmers like you that never
make mistakes nothing is wrong. I am speaking for the other ones
like me that DO make mistakes.

I know of no language that will protect a mistake-prone programmer from
themselves. NONE. With or without garbage collection assistance, or
pointers removed, or arrays conveying extra information across function
calls, you will still make mistakes. Just different ones. What you
will not get though, is better performance and/or a smaller footprint
in all but the most trivial of examples. It's an implementation
decision. I haven't seen anyone say that you should use C for all
problems, and more importantly, for programmers of all skillsets.

Nothing you have mentioned so far
constitutes a "bug" in C.



There isn't a blinder man than the one that doesn't want to see.

Ironically, I couldn't agree more.



--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





.