By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,437 Members | 1,337 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,437 IT Pros & Developers. It's quick & easy.

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

P: n/a
I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.

I just wanted to know what other people thinks on this .

Dec 26 '06 #1
Share this Question
Share on Google+
167 Replies


P: n/a
shaanxxx a écrit :
I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.

I just wanted to know what other people thinks on this .
C++ started to eliminate C pitfalls but did not know when to stop,
in the way of complexity.

The problem with C is the lack of higher level constructs
that would allow a simpler and bug-free programming.

C++ started out as a preprocessor that compiled to C, that allowed
people to define classes, do object oriented programming, and
in general, as a way of eliminating the problems of C by
adding a new paradigm (object oriented programming) and
by making stricter type checking.

This led to multiple inheritance (one of the first mistakes), and
then templates, name spaces, and an incredible array of features
that make C++ a language so complex that has been almost impossible for
the compilers to follow.

As it stands now, there are maybe one or two implementations (EDG mainly
and maybe Comeau) that implement ALL of the language. All the other
compilers (gcc and microsoft included) implement some large subset of
the language, but not all of it.

People that understand the whole language are very few, since the
learning curve is steep, and unforgiving.

Obviously a language that started to "fix C" or to make a
"better C" is obviously in need of a reason, and 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.

C++ has added complexity without really having solved many of
the problems of C. Still you have to allocate/deallocate manually
the memory you want to use, without having an automatic garbage
collector, for instance.

In my opinion, some of the features of C++ are interesting, and
worthwhile, but too many of them make for a language that is just too
big.

jacob
Dec 26 '06 #2

P: n/a

shaanxxx wrote:
I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.

I just wanted to know what other people thinks on this .
Has COBOL gone away?
No. This kludgy 1950 language still clings on because it has a huge
installed base and actually solves some problems better than other
languages (e.g. look at some recent threads here involving currency
transactions which COBOL can handle with aplomb).

Languages do not go obsolete once they get popular. The problem domain
for C and C++ is not identical. For some projects C++ will be better
and for some projects C will be better.

Also important is the resources available for projects. If you have 50
good C programmers and 3 good C++ programmers, then most of your
projects will be C projects because that is what you can maintain.

People frequently prophecise about the demise of various popular
computer languages. They are always wrong.

Dec 26 '06 #3

P: n/a
On 2006-12-26, shaanxxx <sh******@yahoo.comwrote:
I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
C is still very widely used, including for new projects.

Most people with any sense realize both that C++ does not necessarily
mean OOP, and that OOP is not a "silver bullet" anyway.

Out of people who know and understand quite well both languages, many
prefer C++ and many prefer C.

Most programmers have horror stories about bad code in both languages to
while away the long winter evenings.
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
They're not exactly impartial gurus though.
Dec 26 '06 #4

P: n/a
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?

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

P: n/a
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.

The most glaring bugs in C are:

1) Zero terminated strings. This is the source of countless problems,
because each access to a string implies an unbounded search for
the terminating zero, and becasue size information is not stored
explicitely in the string but must be reconstructed, so that
buffer overflows when copying those strings are almost inevitable.

Bounded strings can be written in C like this:

typedef struct tagString {
size_t length;
char *data;
unsigned flags;
} String;

Those are resizable strings. Non-resizable can be described
like this
typedef struct tagFixedString {
size_t length;
int flags;
char data[];
} FixedString;

I give this definitions to block people that say that
using other types of strings is impossible in C.
In the lcc-win32 compiler system, those strings are supported
in a special library.

2) Confusion between pointers and arrays. 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.

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

Another big problem is the error-prone malloc/free combination. We have
discussed this here several times. The solution is to use an automatic
software component (garbage collector) that manages the release of the
allocated memory. Lcc-win32 proposes this in its standard distribution.

Note that the objective here is not just to say what is wrong but to
propose solutions. That is why I mention lcc-win32, that is free anyway,
so I have no financial gain from it.

jacob
Dec 26 '06 #6

P: n/a

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:_I******************************@bt.com...
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?
It depends what you mean by bugs. C has a lot of weaknesses that are
inherent in a portable assembler: no special error-handling mechanism, no
garbage collection, to array bound guarding. None of this could be chnaged
with altering the design premises of the language, except maybe
error-handling, and even then no-one has found a good way that doesn't
involve hidden control paths.

There are a few other niggly things which could have been better. A few,
like the use of "char" for "byte" are simple details. Others, like the
syntax for multi-dimensional arrays, are a bit more deep-rooted. others,
like the typedef problem, are debateable. Most typedefs are a bad idea, but
there are a few cases where they actually help code maintainability.
Personally I would remove the keyword from the language if I was redesigning
C from scratch, but it is too late now, and that kind of knowledge only
comes from long experience.

Then there are some omissions. No distinction between functions which
perform IO and those which don't, no distinction between functions dependent
on platform-specific libraries and portable ones. I wouldn't describe these
exactly as "bugs".
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

Dec 26 '06 #7

