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

On Wed, 27 Dec 2006 11:33:35 -0600, jacob navia wrote
(in article <4592ae70$0$27377$ba4acef3@xxxxxxxxxxxxxx>):

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 as a programmer don't make sure your strings are properly
formed, you will have problems. If your algorithm is not properly
formed, you will also have problems. Why is this confusing?

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

That's a design flaw. If you have a program where that time is an
issue, design your code to mitigate the problem. This is not
difficult.

3) Memory overflows when copying.

Only when not copying properly. Are there artifacts in the standard
library that make this a dangerous path for the uninitiated?
Absolutely. Are they impossible to avoid? Not at all.

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!

No, you do not /have/ to do that. You /may/ need to do that if you
didn't write code to solve the problem before you go there.

OR

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

Inefficient.

Yes, the methods you propose to use are inefficient. Why is that not
surprising me?

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. Nobody cares to understand this
crazy "decay", 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 do not exist in C, only pointers, since arrays do not
survive function boundaries.

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

You are confused. If you can pass it to the function, /in any way/
then it is not impossible to pass it. You contradict yourself. I know
what you meant though. You can't pass it the way you want to pass it.
Tough. Get used to it, or find a language that works the way you like.
Just don't call that other language "C", or try to convince people
comfortable with C that your way is the only way and you won't have
anything to argue about.

Exactly. "It isn't always "conveyed" " as you say. I wasn't saying
anything else. That is the bug precisely. It is impossible
to pass that information to a function and use an array as
an object and not as a pointer!

You use the word "impossible" far too often, and far too improperly.

If it were impossible to handle arrays in C, the language would have
died before you were born. Clearly the problem has known solutions.

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.

It's crazy just how close to right you landed on that one. Even a
stopped clock is right twice a day....

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.

Here I have to disagree with Richard. It does offer real benefits in
some problem domains. That they may not be encountered often in
Richard's travels I won't dispute. But, such cases do exist. There
are ways other than threads to solve those problems also, but typically
they are even more difficult. Multithreaded programming is not /easy/,
therefore it is not surprising that Navia doesn't like it. He has
repeatedly come down on the side of "easy" over "efficient".

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

False. It works fine when correctly done.

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

There is no multi-threading to get rid of in the terms of this
discussion, since it is about C. The real C, not the pseudo-C you are
so fond of.

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

That is in fact the problem. "Designed with X in mind" is a sure
warning sign that X isn't correctly done at all. Luckily, more and
more applications are designed and built with working thread solutions.
"Designed with X in mind" typically means: "I heard about this thing X
and my sadly, my boss has too. He is worried about it impacting the
size of his empire. I spent 20 minutes googling for X, and wrote in
the Executive Summary of my design document that the design has X in
mind, so now everybody is happy, and I'll be long gone before anyone
figures out the difference."



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





.

Relevant Pages

  • comments on my design of a new language?
    ... I have been working on designing a dream language off and on for some ... strings can be interpreted as variables by enclosing them in braces. ... multidimensional) arrays of literals. ...
    (comp.lang.misc)
  • Re: Compiler and an interpreter
    ... >> available short-term memory and ruin productivity. ... > It's not the language, ... > the design, and the lower levels are exactly what the design needs. ... The arrays sit together in a struct. ...
    (comp.programming)
  • Re: comments on my design of a new language?
    ... >I have been working on designing a dream language off and on for some ... > little feedback about my design. ... > multidimensional) arrays of literals. ... > accessed with dot syntax if they are named according to standard ...
    (comp.lang.misc)
  • Re: c / c++ : is it end of era ?
    ... jn> "C strings are a design decision". ... jn> I am just saying that they were a BAD design decision. ... When Brad Cox didn't like some of the limitations of C, ... If you want a language remarkably like C, ...
    (comp.lang.c)
  • Re: why cant functions return arrays
    ... for such a language restricton. ... in the opinion of the very opinionated Jacob Navia. ... have been able to pass and return fixed-size arrays by value by ... language" is a mistake in design or not is an open issue. ...
    (comp.lang.c)