Re: c / c++ : is it end of era ?
- From: Richard Heathfield <rjh@xxxxxxxxxxxxxxx>
- Date: Wed, 27 Dec 2006 00:22:18 +0000
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.
<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.
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.
No bugs so far.
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.
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. And arrays are not pointers, so you can't get rid of "arrays
as pointers".
Another big problem is the error-prone malloc/free combination.
Why is that error-prone?
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. What could be easier? How is this
"error-prone"? You have never satisfactorily answered this.
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.
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 you have mentioned so far
constitutes a "bug" in C.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
.
- Follow-Ups:
- Re: c / c++ : is it end of era ?
- From: jacob navia
- Re: c / c++ : is it end of era ?
- From: jacob navia
- Re: c / c++ : is it end of era ?
- References:
- c / c++ : is it end of era ?
- From: shaanxxx
- Re: c / c++ : is it end of era ?
- From: jacob navia
- Re: c / c++ : is it end of era ?
- From: Richard Heathfield
- Re: c / c++ : is it end of era ?
- From: jacob navia
- c / c++ : is it end of era ?
- Prev by Date: Re: c / c++ : is it end of era ?
- Next by Date: Re: size of pointers
- Previous by thread: Re: c / c++ : is it end of era ?
- Next by thread: Re: c / c++ : is it end of era ?
- Index(es):
Relevant Pages
|