P: n/a
Malcolm wrote:
like the typedef problem, are debateable.
What's the typedef problem?
I don't like their syntax, but I think it's just a matter of taste...
Most typedefs are a bad idea, but
there are a few cases where they actually help code maintainability.
Personally I would remove the keyword from the language if I was redesigning
C from scratch, but it is too late now, and that kind of knowledge only
comes from long experience.
I don't see the problem with a keyword that makes an alias to a type
(usually to a complex one)... If there wasn't typedefs, how would you
"export"[1] a type in a header?

[1] - It not really export, because exporting involves some kind of
linkage, isn't it?

JJ
Dec 27 '06 #8

P: n/a
mg
shaanxxx napisal(a):
I started programming with c. Lot of projects are being done in C++. We
I drow an interesting analogy to difference between C and C++. It's
like difference between european alphabet and japanese "alphabet". C++
it's great because when we want to write a word we only write one sign
so programs are shorter and easier to write. Of course we can say that
C is great because ...

C and C++ are different philosophies.

Dec 27 '06 #9

P: n/a
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.
Dec 27 '06 #10

P: n/a
jacob navia wrote:
>
C++ started to eliminate C pitfalls but did not know when to stop,
in the way of complexity.

The problem with C is the lack of higher level constructs
that would allow a simpler and bug-free programming.

C++ started out as a preprocessor that compiled to C, that allowed
people to define classes, do object oriented programming, and
in general, as a way of eliminating the problems of C by
adding a new paradigm (object oriented programming) and
by making stricter type checking.
OK so far.
This led to multiple inheritance (one of the first mistakes), and
then templates, name spaces, and an incredible array of features
that make C++ a language so complex that has been almost impossible for
the compilers to follow.
Debatable.
As it stands now, there are maybe one or two implementations (EDG mainly
and maybe Comeau) that implement ALL of the language. All the other
compilers (gcc and microsoft included) implement some large subset of
the language, but not all of it.
I know of at least one other, which makes for several more "complete"
C++ implementations than there are C99 ones.
C++ has added complexity without really having solved many of
the problems of C. Still you have to allocate/deallocate manually
the memory you want to use, without having an automatic garbage
collector, for instance.
The RAII (Resource Acquisition Is Initialisation) paradigm solves that
problem. This topic as been done to death both here and down the hall.
In my opinion, some of the features of C++ are interesting, and
worthwhile, but too many of them make for a language that is just too
big.
You don't have to use them all, just the features that make for a better C.

--
Ian Collins.
Dec 27 '06 #11

P: n/a
shaanxxx <sh******@yahoo.comwrote:
I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.

I just wanted to know what other people thinks on this .
Just as poets find new and inventive ways to make antiquated languages sing with beauty,
so can a programmer by sticking with a language as elegant as C.

A good friend of mine had a BASH script he used which would run on average over 20 minutes.

As a programming practice in C (to freshen my skills) - remade the program

And it completed on average over 2 seconds....

From 20 minutes to 2 seconds... C's efficiency combined with the power left to the programmer

will always make it a favorite for years to come. It's just simply fun.

Dec 27 '06 #12

P: n/a
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.
Dec 27 '06 #13

P: n/a
Malcolm a écrit :
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:_I******************************@bt.com...
>>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?

It depends what you mean by bugs. C has a lot of weaknesses that are
inherent in a portable assembler: no special error-handling mechanism, no
garbage collection, to array bound guarding. None of this could be chnaged
with altering the design premises of the language, except maybe
error-handling, and even then no-one has found a good way that doesn't
involve hidden control paths.
With just one change to the language (operator overloading)
I have been able to develop an experimental compiler
that eliminates some of those problems.

The operator overloading allows lcc-win32 to use containers
(accessed with the array notation [ ] ) and with that have
arrays and strings that are bound checked.

Lcc-win32 offers a garbage collector in its standard distribution.
Dec 27 '06 #14

P: n/a
Richard Heathfield a écrit :
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.
This is precisely what I do not accept.

Why being blind to the flaws of the language?

"C, is MY language. Take it or leave it!!!"

?????

Why isn't possible to discuss the flaws of the language
without flame wars?

I remember the starting days of Unix, where EVERY
manual page had a BUGS section. Has this attitude got
lost in this "language nationalism" ???

jacob
Dec 27 '06 #15

P: n/a
jacob navia said:
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.
<snip>
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.
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.
>>>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
Nor is it immediately obvious to a newbie guitarist that guitar music is
written an octave high. I once knew a newbie guitarist who had broken
dozens of strings because of this, and yet he remained convinced that he
had to pitch his strings in such a way that he could play the music as
written. It took a long time to convince him otherwise. The ignorance of
the newbie is not the best yardstick for whether language features are a
good idea or not.
Ahhh. OF COURSE. Arrays "decay". This is a C only concept.
Not true. It's also true, for example, in C++.
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.
>> 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...
The expression's value is passed. Before that value is passed, it has to be
calculated. 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. That your poorly-prototyped function doesn't
make it clear that it is receiving a pointer-to-int because it uses ancient
syntax, does not change the fact that what is being passed and received is
a pointer.
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.
The array isn't passed at all! What is passed is an expression's value.
But everyone else understands that in the above example function "fn"
The example function was poorly written, and does not serve as a good
example.
>
>No bugs so far.

