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

Richard Heathfield a écrit :
jacob navia said:


Richard Heathfield a écrit :

jacob navia said:

<snip>

it is not
very difficult to find problems with the approach in C to many things,
since the bugs in the language aren't that difficult to find.


Do you have at least two examples that will stand up to close scrutiny?


Well, I hope we can start a constructive discussion, instead of
flame wars.


When you start talking about "bugs in the language", you're not trying to start a constructive discussion - you're trying to start a flame war. Nevertheless, if you can find some serious bugs in the language, that's important enough to merit serious and indeed constructive discussion. But if you're just being silly, well, that's just silliness. Let's find out which it is, shall we?


The most glaring bugs in C are:

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.

<snip>


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.


Arrays in C are completely
screwed up. There is endless confusion between pointers and
arrays specially because the size information is destroyed across
function calls.


No, array information is never destroyed. It isn't always *conveyed*, but it is never destroyed except when the array is destroyed.


Yes of course, since when I pass the array in the program above
it is just not passed as an array, even if C has pass by value
semantics...

Then pedantic people will say that all is well since if the arrays
aren't passed as arrays but as pointers by definition, the sizeof
still works ok.

But everyone else understands that in the above example function "fn"

No bugs so far.


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


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. 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...)


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!!!


And arrays are not pointers, so you can't get rid of "arrays as pointers".


Yeah, of course I can. Look at lcc-win32.


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.

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 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...


We have
discussed this here several times.


Yes. 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???


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...



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.


The solution is to use an automatic
software component (garbage collector) that manages the release of the
allocated memory.


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


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.


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.
.

Quantcast