UNIX, C, Perl

Willem wrote:

jacob navia wrote:
) Richard Heathfield wrote:
)
) [snip]
)
) I asked you a question Heathfield, a question that you conveniently
) snipped away.
)
) I repeat it:
) How would *you* solve the above problem?

You're begging the question.
Richard never claimed (in this thread at least) that your
solution was bad in any way.

He just snipped the question. Obviously if I asked the question
again I wanted to know what he thinks.

I did not say that he answered...

And here's the question *you* never answered.
The question that *is* relevant:

Why do you argue about changing C *here*, in this newsgroup ?

Because this group discusses the C language obviously.

I presented my ideas to the comp.std.c group, many times.

I discuss them there too.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 3 '08 #52

Malcolm McLean

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

I still have some "give me 64" mugs left. I trust you are now joining the
campaign for 64 bit ints.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 3 '08 #53

Pilcrow

On Wed, 03 Sep 2008 17:07:00 +0200, jacob navia <ja***@nospam.com>
wrote:

>Richard Heathfield wrote:
>Pilcrow said:

>>Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

>>Examples:
Network and internet access,

C allows you to call library functions that provide these features, but
doesn't go so far as to make their provision mandatory. (Otherwise, you
couldn't have a C implementation on a system that didn't have internet
access - and that would be silly.)

Exactly.