Of course. Only "conscious design decisions", like trigraphs...
Right.
>
>>
>>>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.
More usefully, if one's program has a bug, it means that the programmer does
not understand his program. (This may be because he doesn't understand the
rules of the language, or it may not.) The way to get rid of the bug, then,
is not to change the program or the language, but to increase the
programmer's understanding of his program. Once he understands it fully, he
will see why it does not do what he intends.
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...)
See above. Anyway, I doubt very much whether Mr Pop would have told you
that. He's far too sensible.
>>>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.
So you're getting rid of them *and* supporting them? What colour is the sky
on your planet?
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!!!
Sure there is. If you don't like C strings, there are lots of string
libraries out there, all with varying designs, performance characteristics,
etc. Lots of choice. Me? I use one I wrote myself. Why? Because I know I
can move it around the place. What I can't do is write a program that uses
lcc-win32-only features and *guarantee* that I can move that program to
another computer (say, for example, the S2/NX) and still have it work,
straight out of the box, on that machine's native conforming C compiler.

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

Yeah, of course I can.
No, you can't. This is very, very simple.

Arrays are not pointers.
Therefore there is no "arrays are pointers" feature.
Therefore you can't have got rid of such a feature.

The absence of such a feature does not mean you have got rid of it. It can
mean that the feature never existed in the first place, and that's what it
means here.
Look at lcc-win32.
Your utter inability to understand simple logic does not make a good
advertisement for your product.

>>>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.
This does not explain why malloc/free is error-prone.
>
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.
This, again, does not explain why malloc/free is error-prone.
If I tell you to add thousands of digits thousands of times
you WILL make a mistake, even if you are an expert.
So what? If I tell you to write int main(void) by hand thousands of times
you WILL make a mistake, even if you are an expert. That does not mean int
main(void) is error-prone.
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.

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.
>>>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?
When you've given back the last piece that you received.
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???
Because I understand the program, either because I wrote it or because I've
taken the well-remunerated time to study it long and hard.
>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...
Slower, too. And unpredictable. And not portable.
>

>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...
I don't recall saying any such thing, ever. Please cite the message ID to
which you refer.
For all other people however, the reasoning is obvious.
I make mistakes just like anyone else, and that includes sometimes
forgetting to release memory that I allocated. Unlike you, however, I don't
see this as being a huge problem, because it's easy to detect and easy to
fix.
>>>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.
That's a contradiction in terms. Memory management includes deciding when to
release a memory resource.
It is still the programmer that allocates
memory. This is like saying that an automatic car doesn't let the driver
drive the car...
No, it's like saying an automatic doesn't allow the driver to manage the
gear-changing process as effectively, which is why many racing drivers
prefer manual gearboxes even though automatic transmission in racing cars
is far superior to that in works cars.
>>>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.
Fine, so what's all the fuss?
For programmers like you that never make mistakes nothing is wrong.
Oh, but I do make mistakes. So what?
I am speaking for the other ones like me that DO make mistakes.
The kind of mistakes you're talking about are trivial and easy to correct.
The kind of mistakes you *make* (in Usenet articles) are also trivial and
easy to correct, but unfortunately this involves knowledge and experience
of the C language and a mastery of elementary logic which your articles do
not demonstrate that you possess.
>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.
Okay, do you want to see? Here we go:

Null-terminated strings were a design decision. If you don't like it, by all
means use something else, but be sure to keep the source code around
because otherwise it'll be hell to port.

Arrays are not pointers. Pointers are not arrays. Never have been, never
will be. That's a design decision too. If you don't like it, the most
sensible thing you can do is find a different language, because this is
basic stuff.

The presence or absence of bounds-checking is not a language issue, but an
implementation decision. If you want to put bounds-checking into a C
implementation, that's your choice, provided that the implementation
correctly translates correct programs. But don't expect to be able to force
your choice onto other implementors.

This is very, very simple. So the question is: do you *want* to understand?
If so, we'll help.

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

P: n/a
jacob navia said:
Richard Heathfield a écrit :
>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.

This is precisely what I do not accept.

Why being blind to the flaws of the language?
C isn't perfect (for one thing, it's grown too big). But I specifically mean
that when ***YOU***, Jacob Navia, start talking about bugs in the language,
we know it really means that you're going to bang on about your
implementation's useless non-portable mods that *you* think of as
improvements to what *you* think of as bugs in C.
"C, is MY language. Take it or leave it!!!"
No, C is not your language to change as you please without consequences. C
is defined by ISO. If you want to change the language, talk to ISO.
?????

Why isn't possible to discuss the flaws of the language
without flame wars?
It is, but you don't seem to understand what the real flaws are.
>
I remember the starting days of Unix, where EVERY
manual page had a BUGS section. Has this attitude got
lost in this "language nationalism" ???
No, not at all. But what you think are bugs are not in fact bugs. Why not
track down the real bugs instead?

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

