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

jacob navia said:

Richard Heathfield a écrit :
And any design decision can be called a bug. For example, the whole of
lcc-win32 can be called a bug. So what? The fact that you can abuse
null-terminated strings doesn't mean that null-terminated strings are a
language blemish. You can abuse anything if you try hard enough.


I am not even talking about abuse. I am talking about
1) Error prone unbounded memory scans.

If you don't bound the scan, that's your problem, not C's problem. C
explicitly says that you're not supposed to do that. If you do it anyway,
the behaviour is undefined. So - Don't Do That.

2) Inefficient scanning AGAIN and AGAIN the whole string
to know the length.

If you need to know the length often enough, store it. If you don't, why
bother?

3) Memory overflows when copying.

If you don't provide sufficient storage for the target of a copy, that's
your problem, not C's problem. C explicitly says that you're not supposed
to do that. If you do it anyway, the behaviour is undefined. So - Don't Do
That.

Say, you have a buffer of 80 chars and you want to copy
a string into it. You have to scan the whole string first
to see if it fits!

When you built the string in the first place, you knew its length (if you
did it properly). Don't forget.

OR

At each character you have to test if it fits
or you have reached the terminating zero.

Inefficient.

If this is truly the program's bottleneck, which it almost certainly isn't,
then consider caching the length and using memcpy, or simply use a
third-party string library if you prefer. C's flexibility allows you to do
this, which is a Good Thing, yes?

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 [...] prints:
sizeof array is: 4

The ignorance of
the newbie is not the best yardstick for whether language features are a
good idea or not.


Excuse me but not only newbies.

Okay, I will accept that we should also include amongst the ignorant those
who are unwilling to learn the language properly before using it.

Nobody cares to understand this
crazy "decay",

Here are two dozen counterexamples: I understand it. Chris Torek understands
it. *** Winter understands it. Dan Pop understands it. Kaz Kylheku
understands it. Dennis Ritchie understands it. Brian Kernighan understands
it. Ken Thompson understands it. P J Plauger understands it. Stefan Wilms
understands it. Lawrence Kirby understands it. Keith Thompson understands
it. Dann Corbit understands it. Ben Pfaff understands it. Peter Seebach
understands it. Doug Gwyn understands it. Eric Sosman understands it. Dave
Thompson understands it. Chuck Falconer understands it. Steve Summit
understands it. Richard Bos understands it. Mark McIntyre understands it.
Christian Bau understands it. Clive Feather understands it.

And I have listed only a tiny fraction of those people who understand the
"decay" under discussion. So "nobody" is a bit of an exaggeration, isn't
it?

and the other sophistications of when arrays are
arrays and when arrays are just pointers, so everybody
but the very few language experts says:

Arrays are always arrays. Pointers are always pointers. The name of an
array, however, is converted into a pointer to the array's first element
when used in an expression that is not the operand of sizeof or the &
operator.

Arrays do not exist in C, only pointers, since arrays do not
survive function boundaries.

Arrays survive function boundaries just fine.

#include <stdio.h>

int main(void)
{
char s[] = "Now is the time to party.";
puts(s); /* function boundary */
printf("%lu\n", (unsigned long)sizeof s); /* prints 26 - the
array has survived! */
return 0;
}

My example proves that it is impossible to pass array
size information to a function but you have to pass
it separatedly...

Passing it separately still counts as passing it, so how is it impossible to
pass array size information to a function?

Ahhh. OF COURSE. Arrays "decay". This is a C only concept.


Not true. It's also true, for example, in C++.


This was inherited from C, and you know that.

Had you known that, you would not have made your incorrect claim - or do you
deliberately make incorrect claims?

<snip>

And this needs surely a lot of convoluted explanations
as the countless C-FAQ prove.


No, it's all perfectly straightforward, and is explained very clearly in
K&R2. Anyone with the nous to read that is not going to struggle for
long.


Yes yes. All is OK, very simple.

Good, so what's your problem?

Then tell me:

How do you pass the array size information to a function
that will operate in an array?

See fgets for an example.

You must pass it separatedly isn't it?

Yes; you can't pass it *with* the array because you can't pass the array,
because C is pass-by-value and evaluating an array yields a pointer.

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.



Exactly. "It isn't always "conveyed" " as you say. I wasn't saying
anything else.

Yes, you were. You said the size information is destroyed. You were wrong.
It is not destroyed at all.

That is the bug precisely.

No, it's not a bug. This was a conscious design choice by dmr. You might
think it was a poor choice. You might even think it is a blemish on the
language. But to call it a bug is to misuse the term.

It is impossible
to pass that information to a function and use an array as
an object and not as a pointer!

Yes, well done - you can't pass an array to a function. Do you understand
that now? (Well, actually you can, but only as a subobject within an
aggregate type such as a struct or union.)

The expression's value is passed. Before that value is passed, it has to
be calculated.

GREAT!

I did n,ot knew that. Really new stuff here :-)

It figures. It might be a good idea for you to learn the language before you
start making sweeping criticisms of it.

In your example, the value of the expression consisting solely
of the name of the poorly-named 'array' array is the address of the first
element of the array, and that element's address is passed by value, its
type being pointer-to-int.

Well this is precisely the bug.

No, it's not a bug. It's a deliberate design decision that you don't like.

Why when I define

struct tagArray { int array[2765];};

struct tagArray array;

Now, when I write

fn(array);

no "decaying" happens.

Correct. Whether that's a good thing or a bad thing is a matter for debate,
but you are at least correct for a change.

Ahh, great. At least *some* things work!

The whole language works.

No bugs so far.

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

Right.

Yes, another one of this FEATURES...

Yes. And for the record, trigraphs make perfect sense in some environments.
If you don't like them, don't use them.

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.

I would claim no such thing. I would, however, claim that tracking such
things down is not nearly as difficult as you imagine.

Ahh, and all those packages like "Purify" and all those malloc/free
debuggers are sold by the thousands because.... well, because people
are lazy and stupid and do not follow your propositions obviously.

That's one way to track down such bugs, albeit a rather expensive way to
deal with a fairly simple problem. I do not accept that those who use
Purify are lazy or stupid, although I do not use it myself.


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

You have not demonstrated your case. You have, however, provided some
evidence for eschewing multi-threading, which is non-standard in any case
and, as you say, enormously increases the complexity of an application
for no real benefit.


Obvious. Multi-threading is not good for malloc/free then...

You have not demonstrated that.

instead of
getting rid of multi-threading let's get rid of malloc/free!

You have not demonstrated that this is a wise idea.

More and more applications are designed with multi-threading in mind.

That doesn't mean multi-threading is necessarily a wise idea. Indeed, in
most cases where I've encountered it, it was a very silly idea. (That does
not mean that multi-threading is a silly idea. It only means precisely what
it says.)

Even the hardware is now multi-threaded with several "cores".

But let's keep living in the past...

I'd rather live with the facts. So far, you haven't presented any that would
convince me that you know what you're talking about.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
.