There are many implementations of networking, from
Windows sockets, BSD sockets, Netware, USB networking,
Wan, LANs, etc.

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib.pl');
use strict;
my(@dirList);
ftp::debug('ON');
ftp::open('ftp.cis.ufl.edu', 'anonymous', 'm******@planet.net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ.gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
----------------------------------------------perl

You seem to be using a very old version of perl - perhaps even perl 4.
And no perl user would use that style. The two lines before the last
bracket, for example, would probably be coded like this:

print "\t$_\n" for @dirlist;

See the modules Net::FTP or WWW::Mechanize or LWP::Simple for modern
methods.

>Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

You can not have tested that, since there is no such directory at the
site of the University of Florida.

However, here is a one-line perl script I've actually tested:

perl -MLWP::Simple -e 'getstore "http://www.google.com","demo.html"'

You type it on the command line. It retrieves Google's home page and
stores it in the file demo.html .
But you need the module LWP::Simple to run it

(snip)

>Exactly. C has "modules", and the interface is simple and efficient.
There is an enormous amount of C libraries around.

I am so glad to hear that. Perhaps someone would be so kind as to post
a list of them? At least the more important ones. URL's would be nice.

Sep 3 '08 #54

Keith Thompson

jacob navia <ja***@nospam.comwrites:

Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
[...]

>>They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not
going
to take your word for it. Please post the Message-ID of an article in
which he said that.

The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:

Can we get rid of gets()?

Mr Gwyn defended keeping gets() in the standard document.

And he won. gets() is still in the C99 document.

Ok.

I started a similar discussion last year, 11 years later and Mr Gwyn
was again in the group of the ultra-conservatives that want to keep
gets(), trigraphs, and vehemently deny that ANY changes should
be done.

Ok.

He repeated the same position in 2004, when I started again a discussion
about gets().

Ok.

And in 2007 he repeated his position. No changes, gets belong to the
language.

Ok.

The same for ALL the proposals to change a minimal part of the
language. Not even blatant errors like trigraphs.

Ok.

Please post the Message-ID of an article in which Doug Gwyn said that
the main objective of the C standard committee is to preserve C as a
language that should run legacy code with no new development.

Given your track record for inferring people's opinions from what they
write, I don't believe that Doug holds or has ever expressed that
opinion or anything like it. More specifically, I'm sure he thinks
that C should continue to be a language that can deal with legacy code
(so do I; do you?); I don't believe for a moment that he thinks there
should be no new develpment in C.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Sep 3 '08 #55

jacob navia wrote:

Willem wrote:

....

Why do you argue about changing C *here*, in this newsgroup ?

Because this group discusses the C language obviously.

I presented my ideas to the comp.std.c group, many times.

I discuss them there too.

While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.

Further piece of advice: if and when you actually make your proposals
to the committee, please try to lay off on the slanderous accusations
that pepper your typical postings in this newsgroup. Even if those
accusations were true, you couldn't possibly expect accusations of
idiocy, incompetence, and laziness to make the people you so accuse
more willing to cooperate with you, could you?

Sep 3 '08 #56

On 3 Sep 2008 at 20:07, Pilcrow wrote:

On Wed, 03 Sep 2008 17:07:00 +0200, jacob navia <ja***@nospam.com>
wrote:
>>Exactly. C has "modules", and the interface is simple and efficient.
There is an enormous amount of C libraries around.

I am so glad to hear that. Perhaps someone would be so kind as to post
a list of them? At least the more important ones. URL's would be nice.

http://packages.debian.org/stable/libdevel/

Sep 3 '08 #57

jacob navia wrote:

Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:

[...]

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.

To which you responded (without presenting even a single Message-ID):

The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:

Can we get rid of gets()?

Mr Gwyn defended keeping gets() in the standard document.

And he won. gets() is still in the C99 document.

I started a similar discussion last year, 11 years later and Mr Gwyn
was again in the group of the ultra-conservatives that want to keep
gets(), trigraphs, and vehemently deny that ANY changes should
be done.

He repeated the same position in 2004, when I started again a discussion
about gets().

And in 2007 he repeated his position. No changes, gets belong to the
language.

The same for ALL the proposals to change a minimal part of the
language. Not even blatant errors like trigraphs.

You've cited a lot of evidence suggesting that Doug Gwyn opposes
particular changes to the standard. That was never in question. Any
reasonable person will, occasionally, oppose particular changes to the
standard, and sometimes for reasons that are wrong. Doug has
occasionally also spoken in favor of particular changes to the
standard. Personally, I favor more changes to the standard than he
does, and fewer than you do. However, that's all very different from
your slanderous claim that

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,

Nothing you've cited above says anything about "no new development".
Where, precisely, did Doug Gwyn (or anyone else on the committee)
express THAT opinion? And this time, please provide precise message
identification.

Sep 3 '08 #58

ja*********@verizon.net wrote:

While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.

I need 10 thousand euros (15 000 US$) to buy the AFNOR
(French ISO organization) to present my proposal after
I got sponsored by some company.

I do not have either the sponsors nor that amount of money.

And I have repeated this MANY times, to you and to others.

And you STILL tell me to present proposals to ISO.

I do not have the financial resources for that is that clear?

Further piece of advice: if and when you actually make your proposals
to the committee, please try to lay off on the slanderous accusations
that pepper your typical postings in this newsgroup. Even if those
accusations were true, you couldn't possibly expect accusations of
idiocy, incompetence, and laziness to make the people you so accuse
more willing to cooperate with you, could you?

I have never said that they are idiots or lazy or whatever. You
are just lying (as you often do)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 3 '08 #59

Flash Gordon

jacob navia wrote, On 03/09/08 22:18:

ja*********@verizon.net wrote:
>jacob navia wrote:
>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:

[...]

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,

>>>>as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.

To which you responded (without presenting even a single Message-ID):

This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
<47***************@null.netThread name "C needs a BOOST"

<snip>

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much

^^^^

new development really ought to use higher-level languages in
the first place.

<snip>

Yes, you read correctly.
"Much new development really ought to use higher level languages"

^^^^

than C.

This is in essence what I said.

No, it is very different from what you claimed he said. Much freight is
transported by ship, but that does not prevent freight from being
transported by rail, road and plane. Most Chinese speakers live in
China, yet I hear Chinese being spoken in England by people living in
England.

<snip>

My opinion, based on considerable experience in this area, is that
C remains the best choice for much "systems implementation" work,
but that it is more cost-effective to use other, higher-level
languages for many "applications".

^^^^

Many is not all.

<snip>

It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.

Are you claiming that C should be used as a general solution to ALL
programming problems?

He says "it is not what I said"... then repeats everything again.

Nowhere in what you have quoted has he said that no new development or
applications should be done in C. He has also stated that he does want
some changes to the language, for how can the deficiencies be remedied
without changing the language?

C is good only for systems work, etc etc,

You are miss-quoting here what you have quoted above.

new development or
application dveelopment should be done in better languages, etc.

He said much, not all.
--
Flash Gordon

Sep 3 '08 #60

Flash Gordon wrote:

>
Are you claiming that C should be used as a general solution to ALL
programming problems?

Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...

You apparently are of the same opinion.

By leaving application programming for other languages, you
effectively destroy C.

Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

I am claiming that C can be used for general application
programming. It needs just a single modification
(operator overloading) and a rewrite of the standard library
to be able to be very useful in application programming.

Why?

Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.

I am opposed to most current trends in language development exactly
because I think that simplicity is a virtue and simple things are
basically much more powerful than complicated ones.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 3 '08 #61

Pilcrow

On Wed, 3 Sep 2008 20:18:45 +0000 (UTC), Antoninus Twink
<no****@nospam.invalidwrote:

>On 3 Sep 2008 at 20:07, Pilcrow wrote:
>On Wed, 03 Sep 2008 17:07:00 +0200, jacob navia <ja***@nospam.com>
wrote:
>>>Exactly. C has "modules", and the interface is simple and efficient.
There is an enormous amount of C libraries around.

I am so glad to hear that. Perhaps someone would be so kind as to post
a list of them? At least the more important ones. URL's would be nice.

http://packages.debian.org/stable/libdevel/

Thank you sir; that's a beginning.

Sep 3 '08 #62

jacob navia wrote:

ja*********@verizon.net wrote:
While such a suggestion is on-topic in that group, it is still not the
right place to make your proposal. Only a small number of committee
members participate in that group. If you really want anything to
change, you have to present your proposal to the committee, or at
least convince one of the committee members that your ideas have
sufficient merit to for that committee member to present them for you.
The committee members ore the ONLY ones who can actually make it
happen - nothing you say to anyone else will have much effect.

I need 10 thousand euros (15 000 US$) to buy the AFNOR
(French ISO organization) to present my proposal after
I got sponsored by some company.

Then join ANSI instead. Membership is not restricted to organizations;
individuals can join as well. It is not restricted to US citizens; in
fact a large number of its members are foreign citizens like you who
were unable to afford their own national body's prohibitively high
fees. The Basic membership fee is currently $495, easily within the
range that could be afforded by most professionals. Actually attending
meetings is required only if you want to be a voting member.

I confess to a certain amount of uncertainty about the organizational
connections here; hopefully someone here can fill out the details. I
know that ANSI is listed as participating in ISO/IEC JTC 1, but that
the US Technical Advisory Group for ISO/IEC JTC1/SC22 is INCITS.
INCITS membership is not cheap, and I could find nothing to suggest
that it is open to individuals. I was under the impression that it is
possible to participate in the C standardization process as an
individual member of ANSI, but I can't find anything that clarifies
that it is possible to do so without being a member of INCITS.

Further piece of advice: if and when you actually make your proposals
to the committee, please try to lay off on the slanderous accusations
that pepper your typical postings in this newsgroup. Even if those
accusations were true, you couldn't possibly expect accusations of
idiocy, incompetence, and laziness to make the people you so accuse
more willing to cooperate with you, could you?

I have never said that they are idiots or lazy or whatever. You
are just lying (as you often do)

No, I'm just summarizing. You've accused the committee of wanting C to
be a language restricted to use on legacy code, with no new
development. With no new development, it would be pointless for
committee members to paying hard-earned money for membership fees that
buy them the privilege of putting in hard work on changes to the
standard. Who in their right minds would make such sacrifices to
achieve such a pointless goal? By making such a ridiculous accusation
you're implying that they are at least idiots, if not certifiably
insane.

Sep 3 '08 #63

Keith Thompson

jacob navia <ja***@nospam.comwrites:

Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
[...]

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not
going
to take your word for it. Please post the Message-ID of an article in
which he said that.

[snip]

This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
<47***************@null.netThread name "C needs a BOOST"
<quote>
Ian Collins wrote:

My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

There is a difference between your claim that he said there should be
"no new development", and his actual statement that "Much new
development really ought to use higher-level languages in the first
place."

Just as I've come to expect, you have grossly misrepresented what he
actually wrote.

[...]

Yes, you read correctly.
"Much new development really ought to use higher level languages"
than C.

This is in essence what I said.

Nonsense.

I remember asking him:
<quote>
Actually then, you say it is better not to develop anything new in C.
<end quote>

Then he answered:
<quote>
That's not what I said. I said that *much* new development ought
to be done in higher-level languages. (In fact, it often is.)

He even told you that you had misrepresented his words.

[snip]

He says "it is not what I said"... then repeats everything again.

C is good only for systems work, etc etc, new development or
application dveelopment should be done in better languages, etc.

Which, one more time, is not what he said.

Learn to read.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Sep 3 '08 #64

jacob navia wrote:

ja*********@verizon.net wrote:
jacob navia wrote:
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:

[...]

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.

....

This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
<47***************@null.netThread name "C needs a BOOST"

....

development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

....

Yes, you read correctly.
"Much new development really ought to use higher level languages"
than C.

Quite a reaonable statement, and not at all what you claimed he said.

This is in essence what I said.

No, "much" is quite different from "all". The first makes for an
entirely reasonable statement; replacing "much" with "all" would
produce a preposterous statement, and one that Doug Gwyn did NOT make.

I remember asking him:
<quote>
Actually then, you say it is better not to develop anything new in C.
<end quote>

Then he answered:
<quote>
That's not what I said. I said that *much* new development ought

^^^^^^^^^^^^^^^^^^^^^

to be done in higher-level languages. (In fact, it often is.)

Note the use of the word "much" rather than "all".

That means that the potential benefit of new facilities for such
applications is diminished.

I would like that you claify this of course. Did I understand you
correctly?

I doubt that you did.

^^^^^^^^^^^^^^^^^^^^

My opinion, based on considerable experience in this area, is that
C remains the best choice for much "systems implementation" work,
but that it is more cost-effective to use other, higher-level
languages for many "applications".

Note the key word "many". Not "all", "many". Understand the
difference.

....

He says "it is not what I said"... then repeats everything again.

Yes, because you quite clearly did not understand it the first time.
You still do not - you still make the mistake of confusing "many" with
"all". Are you consistent in this misconception? If I told you that
the total value of all of my stocks exceeded $500K, and offered to
sell you "many" of my stocks for a mere $200K, would you be under the
misapprehension that I was offering you a good deal? If so, I've got
quite a number of similarly "good deals" I'd be willing to discuss
with you.

Sep 4 '08 #65

Bartc

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

jacob navia <ja***@nospam.comwrites:
>Keith Thompson wrote:
>>jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
[...]
>
>They will never do anything since their main objective is to preserve
>C as a language that should run legacy code with no new development,
>as Mr Gwyn explained in comp.std.c.
I don't recall Doug Gwyn ever saying that, and I'm certainly not
going
to take your word for it. Please post the Message-ID of an article in
which he said that.

[snip]

>This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
<47***************@null.netThread name "C needs a BOOST"
<quote>
Ian Collins wrote:
>My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

There is a difference between your claim that he said there should be
"no new development", and his actual statement that "Much new
development really ought to use higher-level languages in the first
place."

Just as I've come to expect, you have grossly misrepresented what he
actually wrote.

[...]

>Yes, you read correctly.
"Much new development really ought to use higher level languages"
than C.

This is in essence what I said.

Nonsense.

Reading the quoted text of Mr Gwyn, it does appear to show considerable bias
against interesting new developments in C, in fact appearing to be backward
looking rather than forward looking.

The attitude seemed to be that there's no point in adding new stuff to C
because (a) it's not much use for programmers maintaining existing code; (b)
for new code, it's better to use a 'better' language. So, forget it.

And, C apparently only just cuts it for systems programming, let alone
general programming. In it's present standard form, he might be right, but
seemed completely against the idea of improving C to make it more suitable,
which is what Jacob is trying to do.

>C is good only for systems work, etc etc, new development or
application dveelopment should be done in better languages, etc.

Which, one more time, is not what he said.

Er, I think he did:

"
It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.
"
--
Bartc

Sep 4 '08 #66

Keith Thompson

"Bartc" <bc@freeuk.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>jacob navia <ja***@nospam.comwrites:
>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
>[...]
>>
>>They will never do anything since their main objective is to preserve
>>C as a language that should run legacy code with no new development,
>>as Mr Gwyn explained in comp.std.c.
>I don't recall Doug Gwyn ever saying that, and I'm certainly not
>going
>to take your word for it. Please post the Message-ID of an article in
>which he said that.
[snip]

>>This was written by Gwyn the 10/4/2007 7:43 PM, with Message ID
<47***************@null.netThread name "C needs a BOOST"

<quote>
Ian Collins wrote:
My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

There is a difference between your claim that he said there should be
"no new development", and his actual statement that "Much new
development really ought to use higher-level languages in the first
place."

Just as I've come to expect, you have grossly misrepresented what he
actually wrote.

[...]

>>Yes, you read correctly.
"Much new development really ought to use higher level languages"
than C.

This is in essence what I said.

Nonsense.

Reading the quoted text of Mr Gwyn, it does appear to show
considerable bias against interesting new developments in C, in fact
appearing to be backward looking rather than forward looking.

Perhaps, but there's a clear contradiction between what Doug Gwyn
actually said and what jacob nava claims Doug Gwyn said.

Doug Gywn said that "Much new development really ought to use
higher-level languages in the first place."

jacob navia claimed that Doug Gwyn said that "their [the committee's]
main objective is to preserve C as a language that should run legacy
code with no new development".

You can agree or disagree with what Doug actually said, but it's very
different from jacob's (deliberate?) misrepresentation.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Sep 4 '08 #67

jacob navia said:

ja*********@verizon.net wrote:

<snip>

>Further piece of advice: if and when you actually make your proposals
to the committee, please try to lay off on the slanderous accusations
that pepper your typical postings in this newsgroup. Even if those
accusations were true, you couldn't possibly expect accusations of
idiocy, incompetence, and laziness to make the people you so accuse
more willing to cooperate with you, could you?

I have never said that they are idiots or lazy or whatever. You
are just lying (as you often do)

If I've counted properly, it has taken till your sixth reply in this
subthread to start with the stupid accusations. What took you so long?
Should we be worried? Do you need a doctor?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 4 '08 #68

Malcolm McLean said:

>
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

I still have some "give me 64" mugs left.

I'd have thought you'd still have all but one of them left (presumably
you've reserved one for yourself).

I trust you are now joining the campaign for 64 bit ints.

Why? They're legal already. In any case, one day they will be too small.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 4 '08 #69

jacob navia wrote:

>
<quote>
Ian Collins wrote:

My conclusion has to be that the demand isn't there.

The very age of C might be partly responsible, in that the vast
amount of existing C applications already embed some solutions
to the requirements for lists, etc. The maintenance programmer
(a)is unlikely to rework the existing app just to use some new
standardized interface for the same thing; and (b) has to
continue to maintain whatever libraries he has been using.

The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

By the way, does the C standard committee have an active library group?

Not as a separate entity.

Seeing as you dragged my name into the discussion, I still stick by my
earlier conclusions. There were requirements for higher level
application programming languages with more abstract libraries. C
didn't evolve to fill the gap, so new languages were developed. The
most successful (in terms of adoption) languages aren't the most
expressive, or elegant but the ones with the most useful libraries.
Many of these are well established C libraries wrapped and in a thin
veneer and bundled with the language distribution. C has lost the
mindshare in hosted applications programming and there's little point in
trying to win it back. To do so invites comparisons with that great
English hero King Canute.

One only has to compare the activities of the current C++ and C
committees to see which one is working on an evolving language. I'd be
pleasantly surprised to see the C programming community get as excited
about the next C standard as the C++ programming community is about theirs.

--
Ian Collins.

Sep 4 '08 #70

Ian Collins said:

<snip>

C has lost the
mindshare in hosted applications programming and there's little point in
trying to win it back.

Am I the only one who isn't particularly bothered about this? Let people
write applications in whatever language /they/ want, as long as they leave
me to write them in whatever language /I/ want. I choose C (often - not
always). If they want to use C# or F# or Eb or D minor, that's up to them
- who cares?

To do so invites comparisons with that great
English hero King Canute.

A much-misunderstood man, who had a far better understanding of reality
than did his courtiers.

One only has to compare the activities of the current C++ and C
committees to see which one is working on an evolving language. I'd be
pleasantly surprised to see the C programming community get as excited
about the next C standard as the C++ programming community is about
theirs.

The principal advantage of an unstable language is that you can add bits to
it. The principal advantage of a stable language is that you know what all
the bits are. Both are good, but you can't have both in the same language.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 4 '08 #71

Richard Heathfield wrote:

Ian Collins said:

<snip>

>C has lost the
mindshare in hosted applications programming and there's little point in
trying to win it back.

Am I the only one who isn't particularly bothered about this? Let people
write applications in whatever language /they/ want, as long as they leave
me to write them in whatever language /I/ want. I choose C (often - not
always). If they want to use C# or F# or Eb or D minor, that's up to them
- who cares?

No me. I just use the most appropriate tool for the job.

>
>One only has to compare the activities of the current C++ and C
committees to see which one is working on an evolving language. I'd be
pleasantly surprised to see the C programming community get as excited
about the next C standard as the C++ programming community is about
theirs.

The principal advantage of an unstable language is that you can add bits to
it. The principal advantage of a stable language is that you know what all
the bits are. Both are good, but you can't have both in the same language.

A bit like Latin and English?

I think the activities of the two committees reflect the desire for
change in the user communities. Well before the 1998 C++ standard was
published, most compiler vendors were shipping compilers with most of
the new features. This was followed by a post standard rush to bring
out conforming compilers. Contrast this with C99.

It wasn't only the desire for change, but the nature of the changes.
Most C++ programmers wanted the new features, hardly any C programmers
appear to want most of C99.

So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.

--
Ian Collins.

Sep 4 '08 #72

Ian Collins said:

Richard Heathfield wrote:

<snip>

>The principal advantage of an unstable language is that you can add bits
to it. The principal advantage of a stable language is that you know
what all the bits are. Both are good, but you can't have both in the
same language.

A bit like Latin and English?

Quidquid C dictum sit, altum viditur.

I think the activities of the two committees reflect the desire for
change in the user communities. Well before the 1998 C++ standard was
published, most compiler vendors were shipping compilers with most of
the new features. This was followed by a post standard rush to bring
out conforming compilers. Contrast this with C99.

Perhaps fairer to compare it with C*8*9, where there was a *pre*-standard
rush to bring out conforming compilers.

>
It wasn't only the desire for change, but the nature of the changes.
Most C++ programmers wanted the new features, hardly any C programmers
appear to want most of C99.

That's because C99's changes were the *wrong* changes.

So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.

Actually, the really worthwhile changes are never going to happen. For
example, I do actually think it would be worth adding operator overloading
to C - but I know that ISO is never going to buy that, and I don't see any
point in fighting a losi... well, not /that/ losing battle, anyway.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 4 '08 #73

Richard Bos

jacob navia <ja***@nospam.comwrote:

Kenny McCormack wrote:

Calm down. Take your medicine. You'll feel better soon.

Kenny, you did not answer my post...

So, you take a slug of your own medicine... like it, do you?

Richard

Sep 4 '08 #74

Richard Heathfield wrote:

Ian Collins said:

>So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.

Actually, the really worthwhile changes are never going to happen. For
example, I do actually think it would be worth adding operator overloading
to C - but I know that ISO is never going to buy that, and I don't see any
point in fighting a losi... well, not /that/ losing battle, anyway.

I'm sure they would be, but how many embedded C compiler vendors are
offering operator overloading as an extension? It's probably fair to
assume they have the finger on the pulse of what a large percentage of
C programmers want. The useful subset of C99 additions had been
extensions in a lot of compilers for years before they were standardised.

--
Ian Collins.

Sep 4 '08 #75

Ian Collins wrote:

Richard Heathfield wrote:
>Ian Collins said:

>>So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.
Actually, the really worthwhile changes are never going to happen. For
example, I do actually think it would be worth adding operator overloading
to C - but I know that ISO is never going to buy that, and I don't see any
point in fighting a losi... well, not /that/ losing battle, anyway.

I'm sure they would be, but how many embedded C compiler vendors are
offering operator overloading as an extension?

Operator overloading is not an objective per se. It is a means of making
libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:

data[2]

to acces the third element of a list/array/other

Operator overloading is needed to implement fixed point arithmetic, what
is needed in many small CPUs that do not implement floating point.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 4 '08 #76

jacob navia wrote:

Ian Collins wrote:
>Richard Heathfield wrote:
>>Ian Collins said:

So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.
Actually, the really worthwhile changes are never going to happen.
For example, I do actually think it would be worth adding operator
overloading to C - but I know that ISO is never going to buy that,
and I don't see any point in fighting a losi... well, not /that/
losing battle, anyway.

I'm sure they would be, but how many embedded C compiler vendors are
offering operator overloading as an extension?

Operator overloading is not an objective per se. It is a means of making
libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:

data[2]

to acces the third element of a list/array/other

Operator overloading is needed to implement fixed point arithmetic, what
is needed in many small CPUs that do not implement floating point.

As I said, I don't dispute the utility of operator overloading. What I
do dispute is the demand. As I said in the bit you snipped, the good
bits of C99 where around for a long time before they were standardised
because there was a demand for them. What extensions are most vendors
offering now?

--
Ian Collins.

Sep 4 '08 #77

James Kuyper

Bartc wrote:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>jacob navia <ja***@nospam.comwrites:

....

>>Yes, you read correctly.
"Much new development really ought to use higher level languages"
than C.

This is in essence what I said.

Nonsense.

Reading the quoted text of Mr Gwyn, it does appear to show considerable
bias against interesting new developments in C, in fact appearing to be
backward looking rather than forward looking.

It's not clear, however, whether the bias he shows is excessive, or a
bias that is entirely appropriate. From my experience with him, my
impression is that he's very much a defender of the words of the current
standard against most changes - but that's primarily because he thinks
that most of the many defects in the standard should be dealt with by
having the reader apply a bizarre mind-reading technique which he calls
"common sense", rather than by having the committee fix the words of the
standard to say what it was actually intended to say.

However, he's not against change itself. He just thinks it should occur
slower and with more consideration and in a different direction than
what jacob wants.

The attitude seemed to be that there's no point in adding new stuff to C

You're making exactly the same mistake jacob did. You're converting
statements that favor making few changes into statements that favor
making no change, and that's a misrepresentation of Doug's position.

because (a) it's not much use for programmers maintaining existing code;
(b) for new code, it's better to use a 'better' language. So, forget it.

Again, you're misrepresenting him by converting statements that say that
"much" code should be done in other languages into statements that "all"
code should be done in other languages.

And, C apparently only just cuts it for systems programming, let alone
general programming. In it's present standard form, he might be right,
but seemed completely against the idea of improving C to make it more
suitable, which is what Jacob is trying to do.

No - he's in favor of improving C, and disagrees with jacob about
whether jacob's proposed changes would have that effect. Since a lot of
other smart people who like programming in C agree with him in that
regard, you might want to consider the possibility that it's the nature
of the proposed change that is the problem, not just the simple fact
that it is a change.

>>C is good only for systems work, etc etc, new development or
application dveelopment should be done in better languages, etc.

Which, one more time, is not what he said.

Er, I think he did:

"
It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.
"

Once again, you're converting non-absolute statements into absolute
ones. To show you how you've misinterpreted, I'll rewrite it so that it
actually supports your misinterpretation:

DISCLAIMER: THIS IS NOT MY OPINION - IT IS NOT DOUG'S OPINION - IT IS
NOT ANYONE'S OPINION, AFAIK:
"It is a mistake to try to push C (in any variant) as a solution for any
programming problem other than the systems programming tasks that it was
designed for, although it still has deficiencies even for that. Time
spent discussing directions for C should be exclusively spend on
remedying its remaining deficiencies for systems work, and not on trying
to support applications where there is always a better choice."

Can you see the difference between my re-write and what he actually
said? Do you understand that your statements apply only to my rewrite,
and not to the original? I only changed a few words, but the result is
that it converts a legitimate point of view (which I don't fully share)
into a statement that could only be made by an idiot.

Sep 4 '08 #78

On 4 Sep 2008 at 2:06, Keith Thompson wrote:

Perhaps, but there's a clear contradiction between what Doug Gwyn
actually said and what jacob nava claims Doug Gwyn said.

Doug Gywn said that "Much new development really ought to use
higher-level languages in the first place."

jacob navia claimed that Doug Gwyn said that "their [the committee's]
main objective is to preserve C as a language that should run legacy
code with no new development".

You can agree or disagree with what Doug actually said, but it's very
different from jacob's (deliberate?) misrepresentation.

Bullshit. It's strikingly similar. If you remove your fundamentalist
glasses for a second, you'll see that Jacob has expressed the same
thought in different words. It's called paraphrase, and that doesn't
make it a misrepresentation.

Sep 4 '08 #79

On 4 Sep 2008 at 6:07, Richard Heathfield wrote:

Quidquid C dictum sit, altum viditur.

You mean videtur.

If you're going to ponce around like a pretentious dick, at least get it
right.

Sep 4 '08 #80

On 4 Sep 2008 at 9:02, jacob navia wrote:

Operator overloading is not an objective per se. It is a means of
making libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:

data[2]

to acces the third element of a list/array/other

Trouble is, you quickly end up pulling in a whole load of other stuff
too. You start out thinking how nice it is to be able to write

c=(a+b)*d;

instead of

mpf_add(c, a, b);
mpf_mul(c, c, d);

and then before you know it you've got overloaded functions because

b=sqrt(a);

is simpler than

mpf_sqrt(b, a);

Then it's iterators so that you can meaningfully overload ++ to index
your list/array/other...

And before you know it, you've got a horrible mess...

Sep 4 '08 #81

Antoninus Twink wrote:

On 4 Sep 2008 at 9:02, jacob navia wrote:
>Operator overloading is not an objective per se. It is a means of
making libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:

data[2]

to acces the third element of a list/array/other

Trouble is, you quickly end up pulling in a whole load of other stuff
too. You start out thinking how nice it is to be able to write

c=(a+b)*d;

This is nice

instead of

mpf_add(c, a, b);
mpf_mul(c, c, d);

That is ugly.

and then before you know it you've got overloaded functions because

b=sqrt(a);

is simpler than

mpf_sqrt(b, a);

lcc-win provides overloaded functions already. Not a big deal.

Then it's iterators so that you can meaningfully overload ++ to index
your list/array/other...

Surely not. That doesn't follow at all. Why it is so complicated
to write a loop?

And before you know it, you've got a horrible mess...

If you do not know how to stop!

Your argument is similar to this:

Antoninus: DO NOT DRINK MILK!!!!
Jacob: But... Why? Milk is tasteful and good for your health.
Antoninus: Yes, but then you drink 8 liters and you are DEAD!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 4 '08 #82

On 4 Sep 2008 at 17:14, jacob navia wrote:

Antoninus Twink wrote:
>And before you know it, you've got a horrible mess...

If you do not know how to stop!

Sure... unfortunately the main historical example is Bjarne Stroustoup,
who definitely didn't know how to stop!

Personally I see nothing wrong with writing
C-with-the-odd-nice-C++-feature and compiling it with a C++ compiler.

Sep 4 '08 #83

Kenny McCormack

In article <g9**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

>Kenny McCormack wrote in response to loony Eric Sosman:

>Calm down. Take your medicine. You'll feel better soon.

But then Jacob picked up the ball thusly:

>Kenny, you did not answer my post...

You consider C really dead?

I mean your opinion *is* important (at least to me)

Well, thank you for that.

Basically, my opinion is irrelevant (in this context). My purpose in
posting was to alert the newbie to the nature of this newsgroup. Sort
of a "newbie's guide to CLC. Despite the name, this is *not* a
technical newsgroup!". So, at least for the moment, I was parrotting
the view held by the regs (which is that it is for legacy and embedded
only, since their highly restrictive definition of what C is makes it
impossible to do anything interesting in it). This is the view held by
the CLC regs, aka, the Heathfield clique. Heathfield (et al) of course,
denies it all (lying as they always do).

In the "for what it is worth" department...
My own opinion on C is that it is still useful as a systems language
(that is, for building OSs and other useful tools), but since this is
completely outside the scope (read: off topic, not portable, blah, blah,
blah) of this NG, you're kinda stuck. Finally, no, I don't think that,
in 2008, C is an honest choice for new development at the purely
applications level.

Sep 4 '08 #84

Pilcrow

On Thu, 4 Sep 2008 17:57:32 +0000 (UTC), ga*****@shell.xmission.com
(Kenny McCormack) wrote:

>In article <g9**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>>Kenny McCormack wrote in response to loony Eric Sosman:

>>Calm down. Take your medicine. You'll feel better soon.

But then Jacob picked up the ball thusly:
>>Kenny, you did not answer my post...

You consider C really dead?

I mean your opinion *is* important (at least to me)

Well, thank you for that.

Basically, my opinion is irrelevant (in this context). My purpose in
posting was to alert the newbie to the nature of this newsgroup. Sort
of a "newbie's guide to CLC. Despite the name, this is *not* a
technical newsgroup!". So, at least for the moment, I was parrotting
the view held by the regs (which is that it is for legacy and embedded
only, since their highly restrictive definition of what C is makes it
impossible to do anything interesting in it). This is the view held by
the CLC regs, aka, the Heathfield clique. Heathfield (et al) of course,
denies it all (lying as they always do).

In the "for what it is worth" department...
My own opinion on C is that it is still useful as a systems language
(that is, for building OSs and other useful tools), but since this is
completely outside the scope (read: off topic, not portable, blah, blah,
blah) of this NG, you're kinda stuck. Finally, no, I don't think that,
in 2008, C is an honest choice for new development at the purely
applications level.

But a knowledge of C seems to be a prerequisite for learning some other
things, such as Win32, various GUIs, certain modules in Perl, etc. which
are useful for applications.

----
Everybody needs somebody that they can look down on.
If you ain't got noone else, why, help yourself to me.

Sep 4 '08 #85

Bartc

"James Kuyper" <ja*********@verizon.netwrote in message
news:AlPvk.565$Wd.61@trnddc01...

Bartc wrote:
>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>>jacob navia <ja***@nospam.comwrites:

>>>C is good only for systems work, etc etc, new development or
application dveelopment should be done in better languages, etc.

Which, one more time, is not what he said.

Er, I think he did:

"
It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.
"

Once again, you're converting non-absolute statements into absolute ones.
To show you how you've misinterpreted, I'll rewrite it so that it actually
supports your misinterpretation:

DISCLAIMER: THIS IS NOT MY OPINION - IT IS NOT DOUG'S OPINION - IT IS NOT
ANYONE'S OPINION, AFAIK:
"It is a mistake to try to push C (in any variant) as a solution for any
programming problem other than the systems programming tasks that it was
designed for, although it still has deficiencies even for that. Time spent
discussing directions for C should be exclusively spend on remedying its
remaining deficiencies for systems work, and not on trying to support
applications where there is always a better choice."

Can you see the difference between my re-write and what he actually said?
Do you understand that your statements apply only to my rewrite, and not
to the original? I only changed a few words, but the result is that it
converts a legitimate point of view (which I don't fully share) into a
statement that could only be made by an idiot.

It's not too hard to read between the lines of the original. Clearly he has
the skills to put across what he thinks without making any hard and fast
commitments. Tact and diplomacy I think it's called.

But the same ideas have been expressed by others in this thread. So in the
clc world at least Jacob seems to be fighting a losing battle in getting any
official support for his work.

--
Bartc

Sep 4 '08 #86

Pilcrow said:

On Thu, 4 Sep 2008 17:57:32 +0000 (UTC), ga*****@shell.xmission.com
(Kenny McCormack) wrote:

<snip>

>>Finally, no, I don't think that,
in 2008, C is an honest choice for new development at the purely
applications level.

But a knowledge of C seems to be a prerequisite for learning some other
things, such as Win32, various GUIs, certain modules in Perl, etc. which
are useful for applications.

Right. It's also a really-nice-to-have for reading technical docs, since
they are often illustrated with C fragments (cases in point:
Aho-Sethi-Ullman (the Dragon Book), Petzold (Programming Windows), Knuth
(TAOCP)). It's good for writing libraries, since so many languages can
link to C libraries nowadays.

And of course it's good for new development at the applications level, if
it's the language that suits you best for that need. For some, it's the
right choice. For others, it isn't. Sweeping generalisations need not
apply.

BTW before taking Kenny McCormack too seriously, check out his technical
contributions to this group (if you can find any).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 4 '08 #87

Malcolm McLean

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

>
And of course it's good for new development at the applications level, if
it's the language that suits you best for that need. For some, it's the
right choice. For others, it isn't. Sweeping generalisations need not
apply.

You don't want lots of languages swilling about your development
environment. Personally I like almost everything in C. However I will knock
up a few Perl scripts to avoid hardcoding paths into C source - they seldom
do anything much I couldn't do as easily in C - and then I've got legacy
Fortran 77 to "maintain".

You get into the way of Fortran 77 coding after a while. Basically you've
got do loops, arrays, if blocks, and gotos. Nothing much else. It's a very
pure programming experience.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 4 '08 #88

Malcolm McLean

"Richard Heathfield" <rj*@see.sig.invalidwrote in message news

Malcolm McLean said:

>I trust you are now joining the campaign for 64 bit ints.

Why? They're legal already. In any case, one day they will be too small.

Think the campaign for real ale rather than the campaign to free the weed.

I don't think we will actually run out of integers with 64 bits. With 32
bits yes, you can't quite give one to everyone in the world. But 64 bits
aren't going to have that problem for a long time yet.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 4 '08 #89

Lassie

"jacob navia" <ja***@nospam.comschreef in bericht
news:g9**********@aioe.org...

Ian Collins wrote:
>Richard Heathfield wrote:
>>Ian Collins said:

So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.
Actually, the really worthwhile changes are never going to happen. For
example, I do actually think it would be worth adding operator
overloading to C - but I know that ISO is never going to buy that, and I
don't see any point in fighting a losi... well, not /that/ losing
battle, anyway.

I'm sure they would be, but how many embedded C compiler vendors are
offering operator overloading as an extension?

Operator overloading is not an objective per se. It is a means of making
libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:

data[2]

to acces the third element of a list/array/other

I really would not implement operator[] for a linked list. operator[] has
the semantics of being a random access operator. A linked list is not a data
stucture one would use when random access is needed and operator[] would
have to loop to the correct index every time which is suddenly invisible
from the programmer.

Sep 4 '08 #90

Lassie wrote:

>
"jacob navia" <ja***@nospam.comschreef in bericht
news:g9**********@aioe.org...
>Ian Collins wrote:
>>Richard Heathfield wrote:
Ian Collins said:

So my point is C fills its (large) niche very well and the only
worthwhile changes are small improvements (like mandating function
prototypes and expunging gets) to improve the quality of C code.
Actually, the really worthwhile changes are never going to happen.
For example, I do actually think it would be worth adding operator
overloading to C - but I know that ISO is never going to buy that,
and I don't see any point in fighting a losi... well, not /that/
losing battle, anyway.

I'm sure they would be, but how many embedded C compiler vendors are
offering operator overloading as an extension?

Operator overloading is not an objective per se. It is a means of making
libraries that use lists, flexible arrays and other sequential
containers interoperable using the same notation:

data[2]

to acces the third element of a list/array/other

I really would not implement operator[] for a linked list. operator[]
has the semantics of being a random access operator. A linked list is
not a data stucture one would use when random access is needed and
operator[] would have to loop to the correct index every time which is
suddenly invisible from the programmer.

Well, if you are using a list and you need the nth element you will
have to start at the start and go to the nth. That is because of the
data structure used.

When you see that you are accessing random elements you change your
declaration to a flexible array and you have more efficient random
access. And you do not need to change the code.

I agree that operator overloading has its drawbacks within this context.

Specially because even if it *can* be used to standardize access to
sequential containers, it needs furthe standards to be able to define
the operations in a meaningful way (like First, next, last, etc).

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 4 '08 #91

Antoninus Twink <no****@nospam.invalidwrote:

>
Trouble is, you quickly end up pulling in a whole load of other stuff
too. You start out thinking how nice it is to be able to write

c=(a+b)*d;

instead of

mpf_add(c, a, b);
mpf_mul(c, c, d);

and then before you know it you've got overloaded functions because

b=sqrt(a);

is simpler than

mpf_sqrt(b, a);

Then it's iterators so that you can meaningfully overload ++ to index
your list/array/other...

And before you know it, you've got a horrible mess...

You mean C++? ;-)
--
Larry Jones

My brain is trying to kill me. -- Calvin

Sep 4 '08 #92

Richard Heathfield <rj*@see.sig.invalidwrote:

>
No, I would not be so foolish as to attack you for daring to propose a
change to the C language. I'm just curious as to why you propose it here,
since nobody here has any authority to change the language definition
(except Larry, perhaps, since he's actually a voting member of the ISO C
Committee). It seems rather pointless.

Actually, at the moment I'm not a voting member of the committee. I am,
however, the document editor. Which role provides more *authority* to
change the language definition I can't say, but the latter role
certainly provides more *opportunity* to do so. :-)
--
Larry Jones

I hate being good. -- Calvin

Sep 4 '08 #93

jacob navia <ja***@nospam.comwrote:

>
How would you make different libraries interoperate with lists,
flexible arrays, arrays, double linked lists, etc?

Like the old joke says: If I were going there, I wouldn't be starting
from here.
--
Larry Jones

Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin

Sep 4 '08 #94

jacob navia <ja***@nospam.comwrote:

>
I need 10 thousand euros (15 000 US$) to buy the AFNOR
(French ISO organization) to present my proposal after
I got sponsored by some company.

That's not necessary -- committee meetings are open to the public.
Anyone is welcome to attend and participate in the discussions and even
straw votes, just not formal votes. Requests for agenda time (e.g., for
a presentation) are normally granted, particularly when made reasonably
in advance. The committee even tries to meet in a variety of locations
to make it easier for people to attend.
--
Larry Jones

How am I supposed to learn surgery if I can't dissect anything? -- Calvin

Sep 4 '08 #95

la************@siemens.com said:

<snip>

Actually, at the moment I'm not a voting member of the committee. I am,
however, the document editor. Which role provides more *authority* to
change the language definition I can't say, but the latter role
certainly provides more *opportunity* to do so. :-)

"He who drafts the document wins the day" - Jay and Lynn, in "Yes,
Minister"

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 4 '08 #96

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:
>How would you make different libraries interoperate with lists,
flexible arrays, arrays, double linked lists, etc?

Like the old joke says: If I were going there, I wouldn't be starting
from here.

Very funny.

If you wanted to go there you would not use C isn't it?

Obvious. This is comp.lang.c.

The basic assumption here seems to be
"Any software development should be done in C++". We are here to
(1) remain people not to cast malloc().
(2) The prototype of main is
int main (void)
NOT
void main(void)
(3) i = i++; is not a good idea.
And that was it.

Any serious proposal for discussion meets the same fate.

VERY FUNNY.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 4 '08 #97