P: n/a
jacob navia wrote:
Richard Heathfield a écrit :
>jacob navia said:
.... snip ...
>>
>>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.
You are welcome to use Ada and/or Pascal. This is virtually
guaranteed to avoid the above scenario. Not completely
guaranteed. Simply renaming ISO10206 to be C0x would do the whole
job. However it would break existing code.
>
.... big snip ...
>
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...
Funny thing, my hashlib subsystem, written in purely standard C,
routinely controls millions of allocations without any known memory
leaks. It may have something to do with being systematic.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Dec 27 '06 #18

P: n/a
"João Jerónimo" <j_*******@yahoo.com.brwrote in message
Malcolm wrote:
>like the typedef problem, are debateable.

What's the typedef problem?
I don't like their syntax, but I think it's just a matter of taste...
Bool breaks libraries.

That, in a nutshell, is the typedef problem. The ability to define aliases
for basic types makes code unreadable, and forces all code to use a
particular convention, making it difficult to integrate functions from two
sources.

Typedefing structs is a bit different. Here you are creating a compund type.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Dec 27 '06 #19

P: n/a
Malcolm said:

<snip>
Typedefing structs is a bit different. Here you are creating a compund
type.
....which has nothing to do with the typedef. The typedef doesn't create a
compound type. It merely creates a synonym for an existing type.

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

P: n/a
Richard Heathfield wrote:
>Typedefing structs is a bit different. Here you are creating a compund
type.

...which has nothing to do with the typedef. The typedef doesn't create a
compound type. It merely creates a synonym for an existing type.
Yes, but it makes the use of compound types much simples, exactly
because of the alias...

JJ
Dec 27 '06 #21

P: n/a
Malcolm wrote:
>>like the typedef problem, are debateable.
What's the typedef problem?
I don't like their syntax, but I think it's just a matter of taste...
Bool breaks libraries.

That, in a nutshell, is the typedef problem. The ability to define aliases
for basic types makes code unreadable, and forces all code to use a
particular convention, making it difficult to integrate functions from two
sources.
That would be solved if C had some more precise types...
Instead of relying on "at least x bits" types, C should have defined
types with 8 bits, types with 16 bits and types with 32 bits...
This was difficult in the time when C was designed, because of the
diversity of architectures at the time (I think there were
bit-addressable machines, right?)...
But now "byte" is a synonym of "octet", right? What's the problem with that?

JJ
Dec 27 '06 #22

P: n/a
João Jerónimo said:
Malcolm wrote:
>>>like the typedef problem, are debateable.
What's the typedef problem?
I don't like their syntax, but I think it's just a matter of taste...
Bool breaks libraries.

That, in a nutshell, is the typedef problem. The ability to define
aliases for basic types makes code unreadable, and forces all code to use
a particular convention, making it difficult to integrate functions from
two sources.

That would be solved if C had some more precise types...
Why?
Instead of relying on "at least x bits" types, C should have defined
types with 8 bits, types with 16 bits and types with 32 bits...
Why?
This was difficult in the time when C was designed, because of the
diversity of architectures at the time (I think there were
bit-addressable machines, right?)...
But now "byte" is a synonym of "octet", right?
Wrong. Numerous counter-examples exist.

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

P: n/a
Richard Heathfield a écrit :
jacob navia said:

>>Richard Heathfield a écrit :
>>>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.

This is precisely what I do not accept.

Why being blind to the flaws of the language?


C isn't perfect (for one thing, it's grown too big). But I specifically mean
that when ***YOU***, Jacob Navia, start talking about bugs in the language,
we know it really means that you're going to bang on about your
implementation's useless non-portable mods that *you* think of as
improvements to what *you* think of as bugs in C.
Of course when *YOU* speak you do not do it for yourself but in
the name of all people that use C, all reasonable people, etc.

I know that when *I* speak I speak for myself.

And your point was?
Your opinion about lcc-win32 is second hand anyway since you
never use it. Your discussion so far presents no arguments
but "C strings are a design decision". So what? I know that.

I am just saying that they were a BAD design decision.

The same as with the example I wrote about arrays.

The evaluation of the expression

array

in the example, evaluates to a pointer, not to an array even
if the object is an array.

When I write
fn(array);

this "array" identifier evaluates to a pointer.

When I write

struct tagFoo {
int array[2756];
};

struct tagFoo array;

And I write later in some function:

fn(array);

The structure is passed by value. Not so for arrays.

This is (of course) a design decision. It is just
a very bad idea. ALL size information about the
array is lost.

But I know that you will throw some words to deny this, as you
have done in your previous messages, but it will not help you. This are
just FACTS.

Dec 27 '06 #24

P: n/a
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.
2) Inefficient scanning AGAIN and AGAIN the whole string
to know the length.
3) Memory overflows when copying.

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!

OR

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

Inefficient.
>
>>>>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...
>
>>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. They realized already
that this "array decaying" wasn't very good and developed a whole
new set of arrays. They had to anyway.
>
>>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. Then tell me:

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

You must pass it separatedly isn't it?
>
>>> 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. 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!
>
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 :-)
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. Why when I define

struct tagArray { int array[2765];};

struct tagArray array;

Now, when I write

fn(array);

no "decaying" happens. Ahh, great. At least *some* things work!

>
>>>No bugs so far.

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


Right.
Yes, another one of this FEATURES...
>
>>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.
>
>>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... instead of
getting rid of multi-threading let's get rid of malloc/free!

More and more applications are designed with multi-threading in mind.
Even the hardware is now multi-threaded with several "cores".

But let's keep living in the past...
Dec 27 '06 #25

P: n/a
jacob navia said:

<snip>
>
Of course when *YOU* speak you do not do it for yourself but in
the name of all people that use C, all reasonable people, etc.
No, I speak for myself, just as you do.
I know that when *I* speak I speak for myself.

And your point was?
Just beyond your grasp, it appears.
Your opinion about lcc-win32 is second hand anyway since you
never use it.
Yes. My opinion about lcc-win32 has been formed almost entirely from your
articles, so perhaps it would be wiser for you to avoid any temptation to
go into marketing.
Your discussion so far presents no arguments
but "C strings are a design decision". So what? I know that.
Then they can hardly constitute a bug. You might not like them; you might
think they're a bad idea; you might even think they constitute a blemish in
the language design - but to call them a "bug" is to misuse the term.
I am just saying that they were a BAD design decision.
Fine, you're entitled to that opinion. I would even go so far as to say that
I don't entirely disagree with it.
The same as with the example I wrote about arrays.

The evaluation of the expression

array

in the example, evaluates to a pointer, not to an array even
if the object is an array.
Correct.
When I write
fn(array);

this "array" identifier evaluates to a pointer.
The expression has pointer type, yes.
When I write

struct tagFoo {
int array[2756];
};

struct tagFoo array;

And I write later in some function:

fn(array);

The structure is passed by value.
Correct.
Not so for arrays.
The array isn't passed *at all*, so how can it be passed by value?
This is (of course) a design decision. It is just
a very bad idea. ALL size information about the
array is lost.
No, it's not. The size information is retained. It is simply that the
information is not *conveyed* to a called function (unless you convey that
information yourself via, say, another argument to the function, and write
the function in such a way that it can receive this information). And why
should it? You're not, after all, passing an array. You're passing a
pointer.
But I know that you will throw some words to deny this, as you
have done in your previous messages, but it will not help you. This are
just FACTS.
So you claim.

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

P: n/a
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. Dik 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.
Dec 27 '06 #27

P: n/a

"shaanxxx" <sh******@yahoo.comwrote in message
news:11**********************@73g2000cwn.googlegro ups.com...
>I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.

I just wanted to know what other people thinks on this .

Like most things - choose the best tool for the job and be pragmatic.
Sometimes assembler, sometimes C, sometimes C++ (sometimes ADA, etc.). Each
has their place.

Working in the embedded field I have completed many *object based* projects
in C for which I would never consider using C++. I have also completed
projects in C++ I would not consider to be appropriate to tackle in C
considering C++ was available as an option.

I have encountered C++ Nazis who know ever last detail of the C++ spec and
consider you antiquated/foolish if you use C. I like watching them fall
flat on their arses when they try and write an embedded project and their
code does not even compile ;-) Naturally it is "the compilers fault"
because it does not correctly implement the standard - like anybody thought
it would.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
Dec 27 '06 #28

P: n/a
>>>>"jn" == jacob navia <ja***@jacob.remcomp.frwrites:

jnYour opinion about lcc-win32 is second hand anyway since you
jnnever use it. Your discussion so far presents no arguments but
jn"C strings are a design decision". So what? I know that.

jnI am just saying that they were a BAD design decision.

You know, when Bjarne Stroustrup decided he didn't like some of the
limitations of C, he designed C++.

When Brad Cox didn't like some of the limitations of C, he designed
Objective-C.

The problem here is not that you see design flaws in C. The problem
is that you believe, in contravention of all evidence, that you can
singlehandedly redesign C *and still call it C*.

C is the language defined by K&R, K&R2, and the C89/90 and C99 standards.

If you want a language remarkably like C, but with length-counted
strings and garbage collection, hey, more power to you! It's likely
to be a fine language, and possibly more useful, more efficient, and
more resilient than C. But unless it conforms to the C standards, it
isn't C.

So why not design the language you really want, and call it something
else?

Charlton

--
Charlton Wilbur
cw*****@chromatico.net
Dec 27 '06 #29

P: n/a
On Wed, 27 Dec 2006 00:17:46 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
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

Dec 27 '06 #30

P: n/a
On Wed, 27 Dec 2006 11:33:35 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
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

Dec 27 '06 #31

P: n/a
Randy Howard said:
>Richard Heathfield a écrit :
<snip>
>>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.
Sure, but they're fewer and further between than most people imagine. At
least, I almost invariably find that people who ask me for help with
multithreaded programs have misunderstood what multithreading is *for*.
They seem to think their programs will run quicker *per se* if they're
multithreaded, as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.

<snip>
Multithreaded programming is not /easy/,
Right. As you are undoubtedly aware already, multithreading is for those who
can't figure out state machines - and state machines are for those who
can't figure out multithreading. :-)

<snip>

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

P: n/a
On Wed, 27 Dec 2006 15:58:36 -0600, Richard Heathfield wrote
(in article <at*********************@bt.com>):
Randy Howard said:
>>Richard Heathfield a écrit :

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

Sure, but they're fewer and further between than most people imagine.
Absolutely. But when you do have a problem suitable for
multi-threading, they can and often do the job very well.
At least, I almost invariably find that people who ask me for help with
multithreaded programs have misunderstood what multithreading is *for*.
No doubt. Companies with names like "Intel" spew so much BS about
threading, it's hard to imagine that not being a problem.
They seem to think their programs will run quicker *per se* if they're
multithreaded, as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.
The other misconception, which it /sounds/ like may apply to you given
the above, although I rather doubt it, is that threading can only help
in situations where you are CPU-bound. It is also quite helpful in
some i/o bound situations (i.e. server land), but not in the way most
people think. There are several large 'buckets' of problems which can
benefit from threading, and the contents of one bucket don't resemble
the contents of the next bucket much at all.
>Multithreaded programming is not /easy/,

Right. As you are undoubtedly aware already, multithreading is for those who
can't figure out state machines - and state machines are for those who
can't figure out multithreading. :-)
I'm not sure I agree with that in the literal sense, but I get the
humor in it nevertheless.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Dec 27 '06 #33

P: n/a
Richard Heathfield wrote:
jacob navia said:
>Richard Heathfield a écrit :
.... snip ...
>
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. Dik 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.
Possibly better expressed as an linked list :-)
>
.... snip ...
>
>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?
Which is just what strlcpy/cat do. They also provide a post-call
means of detecting that the passed size was insufficient, and of
deciding what that size needs to be.

char a[size];
size_t lgh;
...
if ((lgh = strlcpy(array, whatever, sizeof a)) >= sizeof a){
/* it got truncated */;
else /* everything fit */;

and the necessity of passing the available size tends to encourage
the programmer to supply that value, on pain of rejection at
compile time.

.... large snip ...

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Dec 27 '06 #34

P: n/a
João Jerónimo <j_*******@yahoo.com.brwrites:
Richard Heathfield wrote:
>>Typedefing structs is a bit different. Here you are creating a compund
type.
...which has nothing to do with the typedef. The typedef doesn't
create a compound type. It merely creates a synonym for an existing
type.

Yes, but it makes the use of compound types much simples, exactly
because of the alias...
I hardly think that being able to refer to a type as "foo" rather than
"struct foo" makes compound types much simpler. And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dec 27 '06 #35

P: n/a
Keith Thompson said:

<snip>
I hardly think that being able to refer to a type as "foo" rather than
"struct foo" makes compound types much simpler.
Agreed.
And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.
Not agreed. The process is no more complicated than without typedef. The
important thing to remember is that the type synonym isn't usable until the
type exists. The fact that you can "embed" the type definition within the
typedef is a mere distraction, and in any case is not compulsory. Nowadays,
I do this as follows:

struct node_
{
void *data;
struct node_ *left;
struct node_ *right;
};

typedef struct node_ node;

to separate out the two steps, making the whole process clearer. (Yes, I
know I could use the same name for the struct tag and the typedef, but I
choose not to do so, because I think it's a possible source of confusion
for the maintenance programmer.)

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

P: n/a
On Wed, 27 Dec 2006 21:58:36 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
>Randy Howard said:
>>Richard Heathfield a écrit :
(randy wrote, commenting on Richard's assertion that multithreading is
of little benefit)
>
>Here I have to disagree with Richard. It does offer real benefits in
some problem domains.
....
>[people] seem to think their programs will run quicker *per se* if they're
multithreaded,
Consider that most modern computer systems have multiple processors -
graphics controllers, dedicated HDD controllers, dedicated network
controllers etc.
>as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.
Many systems also have multi-cpu cores. Single threaded apps cannot
take full advantage of that, no matter how clever the compiler or OS
are.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Dec 27 '06 #37

P: n/a
Mark McIntyre said:
On Wed, 27 Dec 2006 21:58:36 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>[people] seem to think their programs will run quicker *per se* if they're
multithreaded,

Consider that most modern computer systems have multiple processors -
graphics controllers, dedicated HDD controllers, dedicated network
controllers etc.
Nevertheless, simply making your program multi-threaded will not mean that
it is guaranteed to run faster.
>>as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.

Many systems also have multi-cpu cores. Single threaded apps cannot
take full advantage of that, no matter how clever the compiler or OS
are.
A user of a single-threaded program can nevertheless take at least *some*
advantage, because he can run that program on one CPU and some other
program on another.

But my main point is that multithreading is not a magic wand you can wave at
any problem. It can certainly be used effectively, but it can also be used
ineffectually, and can even be counter-productive.

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

P: n/a
In article <45**********************@news.orange.frjacob navia <ja***@jacob.remcomp.frwrites:
Richard Heathfield a écrit :
jacob navia said:
....
>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.
Perhaps. But the conclusion that it is impossible to do bound checking
is false. If a compiler decides to use fat pointers, bound checking *is*
possible.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dec 28 '06 #39

P: n/a
ne********@sbcglobal.net skrev:
A good friend of mine had a BASH script he used which would run on average over 20 minutes.

As a programming practice in C (to freshen my skills) - remade the program

And it completed on average over 2 seconds....

From 20 minutes to 2 seconds... C's efficiency combined with the power left to the programmer
And what features specific to C enabled you to make the program that
much more efficient?
August
Dec 28 '06 #40

P: n/a
August Karlstrom <fu********@comhem.sewrote:
ne********@sbcglobal.net skrev:
>A good friend of mine had a BASH script he used which would run on average over 20 minutes.

As a programming practice in C (to freshen my skills) - remade the program

And it completed on average over 2 seconds....

From 20 minutes to 2 seconds... C's efficiency combined with the power left to the programmer

And what features specific to C enabled you to make the program that
much more efficient?
August
1) My friend and I have noticed that working with arrays in C are much faster than anything we compile with any other language. The programming concepts are the same, but the implementation on systems make C run faster on average

(from our experience)

2) The built in library functions of bsearch and qsort work faster than using strings in C++ for doing much the same thing. (Obviously a lot faster then using BASH)
I must say that these are observations that we have seen. I'm not stating they're a universal experience, have
you had the same experience?
Dec 28 '06 #41

P: n/a
Keith Thompson wrote:
>Yes, but it makes the use of compound types much simples, exactly
because of the alias...

I hardly think that being able to refer to a type as "foo" rather than
"struct foo" makes compound types much simpler. And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.
I really shouldn't be discussing this kind of things with the little
experience I have...

Sorry!
Today I was for the first time trying to implement a linked list in C
and faced exactly this problem!
And then I started thinking about whether to abstract the structures
with typedefs or not!

JJ
Dec 28 '06 #42

P: n/a
Richard Heathfield wrote:
>And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.

Not agreed. The process is no more complicated than without typedef. The
important thing to remember is that the type synonym isn't usable until the
type exists.
But on the other hand, a structure (in the structures namespace) can be
used before completely defined... It doesn't need to be defined, either!
In fact, I tried that now:
typedef struct garbage garb;

gcc doesn't complain if I try to create an object from this code...
If I try to access it before struct garbage exists it complains that it
doesn't know the size (because it needs to allocate space on the stack)...

JJ
Dec 28 '06 #43

P: n/a
Richard Heathfield wrote:
>That would be solved if C had some more precise types...
Instead of relying on "at least x bits" types, C should have defined
types with 8 bits, types with 16 bits and types with 32 bits...

Why?
In my opinion (not very experienced, I admit), the types with imprecise
size aren't bad... Only there could *also* be the precise ones.

Remember that when programming in very low-level, one has sometimes to
adapt data structures to hardware-imposed patterns...
And typedefs allow working around this.
>This was difficult in the time when C was designed, because of the
diversity of architectures at the time (I think there were
bit-addressable machines, right?)...
But now "byte" is a synonym of "octet", right?

Wrong. Numerous counter-examples exist.
Can you give some of these examples?

JJ
Dec 28 '06 #44

P: n/a
On Wed, 27 Dec 2006 17:19:06 -0600, Richard Heathfield wrote
(in article <io*********************@bt.com>):
Mark McIntyre said:
>On Wed, 27 Dec 2006 21:58:36 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>[people] seem to think their programs will run quicker *per se* if they're
multithreaded,

Consider that most modern computer systems have multiple processors -
graphics controllers, dedicated HDD controllers, dedicated network
controllers etc.

Nevertheless, simply making your program multi-threaded will not mean that
it is guaranteed to run faster.
This is generally true. Most people, especially when first exposed to
threads usually manage to make their program run much slower. Of
course, that is no more the fault of threads than programmers having
problems with pointers are C's fault. :-)
A user of a single-threaded program can nevertheless take at least *some*
advantage, because he can run that program on one CPU and some other
program on another.
True, but that's only a seat-of-the-pants speedup, whether a single
application runs faster or not, the system as a whole feels faster.
But my main point is that multithreading is not a magic wand you can wave at
any problem. It can certainly be used effectively, but it can also be used
ineffectually, and can even be counter-productive.
That's true of any programming methodology, language or even API.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Dec 28 '06 #45

P: n/a
Randy Howard a écrit :
>
>>>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.
I am just saying they are not needed any more. Why they are here?
Because a Danish manufacturer had problems with '{' and other
letters of the C alphabet. In the horse trading that goes behind
the publications of international standards they got into the
standard that trigraphs would be there to save them.

Then, time passes, the manufacturer has disappeared since a long
time, and we are stuck with a nonsense construct!!!!
>
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.
Ahh bugs are BAD BAD.

Great discovery. We are discussing how to avoid them if possible.
One of the ways to avoid them is to make things automatic
whenever possible so that the programmer has less to do, and less
possibilities of errors.

Why C is better than assembly?

Because the level of detail that you have to care about is less.

You just write:

c = a+b;

and you do not have to care about which register you use,
which address are b and c, etc etc.

If we have counted strings the length of the string is no longer
a problem you have to manage but the string library.

If you use the GC you do not care about free(). One problem
LESS to care about
Dec 28 '06 #46

P: n/a
Randy Howard a écrit :
On Wed, 27 Dec 2006 00:17:46 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
>>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.
To answer you in terms of your own analogy:

C gives you a machette without a HANDLE.
You can't use it without cutting yourself the hand.

I want to add a HANDLE to the machette i.e. a BLUNT
side where I can handle it without getting my blood in my
fingers...

jacob
Dec 28 '06 #47

P: n/a
João Jerónimo said:
Richard Heathfield wrote:
>>And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.

Not agreed. The process is no more complicated than without typedef. The
important thing to remember is that the type synonym isn't usable until
the type exists.

But on the other hand, a structure (in the structures namespace) can be
used before completely defined... It doesn't need to be defined, either!
No, it can't be used before it is defined. But its *name* can be used in a
typedef, yes.
In fact, I tried that now:
typedef struct garbage garb;
Yes, that's legal.
gcc doesn't complain if I try to create an object from this code...
When invoked in conforming mode, it must complain.
If I try to access it before struct garbage exists it complains that it
doesn't know the size (because it needs to allocate space on the stack)...
C doesn't require implementations to allocate space on any kind of "stack",
but the type must be complete before you can define an object of that type.

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

P: n/a
João Jerónimo said:
Richard Heathfield wrote:
>>That would be solved if C had some more precise types...
Instead of relying on "at least x bits" types, C should have defined
types with 8 bits, types with 16 bits and types with 32 bits...

Why?

In my opinion (not very experienced, I admit), the types with imprecise
size aren't bad... Only there could *also* be the precise ones.
Fine, but eventually people will say "why does C have this
guaranteed-to-be-exactly-8-bits type? Nobody has used 8-bit bytes for
*decades*!" And we will not even have the excuse of "historical reasons",
since C started off *without* such a type.
Remember that when programming in very low-level, one has sometimes to
adapt data structures to hardware-imposed patterns...
....which is why C leaves the exact size of types up to the implementor.
And typedefs allow working around this.
No, they just let you create a new name for an existing type.
>
>>This was difficult in the time when C was designed, because of the
diversity of architectures at the time (I think there were
bit-addressable machines, right?)...
But now "byte" is a synonym of "octet", right?

Wrong. Numerous counter-examples exist.

Can you give some of these examples?
I can give you one, because it's one that I have written C code for: the
Analog SHARC DSP (used in set-top boxes, e.g. DVD players, Web TV, that
sort of thing), which has 32-bit bytes. So sizeof(long), sizeof(short),
sizeof(int), and sizeof(char) are all the same: 1.

No doubt others here can tell you about other DSPs with 16- or 32-bit bytes.
They're hardly rare. Also, various dinosaurs have had very weird byte
sizes, e.g. 9, 36, and I believe there was once a 24 (BICBW).

All that C guarantees is that your bytes will be *at least* 8 bits wide, and
*exactly* CHAR_BIT bits wide, where the value of CHAR_BIT is set by the
implementation.

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

P: n/a
jacob navia said:

<snip>
>
I am just saying [trigraphs] are not needed any more. Why they are here?
Because a Danish manufacturer had problems with '{' and other
letters of the C alphabet. In the horse trading that goes behind
the publications of international standards they got into the
standard that trigraphs would be there to save them.

Then, time passes, the manufacturer has disappeared since a long
time, and we are stuck with a nonsense construct!!!!
So you claim. Nonetheless, trigraphs remain useful even now in, say,
mainframe environments. But if you don't like trigraphs, don't use them.

<snip>
Great discovery. We are discussing how to avoid them if possible.
One of the ways to avoid [bugs] is to make things automatic
whenever possible so that the programmer has less to do, and less
possibilities of errors.
Quite so, but that automation comes at a cost (typically a performance
drop). So there's a trade-off here - you can automate some parts of your
program generation and reduce programmer time, or you can do it by hand and
reduce runtime. For people who want the former, there are already other
languages that cater for them. For people who want the latter, C caters for
them. If you change C so that it no longer caters for those people, they
will ignore the changes, and go on using the old C, because the old C meets
their needs better than the new C does.
Why C is better than assembly?
Because it's portable. Duh.

<snip>

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

167 Replies

This discussion thread is closed

Replies have been disabled for this discussion.