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

Why the C committee doesn't provide an implementation when the standard is published?

P: n/a
Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?

C works on the abstract model of low level machine. C stands for
portability and platform and machine independent. If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough? The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?

The standard implementation will never stop various non-standard
implementations from being produced by individual person or
organization. If all the programmers can have the standard
implementation as soon as the language standard is released, then all
programs can be written following the standard freely and strictly.
--
lovecreatesbeauty

Jun 9 '06 #1
Share this Question
Share on Google+
52 Replies


P: n/a
lovecreatesbeauty wrote:
Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?
Because it's not their job?
C works on the abstract model of low level machine. C stands for
portability and platform and machine independent. If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough? The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?

Some standard library functions can't be implemented in C, or at least
can't be optimally implemented in C.

It might be fun to define the standard library as a set of unit tests.

--
Ian Collins.
Jun 9 '06 #2

P: n/a
>Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?
To run under what, the "Standard OS" on the "Standard Hardware"?
It isn't the job of a standards committee to produce an implementation.
C works on the abstract model of low level machine. C stands for
portability and platform and machine independent.
But an *implementation* is not going to be platform and machine
independent.
If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough?
No, if it's expected to produce native machine code.
The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?
No. Do the people who write building codes build buildings?
The standard implementation will never stop various non-standard
implementations from being produced by individual person or
organization. If all the programmers can have the standard
implementation as soon as the language standard is released, then all
programs can be written following the standard freely and strictly.


One of the potential problems of a "standard implementation" would
be that an extension (or incomplete error checking) in the "standard
implementation" would tend to become a de facto "standard extension"
when that may not have been intended by the standards committee.
The standard, not a "standard implementation" defines the language.

Gordon L. Burditt
Jun 9 '06 #3

P: n/a
Gordon Burditt wrote:
The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document?

No. Do the people who write building codes build buildings?


It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler. Is it / standard not important? If
not, why the standard committee is very important and people need it?

Jun 9 '06 #4

P: n/a
lovecreatesbeauty said:
Gordon Burditt wrote:
>The standard
>implementation is published by the international standard committee. Is
>it to hurried for the committee to do it? Does the committee take no
>responsibility for publishing a standard implementation when release
>the paper language document? No. Do the people who write building codes build buildings?


It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.


C99, yes. Please note, however, that C89 was a very different matter.
Vendors were rushing to conform to it, and most had conforming compilers
even before the ink was dry, because they'd been following the
standardisation process very closely. C89 mattered - and still matters.
Is it / standard not important?
C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.
If
not, why the standard committee is very important and people need it?


That's an excellent question. Perhaps someone from the committee would like
to answer it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 9 '06 #5

P: n/a
Richard Heathfield <in*****@invalid.invalid> writes:
lovecreatesbeauty said:

[...]
Is it / standard not important?


C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.


C89 (or C90) caught on as quickly as it did because there was a great
demand for a standard. When C99 was issued, there was already a
standard that worked well, so there was less demand for a new one.
But there are a *few* implementations that conform to C99, and more
that implement parts of C99.

If nothing else, the C99 standard provides a direction for development
beyond C90. For example, a C compiler vendor wants to implement
complex numbers will almost certainly do so using the syntax defined
by the C99 standard, rather than inventing something else.
--
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.
Jun 9 '06 #6

P: n/a
In article <f7********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
lovecreatesbeauty said:
Gordon Burditt wrote:
>The standard
>implementation is published by the international standard committee. Is
>it to hurried for the committee to do it? Does the committee take no
>responsibility for publishing a standard implementation when release
>the paper language document?
No. Do the people who write building codes build buildings?


It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.


C99, yes. Please note, however, that C89 was a very different matter.
Vendors were rushing to conform to it, and most had conforming compilers
even before the ink was dry, because they'd been following the
standardisation process very closely. C89 mattered - and still matters.


Actually ISO C90+A1 and the TC's..ie C95/6 This is where most compilers
are. Generally they have taken a few items from C99 but not many.
Is it / standard not important?


C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.

I agree.
If
not, why the standard committee is very important and people need it?


That's an excellent question. Perhaps someone from the committee would like
to answer it.


AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee :-)

Several high profile committee members have said they wished certain
areas had not been included and that C99 has "lost it's way". The
evidence is that the main compiler vendors have not implemented it.

You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.

BTW There is no such language as C/C++. C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99. So C written
in a C++ compiler is not C.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.

GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.

The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard. In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.

So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.

However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++ and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.

Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #7

P: n/a
Chris Hills wrote:
AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee :-)


Notice that the oft-quoted line about the horse designed by a committee
is a poor substitute for a real argument. In particular, notice that the
most successful translation of the Bible ever, the Authorized / King
James Version, is the quintessential committee-designed translation.
Jun 9 '06 #8

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
Richard Heathfield <in*****@invalid.invalid> writes:
lovecreatesbeauty said:[...]
Is it / standard not important?


C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.


C89 (or C90) caught on as quickly as it did because there was a great
demand for a standard.


Yes
When C99 was issued, there was already a
standard that worked well, so there was less demand for a new one.
True. also there was NO demand by the majority for a lot of the features
that were added.
But there are a *few* implementations that conform to C99,
I think 50% (ie three of them) were for political reasons only.
and more
that implement parts of C99.
I think "everyone" has implemented a few bits of C99. Though they have
ignored a LOT more than they have implemented.
If nothing else, the C99 standard provides a direction for development
beyond C90.
Not really.
For example, a C compiler vendor wants to implement
complex numbers will almost certainly do so using the syntax defined
by the C99 standard, rather than inventing something else.


Maybe. Maybe not. There are some features of the C standard that are
broken anyway. No one is really going to implement these or use them as
a base.

Several ISO C panel members have called for going back to C95 and
starting again.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #9

P: n/a
jjf

lovecreatesbeauty wrote:
Gordon Burditt wrote:
The standard
implementation is published by the international standard committee. Is
it to hurried for the committee to do it? Does the committee take no
responsibility for publishing a standard implementation when release
the paper language document? No. Do the people who write building codes build buildings?


It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.


Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.
Is it / standard not important?
It is important.
If not, why the standard committee is very important and people need it?


Jun 9 '06 #10

P: n/a
In article <4e*************@individual.net>, Martin Ambuhl
<ma*****@earthlink.net> writes
Chris Hills wrote:
AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee :-)
Notice that the oft-quoted line about the horse designed by a committee
is a poor substitute for a real argument.


Hence the :-)
In particular, notice that the
most successful translation of the Bible ever, the Authorized / King
James Version, is the quintessential committee-designed translation.


That was political.... Besides it depends how you define "successful" in
this case. But that is very much OT.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #11

P: n/a
In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes

lovecreatesbeauty wrote:
Gordon Burditt wrote:
> >The standard
> >implementation is published by the international standard committee. Is
> >it to hurried for the committee to do it? Does the committee take no
> >responsibility for publishing a standard implementation when release
> >the paper language document?
> No. Do the people who write building codes build buildings?


It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.


Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.


They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO. Ie ISO9899:1999 (any other version of ISO9899 is
OBSOLETE)
Is it / standard not important?


It is important.


Why?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #12

P: n/a
Chris Hills said:
In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes

lovecreatesbeauty wrote:

It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.
Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.


They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO.


But as far as the Real World is concerned, they /are/ conforming
implementations. For as long as the ISO C committee could carry the Real
World with it, the distinction between ISO's view and that of the Real
World was irrelevant. But because they can no longer do that, it has become
very relevant indeed.
Ie ISO9899:1999 (any other version of ISO9899 is OBSOLETE)


Only as far as ISO is concerned.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 9 '06 #13

P: n/a
Chris Hills wrote:
In article <4e*************@individual.net>, Martin Ambuhl
<ma*****@earthlink.net> writes
Chris Hills wrote:
AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee :-)

Notice that the oft-quoted line about the horse designed by a committee
is a poor substitute for a real argument.


Hence the :-)
In particular, notice that the
most successful translation of the Bible ever, the Authorized / King
James Version, is the quintessential committee-designed translation.


That was political.... Besides it depends how you define "successful" in
this case. But that is very much OT.


To dominate the religious and literary life of English speakers from
1660, when the Geneva Bible, last printed in 1644 was suppressed by the
same regime that reintroduced such civilized touches as the censorship
and compulsory Sunday service attendance, until at least 1952, when the
RSV was introduced is more successful than anything that any of us can
claim, I assure you. You need an extremely perverse definition of
"successful" to find any translation of the Bible that was more successful.
Jun 9 '06 #14

P: n/a
Martin Ambuhl <ma*****@earthlink.net> writes:
You need an extremely perverse definition of "successful" to find
any translation of the Bible that was more successful.


The Vulgate :-)

Yours,

--
Jean-Marc
Jun 9 '06 #15

P: n/a
In article <4e*************@individual.net>, Martin Ambuhl
<ma*****@earthlink.net> writes
Chris Hills wrote:
In article <4e*************@individual.net>, Martin Ambuhl
<ma*****@earthlink.net> writes
Chris Hills wrote:

AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee :-)
Notice that the oft-quoted line about the horse designed by a committee
is a poor substitute for a real argument.


Hence the :-)
In particular, notice that the
most successful translation of the Bible ever, the Authorized / King
James Version, is the quintessential committee-designed translation.


That was political.... Besides it depends how you define "successful" in
this case. But that is very much OT.


To dominate the religious and literary life of English speakers from
1660, when the Geneva Bible, last printed in 1644 was suppressed by the
same regime that reintroduced such civilized touches as the censorship
and compulsory Sunday service attendance, until at least 1952, when the
RSV was introduced is more successful than anything that any of us can
claim, I assure you. You need an extremely perverse definition of
"successful" to find any translation of the Bible that was more successful.


It was successful in much the same way the Colombian drugs cartels are.
They spread their stuff far and wide.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #16

P: n/a
In article <6a********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes

lovecreatesbeauty wrote:

It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.

Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.
They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO.


But as far as the Real World is concerned, they /are/ conforming
implementations.


In which case as far as the real world is concerned any of the compilers
that people want to discuss here are also C compilers.... You can't have
it both ways.
For as long as the ISO C committee could carry the Real
World with it, the distinction between ISO's view and that of the Real
World was irrelevant.
Agreed.
But because they can no longer do that, it has become
very relevant indeed.


I agree.
Ie ISO9899:1999 (any other version of ISO9899 is OBSOLETE)


Only as far as ISO is concerned.


AND BSI.... Took me a hell of a time to get them to make the C95 version
available again! They were very pleased when sales of C95 in the last
three years out striped the total sales of C99 at BSI :-)

However BSI have now run out of their copies of C95 :-( the ISO version
is Obsolete and very expensive. (over 150USD) So I am working on getting
it published at a far lower rate. It is going to take a while but I am
working on it.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #17

P: n/a
Chris Hills said:
In article <6a********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes

lovecreatesbeauty wrote:
>
> It is the fact for C language that the standard committee published
> 100% standard compliant paper document. 10 years later, there is no
> 100% standard compliant compiler.

Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.

They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO.


But as far as the Real World is concerned, they /are/ conforming
implementations.


In which case as far as the real world is concerned any of the compilers
that people want to discuss here are also C compilers.... You can't have
it both ways.


Well, clc isn't *exactly* the real world. :-) But to take your point more
seriously, my understanding of the consensus of regular contributors on clc
topicality is that K&R C is topical, as is any subsequent formal
standardisation by ISO. So, currently, K&R C, ISO C90, its subsequent
corrigenda and amendments, ISO C99, and /its/ subsequent corrigenda and
amendments, are all topical. And unless the consensus changes dramatically,
they will all remain so.
Ie ISO9899:1999 (any other version of ISO9899 is OBSOLETE)


Only as far as ISO is concerned.


AND BSI.... Took me a hell of a time to get them to make the C95 version
available again! They were very pleased when sales of C95 in the last
three years out striped the total sales of C99 at BSI :-)


And that in itself shows that C95 is far from obsolete. After all, you don't
buy a copy of the Standard unless you have correctness or portability
concerns - so if C95 is selling well, it shows that people consider it to
be an authority on correctness and portability.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 9 '06 #18

P: n/a
In article <N8******************************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
In article <6a********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:

In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes
>
>lovecreatesbeauty wrote:
>>
>> It is the fact for C language that the standard committee published
>> 100% standard compliant paper document. 10 years later, there is no
>> 100% standard compliant compiler.
>
>Nonsense. There are many C compilers which are 100% compliant to the C
>Standards from 1996 and earlier.

They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO.

But as far as the Real World is concerned, they /are/ conforming
implementations.
In which case as far as the real world is concerned any of the compilers
that people want to discuss here are also C compilers.... You can't have
it both ways.


Well, clc isn't *exactly* the real world. :-)


exactly. :-)
But to take your point more
seriously, my understanding of the consensus of
some of the
regular contributors on clc
topicality is that K&R C is topical, as is any subsequent formal
standardisation by ISO. So, currently, K&R C, ISO C90, its subsequent
corrigenda and amendments, ISO C99, and /its/ subsequent corrigenda and
amendments, are all topical. And unless the consensus changes dramatically,
they will all remain so.
the rest of us widen it to include all C compilers.
Ie ISO9899:1999 (any other version of ISO9899 is OBSOLETE)

Only as far as ISO is concerned.


AND BSI.... Took me a hell of a time to get them to make the C95 version
available again! They were very pleased when sales of C95 in the last
three years out striped the total sales of C99 at BSI :-)


And that in itself shows that C95 is far from obsolete.


In the real world that is the case. In fact ISO C95/6 *IS* the
standard.
After all, you don't
buy a copy of the Standard unless you have correctness or portability
concerns - so if C95 is selling well, it shows that people consider it to
be an authority on correctness and portability.


Yes. It is also why MISRA-C is based on C90. MISRA has to work in
reality.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 9 '06 #19

P: n/a
Chris Hills wrote:
In article <f7********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
lovecreatesbeauty said:
Gordon Burditt wrote:
> The standard
> implementation is published by the international standard committee. Is
> it to hurried for the committee to do it? Does the committee take no
> responsibility for publishing a standard implementation when release
> the paper language document?
No. Do the people who write building codes build buildings?
It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler. C99, yes. Please note, however, that C89 was a very different matter.
Vendors were rushing to conform to it, and most had conforming compilers
even before the ink was dry, because they'd been following the
standardisation process very closely. C89 mattered - and still matters.


Actually ISO C90+A1 and the TC's..ie C95/6 This is where most compilers
are. Generally they have taken a few items from C99 but not many.
Is it / standard not important?

C89 is vital. But C99? No, not really. Otherwise, we'd have more conforming
implementations by now.

I agree.
If
not, why the standard committee is very important and people need it?

That's an excellent question. Perhaps someone from the committee would like
to answer it.


AFAIK C99 was a "committee designed animal". Ie the Camel is a horse
designed by a committee :-)

Several high profile committee members have said they wished certain
areas had not been included and that C99 has "lost it's way". The
evidence is that the main compiler vendors have not implemented it.

You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.

BTW There is no such language as C/C++. C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99. So C written
in a C++ compiler is not C.

I would have objected strenuously to this before this morning. Now I
don't quite know what to think about this garbage on my clipboard:
Compiling...
Text1.c
C:\MSDEV\Projects\tja15\Text1.c(14) : error C2143: syntax error : missing
';' before 'type'
C:\MSDEV\Projects\tja15\Text1.c(15) : error C2065: 'c' : undeclared
identifier
Error executing cl.exe.
Text1.obj - 2 error(s), 0 warning(s)
/* end output of cl.exe; begin source */
#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
int a =SIX;
int b =NINE;
printf("In main SIX is %d while NINE is %d\n", a ,b);
/* int c = (1 + 5 * 8 + 1);*/
/* int c; */
int c;
c = 8;

/*printf("Is the culprit the grouping? %d\n", c); */
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

/* end source */
The Germans are telling me that I can't have the declaration after the
printf, a feature demanded by C99. Furthermore, I found out that arctan
of a float is defined in math.h for this implementation although this
requirement didn't exist in '94 or so when I bought it. I don't know
what all that means, but I think it means something.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.

GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.

The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard. In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.

So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.

However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++ and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.

Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.

When Dr. Feynmann presented QED to a room including Pauli and Einstein,
the former suggested that it interfered with the latter's relativity
theory, to which Professor Einstein replied, "the theory is still so
new." When the zero-option was proposed, nobody took it seriously until
Reykjavik, when it was implemented. Point is, history takes a long
time. frank
--------
The existence of the Lutherbibel allowed for the King James.
Jun 9 '06 #20

P: n/a
On 8 Jun 2006 20:40:08 -0700, in comp.lang.c , "lovecreatesbeauty"
<lo***************@gmail.com> wrote:
Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?


Why doesn't the government build a car once they publish emission
laws? Why doesn't the FA own football clubs, once it publishes the
rules? Why don't business analysts develop software, once they've
written the spec?

Answer: the task of definiing how to do something, and the task of
building it, are rightly separate jobs.
--
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
Jun 9 '06 #21

P: n/a
jjf

Chris Hills wrote:
In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes

lovecreatesbeauty wrote:
Gordon Burditt wrote:
> >The standard
> >implementation is published by the international standard committee. Is
> >it to hurried for the committee to do it? Does the committee take no
> >responsibility for publishing a standard implementation when release
> >the paper language document?
> No. Do the people who write building codes build buildings?

It is the fact for C language that the standard committee published
100% standard compliant paper document. 10 years later, there is no
100% standard compliant compiler.


Nonsense. There are many C compilers which are 100% compliant to the C
Standards from 1996 and earlier.


They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO. Ie ISO9899:1999 (any other version of ISO9899 is
OBSOLETE)


Agreed. So what? As quoted above, I was responding to the OP's claim
that there are no C compilers which are 100% compliant to the C
Standards as they were 10 years ago.
Is it / standard not important?


It is important.


Why?


Because people who want to write portable code need a standard to do
so, and clearly need compilers which implement that standard. The fact
that C90 and C95 are no longer ISO Standards is not relevant to
anything in the real world. They are very well defined ex-standards
which many compilers implement fully and correctly (and they conformed
to the Standards for as long as those Standards existed, and still
would if the Standards were magically to come back into existence).

The fact that earlier Standards become non-Standard and obsolete when a
new version is published is one of the bigger sillinesses of the ISO
process. The real world almost invariably lags the ISO process in
conformance terms, often by many years. There's no real reason why
compilers couldn't continue to claim formal compliance to the C90
Standard (say) instead of the current theoretical (and silly, and
ignored) situation that all C compilers stopped being Standard C
compilers the moment C99 was published.

Few (if any) Standard C compilers (as formally interpreted by ISO) now
exist, and it looks rather like few ever will unless the C committee
comes to its senses. "Standard C" does exist in the real world,
however, and is defined in terms of conformance to C90, C95, or
whatever.

Jun 10 '06 #22

P: n/a
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:8B**************@phaedsys.demon.co.uk...
You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.
But they still offer a compiler used by millions of C programmers.
BTW There is no such language as C/C++.
Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...
C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99.
Perhaps, but Standard C++ is based on C95. And the next revison of C++
(aka C++0X) has already adopted the *entire* C99 preprocessor, the
*entire* C99 library, and quite a number of C99 language features.
Posix also now requires C99. Maybe the way isn't all that different
in the end.
So C written
in a C++ compiler is not C.
Right, as is often pointed out in the heated subset/superset debates
that erupt spontaneously from time to time. But they're demonstrably
fellow travelers.
Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction
Well, yes, but they seem to have gotten religion about standards
conformance lately. They haven't done export for C++ yet (because
it's damned hard and next to nobody is asking for it) but they have
yet to proclaim they *aren't* going to do it. Similarly, they have
quite good conformance to C90 and C95, and haven't done C99 (because
once again it takes a lot of work and next to nobody is asking for it).
added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.
Mostly true, except for the compiler vendors (desktop and embedded) who
use the EDG front end and Dinkumware libraries, who get full C99 and C++
compliance for free. They don't brag about it because, as mentioned above,
it ain't a selling point.
GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.
There are many claims about various features of C and C++, with
dubious "real world" justification. Works for me.
The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard.
No, they've got a bad reputation for saying NO! to damn near everything,
including things they once promised to support. *Nothing* normative has
been added to Standard C since C99 and nothing of that sort is currently
planned. Where's the beef?
In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.
"Considered briefly and properly rejected" is how I'd characterize it.
So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.
Probably true, and you should note that the C committee is cooperating
in this approach by working diligently on DRs and not starting a revision
of C99. Where's the beef?
However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++
ECMA has standardized an extension to C++ that's highly compatible with
Standard C++, if that's what you mean.
and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.
Could be, but there seem to be people actively implementing what the
C++ committee is standardizing. And in our (Dinkumware's) experience,
there seems to be at least some market for the major additions. The
wilderness isn't empty.
Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.


Could also be, but if so neither you nor I will "get them back" just
by advancing our own notions of where "back" might be.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 10 '06 #23

P: n/a


Chris Hills wrote:

<snip>
In short no one really needed the new features of C99.


I disagree and I am a bit confused why people are so unhappy about the
C99 standard. I am no expert and I recognise that when people like
Richard Heathfield are not convinced that C99 is any good I should not
either. Also, it is mentioned that some parts may even be broken.
Nevertheless, features like mixed declarations and code, isnan, isinf,
__func__ , variable-length arrays, etc is really nice and in my opinion
very very useful.

The C community is extremely large and every programmer has their own
opinion about how things should be done. Maybe people are even a bit
affectionate about the language and do not wish to see it ruined or
moved in a direction that they do not want it to. But if no one makes
any compromises, no new standard will ever be adopted and the standard
C language will stop at C89.

Regards, Jesper

Jun 10 '06 #24

P: n/a
Jesper wrote:

Chris Hills wrote:

<snip>
In short no one really needed the new features of C99.


I disagree and I am a bit confused why people are so unhappy about the
C99 standard. I am no expert and I recognise that when people like
Richard Heathfield are not convinced that C99 is any good I should not
either. Also, it is mentioned that some parts may even be broken.
Nevertheless, features like mixed declarations and code, isnan, isinf,
__func__ , variable-length arrays, etc is really nice and in my opinion
very very useful.

The C community is extremely large and every programmer has their own
opinion about how things should be done. Maybe people are even a bit
affectionate about the language and do not wish to see it ruined or
moved in a direction that they do not want it to. But if no one makes
any compromises, no new standard will ever be adopted and the standard
C language will stop at C89.

The C community is not sufficiently large that things can 'should'.
Only persons can 'should' and Hume's is-ought gap looms as large as
ever. I've now read parts of n1124.pdf and I really don't know what to
think about the normative question. If clc solved it, they would be the
first to do so. frank
Jun 10 '06 #25

P: n/a
In article <11**********************@h76g2000cwa.googlegroups .com>,
jj*@bcs.org.uk writes

Chris Hills wrote:
In article <11**********************@i40g2000cwc.googlegroups .com>,
jj*@bcs.org.uk writes
>
>lovecreatesbeauty wrote:
>> Gordon Burditt wrote:
>> > >The standard
>> > >implementation is published by the international standard committee. Is
>> > >it to hurried for the committee to do it? Does the committee take no
>> > >responsibility for publishing a standard implementation when release
>> > >the paper language document?
>> > No. Do the people who write building codes build buildings?
>>
>> It is the fact for C language that the standard committee published
>> 100% standard compliant paper document. 10 years later, there is no
>> 100% standard compliant compiler.
>
>Nonsense. There are many C compilers which are 100% compliant to the C
>Standards from 1996 and earlier.
They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO. Ie ISO9899:1999 (any other version of ISO9899 is
OBSOLETE)


Agreed. So what? As quoted above, I was responding to the OP's claim
that there are no C compilers which are 100% compliant to the C
Standards as they were 10 years ago.
>> Is it / standard not important?
>
>It is important.


Why?


Because people who want to write portable code


I rarely see portability high on anyone's list out side C.l.c
need a standard to do
so, and clearly need compilers which implement that standard. The fact
that C90 and C95 are no longer ISO Standards is not relevant to
anything in the real world.
It is VERY relevant. In a legal sense in some areas.
They are very well defined ex-standards
which many compilers implement fully and correctly (and they conformed
to the Standards for as long as those Standards existed, and still
would if the Standards were magically to come back into existence).
This is true
The fact that earlier Standards become non-Standard and obsolete when a
new version is published is one of the bigger sillinesses of the ISO
process.
Yes and no. The new one has to supersede the old and in some cases there
are legal requirements to use the current ISO standard. ISO does a lot
more than programming languages.
The real world almost invariably lags the ISO process in
conformance terms, often by many years. There's no real reason why
compilers couldn't continue to claim formal compliance to the C90
Standard (say) instead of the current theoretical (and silly, and
ignored) situation that all C compilers stopped being Standard C
compilers the moment C99 was published.
I agree completely so I got BSI C95 reissued at a sensible price.
Unfortunately they have not run out so I am doing a deal to get the ISO
version revised at a sensible price. It is currently over 150USD
Few (if any) Standard C compilers (as formally interpreted by ISO) now
exist, and it looks rather like few ever will unless the C committee
comes to its senses.
I agree.
"Standard C" does exist in the real world,
however, and is defined in terms of conformance to C90, C95, or
whatever.


I agree, that is the reality that is the practical answer but legally
C99 is the standard and this can cause problems.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 10 '06 #26

P: n/a
Chris Hills said:

<snip>
C99 is the standard and this can cause problems.


Gotta love selective quotation.

<g,d&r>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 10 '06 #27

P: n/a
In article <3d******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:8B**************@phaedsys.demon.co.uk...
You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.
But they still offer a compiler used by millions of C programmers.


I agree. It is THE de-facto standard on the desktop. That is my point.
Most desktop "C" programmers are in fact using a C++ compiler. As you
have pointed out recently the current crop of MS compilers are very good
and do adhere to the C++ standards.
BTW There is no such language as C/C++.


Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...


I can also find millions of hits to show that Elvis lives, Roswell was a
fake AND that it was real aliens, That the Davinci code is ALL real and
all fake. Also that there are WMD in Iraq... Just because lots of
people believe it does not make it true.

Just because you can find millions of hits on google proves absolutely
nothing. I think it was Robert HeinLein who said "never underestimate
the power of human stupidity".

C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99.


Perhaps, but Standard C++ is based on C95.


OK and C95 != C99.
And the next revison of C++
(aka C++0X) has already adopted the *entire* C99 preprocessor, the
*entire* C99 library, and quite a number of C99 language features.
That is the *next* version of C++ BTW when is it due out?
Posix also now requires C99. Maybe the way isn't all that different
in the end.
So C written
in a C++ compiler is not C.
Right, as is often pointed out in the heated subset/superset debates
that erupt spontaneously from time to time. But they're demonstrably
fellow travelers.


Close yes but not the same.
Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction
Well, yes, but they seem to have gotten religion about standards
conformance lately.


Yes, they have put a lot of work into ECMA and as you have pointed out
become a lot more ISO compliant.
They haven't done export for C++ yet (because
it's damned hard and next to nobody is asking for it)
This is a bit of a recurring theme where no one is pushing for
compatibility with the latest standards.
but they have
yet to proclaim they *aren't* going to do it. Similarly, they have
quite good conformance to C90 and C95, and haven't done C99 (because
once again it takes a lot of work and next to nobody is asking for it).
This is where we all came in. Why does no one (very few) want C99
conformance?
added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.


Mostly true,


thanks :-)
except for the compiler vendors (desktop and embedded) who
use the EDG front end and Dinkumware libraries, who get full C99 and C++
compliance for free.
I know. AFAIK most of the major embedded compilers use that combination.
See http://www.edg.com & http://www.dinkumware.com I will put the
advert in for you :-)

As you say they do give C99 but.....
They don't brag about it because, as mentioned above,
it ain't a selling point.
though AFAIK not all of the embedded implimenters do a full C99 back
end.
GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.


There are many claims about various features of C and C++, with
dubious "real world" justification. Works for me.


What works for you?

The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard.


No, they've got a bad reputation for saying NO! to damn near everything,
including things they once promised to support.


I know. Bloody nightmare. But probably not the place to go into it in
detail.
*Nothing* normative has
been added to Standard C since C99 and nothing of that sort is currently
planned. Where's the beef?
Ask the usual suspects.... Though one or two seem to have given up and
wandered off.

In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.


"Considered briefly and properly rejected" is how I'd characterize it.


OK. Though you have said there are parts of C99 you wish had not been
put in.
So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.


Probably true, and you should note that the C committee is cooperating
in this approach by working diligently on DRs and not starting a revision
of C99. Where's the beef?


They were arguing against adding any TR's or anything else until all the
DR's had been fixed. Also that is Nick's worries about the whole maths
model.
However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++


ECMA has standardized an extension to C++ that's highly compatible with
Standard C++, if that's what you mean.


:-) Let's leave that can un-opened. the last thread on it ran to
hundreds of posts and had more heat than light. I can see both sides of
the argument.
and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.


Could be,
but there seem to be people actively implementing what the
C++ committee is standardizing. And in our (Dinkumware's) experience,
there seems to be at least some market for the major additions. The
wilderness isn't empty.


That's good. However as MS is the defacto standard on the desktop and
they are going ECMA C++/CLI isn't that where the vast majority of C++
users will go?
Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.


Could also be, but if so neither you nor I will "get them back" just
by advancing our own notions of where "back" might be.


I think you have more influence than I do in that respect.

Chris

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 10 '06 #28

P: n/a
"Jean-Marc Bourguet" <jm@bourguet.org> wrote
Martin Ambuhl <ma*****@earthlink.net> writes:
You need an extremely perverse definition of "successful" to find
any translation of the Bible that was more successful.


The Vulgate :-)

I was going to say.
There is an obsession with taking decisions in committee. The British
government works that way, so does my Catholic club. So does the Faculty of
Biological Sciences, at least for decisons such as to stop providing milk,
because of tax implications, and take awy the wastepaper bins to encourage
recycling. However my group doesn't take research decision in committee.

There was some research recently that deterimined that when people make
trivial decisions, a considered response is best. However when the decision
is complex and important, first instincts are usally right. Virtually all
politicians work like this - they instinctively know whether it is right to
cut taxes or raise them, because of ideology; they don't look at pages of
closely reasoned economic arguments about inflationary pressures, capacity,
fiscal expansion, and money M0.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
Jun 10 '06 #29

P: n/a
On Fri, 9 Jun 2006 22:55:38 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
Then why does Google give me 61 million hits on C/C++?
Same reason it gives me a million on "martian president" and a scary
eighteen thousand on "gonad sandwich". Google isn't a repository of
correct information. It isn't even a repository of accurate
information. Its merely a huge bucket of all the stuff ever published
on the web.
You're the one who keeps invoking the real world...


Newsflash: google isn't the real world.
--
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
Jun 10 '06 #30

P: n/a
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:iy**************@phaedsys.demon.co.uk...
I rarely see portability high on anyone's list out side C.l.c


Interesting. I've made a living since 1978 supplying people with tools
to write portable code. Not exactly true -- many of our customers are
simply happy we've ported our tools to their favorite platform -- but
a serious fraction of cour customers want and need portability. Not
a one of those customers has ever mentioned C.l.c...
need a standard to do
so, and clearly need compilers which implement that standard. The fact
that C90 and C95 are no longer ISO Standards is not relevant to
anything in the real world.


It is VERY relevant. In a legal sense in some areas.


C95 retains some official life if only as the document incorporated
by reference in C++98, the current C++ Standard. But I agree that
ISO's rules for recording tape thickness don't apply nearly as well
to programming languages.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 10 '06 #31

P: n/a
"P.J. Plauger" <pj*@dinkumware.com> writes:
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:iy**************@phaedsys.demon.co.uk...
I rarely see portability high on anyone's list out side C.l.c


Interesting. I've made a living since 1978 supplying people with tools
to write portable code. Not exactly true -- many of our customers are
simply happy we've ported our tools to their favorite platform -- but
a serious fraction of cour customers want and need portability. Not
a one of those customers has ever mentioned C.l.c...

I'd argue that you'll find that all groups with languages which do
have some official standard do stress portability.

All the other have to run with the masses and re-write their software
every other year.

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.
Jun 10 '06 #32

P: n/a
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:LS**************@phaedsys.demon.co.uk...
In article <3d******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:8B**************@phaedsys.demon.co.uk...
You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.
But they still offer a compiler used by millions of C programmers.


I agree. It is THE de-facto standard on the desktop. That is my point.
Most desktop "C" programmers are in fact using a C++ compiler. As you
have pointed out recently the current crop of MS compilers are very good
and do adhere to the C++ standards.


Not sure what your point is then. AFAIK, *every* C++ compiler is also
a C compiler these days. If each side of the compiler honors its
particular standard well enough, most programmers think of them as two
different compilers implementing two different but closely related
programming languages.
BTW There is no such language as C/C++.


Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...


I can also find millions of hits to show that Elvis lives, Roswell was a
fake AND that it was real aliens, That the Davinci code is ALL real and
all fake. Also that there are WMD in Iraq... Just because lots of
people believe it does not make it true.

Just because you can find millions of hits on google proves absolutely
nothing. I think it was Robert HeinLein who said "never underestimate
the power of human stupidity".


Sorry, but it does prove something, human capacity for stupidity
notwithstanding. Google ain't the real world, but it is a first-order
estimator of what's out there. Same for C.l.c. No matter how many
times someone pedantically insists that there is no such language as
C/C++, lots of folks out in the real world continue to use the term
to refer to the mix of code they use to solve real-world problems.

By contrast, I just Googled:

Pascal/Cobol and got one hit in Korean,

Eiffel/PL/I and got two hits, one in Japanese

So those combinations of languages seem to make less sense treated as
a single entity than C and C++. Also, FWIW, I wrote an article a year
or two ago called "The C/C++ Programming Language" which did *not*
drown in derision from subsequent letters to the editor.

There's something there that has meaning to people, deny it as much
as you'd like. Wouldn't it be more helpful to get out of denial and
start considering the role C.l.c. could play in helping the millions
of programmers, managers, etc. who profitably assume that C/C++ is
a term that makes sense?
C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99.


Perhaps, but Standard C++ is based on C95.


OK and C95 != C99.


No, but it's a step closer, and it shows that C++ walked alongside
C as far as it could to make a standard published before 1999.
And the next revison of C++
(aka C++0X) has already adopted the *entire* C99 preprocessor, the
*entire* C99 library, and quite a number of C99 language features.


That is the *next* version of C++ BTW when is it due out?


The "0" in C++0X indicates a fervent hope that it'll happen before
2010. (Remember C9X?) And it once again indicates that the languages
are making serious efforts to converge, after several years of
drifting in different directions.
Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction


Well, yes, but they seem to have gotten religion about standards
conformance lately.


Yes, they have put a lot of work into ECMA and as you have pointed out
become a lot more ISO compliant.
They haven't done export for C++ yet (because
it's damned hard and next to nobody is asking for it)


This is a bit of a recurring theme where no one is pushing for
compatibility with the latest standards.


You misunderstand the emphasis. It has almost never been the case ever
that a vendor has aimed for 100 per cent conformance to a programming
language standard. (I say this despite the free use of ANSI and ISO
in advertising.) I remember a decade ago Tom Plum expressing frustration
that he couldn't get any of his customers to eliminate the last three to
five test failures when running their C compilers against his validation
suite. Each had damn good reasons -- usually involving backward
compatibility -- why they wouldn't close the gap completely. With C++,
a way more complex language, the fuzz level is typically measured in
the dozens or hundreds of tests, but the same reasons apply. And both
C++ and C99 have made matters worse by setting such a high bar for
100 per cent conformance that few vendors are motivated to approach that
Apollonian ideal.

Nevertheless, the C and C++ Standards carry weight, if only because
many enterprises insist that *certain* portions of each language
implementation conform closely, and there are tools from Plum Hall and
Perennial to probe those portions. So the paucity of 100 per cent
conforming implementations should not be taken as proof that standards
have failed. Their success these days is just somewhat less absolute
than we all hoped for a decade and a half ago.
but they have
yet to proclaim they *aren't* going to do it. Similarly, they have
quite good conformance to C90 and C95, and haven't done C99 (because
once again it takes a lot of work and next to nobody is asking for it).


This is where we all came in. Why does no one (very few) want C99
conformance?


See above. And other reasons given. C99 is an asymptote these days,
not a pressing goal. Same for C++ (which is also a moving target).
added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.


Mostly true,


thanks :-)
except for the compiler vendors (desktop and embedded) who
use the EDG front end and Dinkumware libraries, who get full C99 and C++
compliance for free.


I know. AFAIK most of the major embedded compilers use that combination.
See http://www.edg.com & http://www.dinkumware.com I will put the
advert in for you :-)

As you say they do give C99 but.....
They don't brag about it because, as mentioned above,
it ain't a selling point.


though AFAIK not all of the embedded implimenters do a full C99 back
end.


I just plain don't know. I've stopped asking folks like Green Hills,
Wind River, etc. what they're going to release when. Practically all
of our support for our OEMs is helping them give their customers what
they want *now*.
GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.


There are many claims about various features of C and C++, with
dubious "real world" justification. Works for me.


What works for you?


All those things in C99 that people say are broken. They also seem to
work for our customers. But what do we know?
The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard.


No, they've got a bad reputation for saying NO! to damn near everything,
including things they once promised to support.


I know. Bloody nightmare. But probably not the place to go into it in
detail.
*Nothing* normative has
been added to Standard C since C99 and nothing of that sort is currently
planned. Where's the beef?


Ask the usual suspects.... Though one or two seem to have given up and
wandered off.


Well, that'll make for a refreshing interlude.
In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.


"Considered briefly and properly rejected" is how I'd characterize it.


OK. Though you have said there are parts of C99 you wish had not been
put in.


Of course. Every programming language standard has oodles of compromises,
many made for "political" reasons (as if that were a bad thing). I didn't
like all aspects of ANSI C89, yet I voted to approve the final draft.
I certainly didn't like C++98, yet I did the same. I have no trouble
griping about the problems in the standards I try to implement, while
trying at the same time to implement them well and acknowledging a
committee's right to go against the will of any minority. A standard
doesn't have to be 100 per cent lovely, in the eyes of every admirer,
to be useful. Quite the contrary.
So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.


Probably true, and you should note that the C committee is cooperating
in this approach by working diligently on DRs and not starting a revision
of C99. Where's the beef?


They were arguing against adding any TR's or anything else until all the
DR's had been fixed.


At least the TRs are non-normative. And, thanks to the persistence of
John Benito, the WG14 Convener, the DRs are well under control. If there
are still massive flaws not addressed by open DRs, that's the fault of
those who perceive the flaws, not the diligence of WG14.
Also that is Nick's worries about the whole maths
model.


Yes, I've gotten a dose or two of Nick's worries lately. And been
somewhat surprised about what he doesn't know about what he's
criticizing.
and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.


Could be,
but there seem to be people actively implementing what the
C++ committee is standardizing. And in our (Dinkumware's) experience,
there seems to be at least some market for the major additions. The
wilderness isn't empty.


That's good. However as MS is the defacto standard on the desktop and
they are going ECMA C++/CLI isn't that where the vast majority of C++
users will go?


Dunno. Maybe. I know quite a few people who use VC++ as a Standard C
and a Standard C++ compiler (I hesitate to say C/C++ here). The lure
of the managed environment will doubtless draw many, but there are
also many who want nontrivial code to work on Windows, Linux, Unix,
and other platforms. The siren call is not always obeyed.
Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.


Could also be, but if so neither you nor I will "get them back" just
by advancing our own notions of where "back" might be.


I think you have more influence than I do in that respect.


Perhaps, but much of the time my influence is bugger all. Particularly
in C++. But at least that gives me more opportunities to gripe...

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 10 '06 #33

P: n/a
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:2c********************************@4ax.com...
On Fri, 9 Jun 2006 22:55:38 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
Then why does Google give me 61 million hits on C/C++?
Same reason it gives me a million on "martian president" and a scary
eighteen thousand on "gonad sandwich".


No, not quite the same reason. Put quotes around C/C++ (forcing a
more exact match) and you still get 60 million plus hits. Then look
at the first dozen or so hits and pass your own judgment on how
grounded each is in reality. Do the same for "martian president" and
you drop to 89 hits, each as fruity as you'd expect. "gonad sandwich"
gives two hits, by ignoring the punctuation between the words.
(One is more or less sanely medical, the other is demonstrably
random "Greeked" text.) 60 million is not 89 is not 2, no matter
how much rhetorical flair you apply for top spin.
Google isn't a repository of
correct information. It isn't even a repository of accurate
information.
Didn't say it was. But as I mentioned in an earlier posting, it's
a practical and effective first-order indicator of what's out there.
You can then quickly sample the offerings and perform independent
sanity checks on the result.
Its merely a huge bucket of all the stuff ever published
on the web.


Merely? That's quite a resource IME.
You're the one who keeps invoking the real world...


Newsflash: google isn't the real world.


It's closer to it than your denial rooted in glib sophistry. And
C/C++ is way more real than a Martian president (or that, uh, other
thing), and you deny its presence in your chosen professional
field at your peril.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 10 '06 #34

P: n/a
In article <3d******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:8B**************@phaedsys.demon.co.uk...
You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.


But they still offer a compiler used by millions of C programmers.
BTW There is no such language as C/C++.


Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...


GWB managed to convince 60 million that there were WMD in Iraq when we
knew there weren't any.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 10 '06 #35

P: n/a
In article <-q******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:LS**************@phaedsys.demon.co.uk...
BTW There is no such language as C/C++.
Sorry, but it does prove something, human capacity for stupidity
notwithstanding. Google ain't the real world, but it is a first-order
estimator of what's out there. Same for C.l.c. No matter how many
times someone pedantically insists that there is no such language as
C/C++, lots of folks out in the real world continue to use the term
to refer to the mix of code they use to solve real-world problems.
Point taken
There's something there that has meaning to people, deny it as much
as you'd like. Wouldn't it be more helpful to get out of denial and
start considering the role C.l.c. could play in helping the millions
of programmers, managers, etc. who profitably assume that C/C++ is
a term that makes sense?
Well I have been asking for a widening of c.l.c a bit

And the next revison of C++
(aka C++0X) has already adopted the *entire* C99 preprocessor, the
*entire* C99 library, and quite a number of C99 language features.


That is the *next* version of C++ BTW when is it due out?


The "0" in C++0X indicates a fervent hope that it'll happen before
2010. (Remember C9X?)


:-)
There was a suggestion from JB that we would have C05 by rolling in the
two TC's
And it once again indicates that the languages
are making serious efforts to converge, after several years of
drifting in different directions.
I hope so.
This is a bit of a recurring theme where no one is pushing for
compatibility with the latest standards.


You misunderstand the emphasis. It has almost never been the case ever
that a vendor has aimed for 100 per cent conformance to a programming
language standard. (I say this despite the free use of ANSI and ISO
in advertising.)


I agree. They all say "ANSI C" on the box but never claim full
compliance to the standard.
I remember a decade ago Tom Plum expressing frustration
that he couldn't get any of his customers to eliminate the last three to
five test failures when running their C compilers against his validation
suite. Each had damn good reasons -- usually involving backward
compatibility -- why they wouldn't close the gap completely.
I can understand that. It is a commercial world and there is not death
penalty for not using a conforming compiler.
I know. AFAIK most of the major embedded compilers use that combination.
See http://www.edg.com & http://www.dinkumware.com I will put the
advert in for you :-)

As you say they do give C99 but.....
They don't brag about it because, as mentioned above,
it ain't a selling point.


though AFAIK not all of the embedded implimenters do a full C99 back
end.


I just plain don't know. I've stopped asking folks like Green Hills,
Wind River, etc. what they're going to release when. Practically all
of our support for our OEMs is helping them give their customers what
they want *now*.


that is usually out of the box support for various targets with target
specific projects i.e. peripherals and boot loaders rather than
standards conformance or portability
In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.

"Considered briefly and properly rejected" is how I'd characterize it.


OK. Though you have said there are parts of C99 you wish had not been
put in.


Of course. Every programming language standard has oodles of compromises,
many made for "political" reasons (as if that were a bad thing).


It depends where you stand. Is there a pure technical argument in a
commercial world? Politics will always intrude.
I didn't
like all aspects of ANSI C89, yet I voted to approve the final draft.
I certainly didn't like C++98, yet I did the same.


Why vote yes then?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 10 '06 #36

P: n/a
On Sat, 10 Jun 2006 11:02:32 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:2c********************************@4ax.com.. .
On Fri, 9 Jun 2006 22:55:38 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
Then why does Google give me 61 million hits on C/C++?


Same reason it gives me a million on "martian president" and a scary
eighteen thousand on "gonad sandwich".


No, not quite the same reason.


Sure, I was being disingenuous. But then so were you, using google as
a reference. You understand my point perfectly.
Google isn't a repository of
correct information. It isn't even a repository of accurate
information.


Didn't say it was.


Now /you're/ being disingenuous. Lets both stop shall we, and
reference only actual real sources of data, instead of the sum total
of all human drivel.
Newsflash: google isn't the real world.


It's closer to it than your denial rooted in glib sophistry.


Ah, insults /and/ sophistry. Excellent, padawan, you pass the test.
You may diminish and go into the west.
--
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
Jun 10 '06 #37

P: n/a
"P.J. Plauger" <pj*@dinkumware.com> writes:
[...]
Not sure what your point is then. AFAIK, *every* C++ compiler is also
a C compiler these days. If each side of the compiler honors its
particular standard well enough, most programmers think of them as two
different compilers implementing two different but closely related
programming languages.


As far as I know, gcc (which officially stands for "GNU Compiler
Collection") has separate frontends for C and C++ -- and also for Ada,
Fortran, and probably a few other languages. I don't know whether
there's any common code between the C and C++ frontends.

--
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.
Jun 10 '06 #38

P: n/a
Keith Thompson <ks***@mib.org> writes:
As far as I know, gcc (which officially stands for "GNU Compiler
Collection") has separate frontends for C and C++ -- and also for Ada,
Fortran, and probably a few other languages. I don't know whether
there's any common code between the C and C++ frontends.


There's actually a lot of common code between the C and C++ front
ends to GCC.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Jun 10 '06 #39

P: n/a
"P.J. Plauger" <pj*@dinkumware.com> wrote

It's closer to it than your denial rooted in glib sophistry. And
C/C++ is way more real than a Martian president (or that, uh, other
thing), and you deny its presence in your chosen professional
field at your peril.

That's the problem.
C/C++ has the potential to destroy the C language. If no one sticks to the C
subset of the language, pretty soon everyone needs a C++ compiler to compile
the most basic code. As a C newgroup, this isn't a development most regs
want to see.

There is also a very good argument that C/C++ is bad C and bad C++.
C's virtue is that it is simple, "portable assembler". Once you admit
complex constructs you lose that simplicity, interfaces become hard to
understand, and it is difficult to profile code.
Similarly, to do an effective object-oriented design in C++, you need to use
the whole of the language and use it consistently. For instance a
constructor needs to throw an exception if it is to fail. Exceptions go hand
in hand with constructors, and banning them is a poor idea. It is no use
writing a C sort routine, because when the C++ programmer passe it objects,
he expects them to be copied from palce to place in memory correctly. If he
is using STL, he also expects to sort any controlled sequence witht he
appropriate characteristics.

I've seen a lot of C/C++ in my time. Almost always it is nightmarish mess
that combines the worst features of both languages.

Incidentally I am not a professional. I am not a member of any chartered
body with the power to restrict entry to the field.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
Jun 11 '06 #40

P: n/a
Chris Hills said:
In article <-q******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes


<snip>
I remember a decade ago Tom Plum expressing frustration
that he couldn't get any of his customers to eliminate the last three to
five test failures when running their C compilers against his validation
suite. Each had damn good reasons -- usually involving backward
compatibility -- why they wouldn't close the gap completely.


I can understand that. It is a commercial world and there is not death
penalty for not using a conforming compiler.


We could fix that.

<g,d&r>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 11 '06 #41

P: n/a
Groovy hepcat lovecreatesbeauty was jivin' on 8 Jun 2006 20:40:08
-0700 in comp.lang.c.
Why the C committee doesn't provide an implementation when the
standard is published?'s a cool scene! Dig it!
Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?
Running on which system? Targetting which system? Hosted or free
standing? And how much are you willing to pay for this?
C works on the abstract model of low level machine. C stands for
portability and platform and machine independent. If the C compiler and
C standard library are written in C itself, is it possible that one
"standard" C compiler plus library is enough? The standard


Tell me, how do you perform system dependant tasks (such as file
I/O, memory management, interaction with hardware, etc.) in standard
C? Each target system needs its own implementation.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
Jun 11 '06 #42

P: n/a
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:wk**************@phaedsys.demon.co.uk...
OK. Though you have said there are parts of C99 you wish had not been
put in.


Of course. Every programming language standard has oodles of compromises,
many made for "political" reasons (as if that were a bad thing).


It depends where you stand. Is there a pure technical argument in a
commercial world? Politics will always intrude.


I once wrote an essay on the three basic meanings of "politics" --
briefly "damned politics", "jes' politics", and "enlightened politics".
But in the end *all* human interaction is politics, so railing against
it is like railing against the increase of entropy (which is defined
to be a property that practically *has* to increase).
I didn't
like all aspects of ANSI C89, yet I voted to approve the final draft.
I certainly didn't like C++98, yet I did the same.


Why vote yes then?


Because the standards were *good enough* and to continue to oppose them
would have been counterproductive, even obstructionist.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 11 '06 #43

P: n/a
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:k9********************************@4ax.com...
On Sat, 10 Jun 2006 11:02:32 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:2c********************************@4ax.com. ..
On Fri, 9 Jun 2006 22:55:38 -0400, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

Then why does Google give me 61 million hits on C/C++?

Same reason it gives me a million on "martian president" and a scary
eighteen thousand on "gonad sandwich".
No, not quite the same reason.


Sure, I was being disingenuous. But then so were you, using google as
a reference. You understand my point perfectly.


Not when you make an inaccurate and dismissive statement (which was
accompanied by a similar statement in a separate posting). I felt
the glib dismissal needed to be countered.
Google isn't a repository of
correct information. It isn't even a repository of accurate
information.


Didn't say it was.


Now /you're/ being disingenuous.


Nope. It is well known that a heap of information of varying degrees of
accuracy can be used to distill remarkably accurate estimators.
Lets both stop shall we, and
reference only actual real sources of data, instead of the sum total
of all human drivel.
But Google isn't as bad as you characterize it, not by a long shot.
(Would you have been as dismissive had it supported *your* viewpoint?)
I've found all sorts of algorithms, pizza parlors, addresses, definitions,
quotations, etc. etc. by Google searches and have verified repeatedly
that the ones that look sensible are mostly accurate, while the ones
that look fruity and nearly always fruity. Throw in the averaging effect
I cited above and you're a huge Hamming distance away from drivel.
Newsflash: google isn't the real world.


It's closer to it than your denial rooted in glib sophistry.


Ah, insults /and/ sophistry.


Sorry, I was trying to be descriptive. Any insult was purely a bonus.
Excellent, padawan, you pass the test.
You may diminish and go into the west.


And now you're being patronizing.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 11 '06 #44

P: n/a
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"P.J. Plauger" <pj*@dinkumware.com> writes:
[...]
Not sure what your point is then. AFAIK, *every* C++ compiler is also
a C compiler these days. If each side of the compiler honors its
particular standard well enough, most programmers think of them as two
different compilers implementing two different but closely related
programming languages.


As far as I know, gcc (which officially stands for "GNU Compiler
Collection") has separate frontends for C and C++ -- and also for Ada,
Fortran, and probably a few other languages. I don't know whether
there's any common code between the C and C++ frontends.


I don't either and it hardly matters. What matters is the efforts that
have gone into defining the rules for calling C from C++ and conversely,
so you can share nontrivial data structures and partition a program
sensibly between the two languages.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jun 11 '06 #45

P: n/a
In article <8s********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
In article <-q******************************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes


<snip>
I remember a decade ago Tom Plum expressing frustration
that he couldn't get any of his customers to eliminate the last three to
five test failures when running their C compilers against his validation
suite. Each had damn good reasons -- usually involving backward
compatibility -- why they wouldn't close the gap completely.


I can understand that. It is a commercial world and there is not death
penalty for not using a conforming compiler.


We could fix that.

<g,d&r>

I have been mentioning the Corporate Manslaughter Bill In presentations
for some years now. I wish they would get it in to law.

It was not designed for SW but basically says are the Corporation
/managment using proper tools and processes. Proper safety procedures
etc.

It moves the blame from, in the case of the Zeebruger Ferry from the
deck hand who did not properly close the bow door or the Captain who as
a matter of procedure left the harbour whilst closing he bow door to the
management who wanted X crossings a day to be more profitable.

To save time to meet the requirement of X crossings a day the captain
had to leave harbour whilst closing the bow door on a RO-RO ferry.

Also the corporation had removed the car deck baffles.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 11 '06 #46

P: n/a
jjf

Chris Hills wrote:

I rarely see portability high on anyone's list out side C.l.c
I'm astonished. I've been participating in comp.lang.c on and off for
pushing 20 years; the 'off' periods have mostly been when I've been too
busy writing C code which had to run on several different processors
under several different OSes. I can't remember when I last wrote any C
code for which portability wasn't a consideration, if I ever have. At
this moment I'm taking a break from writing commercial C which will run
on 5 different processors (or at least 7 if you include the same
processor architecture operating at different word widths) under 5
different OS families.
In article <11**********************@h76g2000cwa.googlegroups .com>,
jj*@bcs.org.uk writes

The fact that earlier Standards become non-Standard and obsolete when a
new version is published is one of the bigger sillinesses of the ISO
process.


Yes and no. The new one has to supersede the old and in some cases there
are legal requirements to use the current ISO standard. ISO does a lot
more than programming languages.


It doesn't necesarily have to 'supersede'. That could be enforced by
whatever environment brings in legal or other obligations. That is,
contracts, safety law, or whatever could either specify "the most
recently approved whatever standard" or could explictly refer to a
particular one.

Jun 11 '06 #47

P: n/a
In article <11**********************@f6g2000cwb.googlegroups. com>,
jj*@bcs.org.uk writes

Chris Hills wrote:

I rarely see portability high on anyone's list out side C.l.c
I'm astonished.


It's true. Some people woke in an environment where portability is a
concern. A lot of the people like PJP who write libraries and components
etc do write portable code but the majority of the C I see is definitely
NOT portable. There is not point to having it portable and in fact if it
were portable C the programmer would probably be fired.

Why because in most embedded systems you are talking directly to HW
there is no OS. Their architectures require non standard C.

To write it as portable C would make it slower and larger. If Larger so
that it requires more memory it could add 50cents to a unit... over 100K
units a year that is 50,000 USD a year... that is why small and fast and
never mind the portability is way it works.

Besides once you have invested in the tools for a particular processor
IE compilers and ICE you don't want to buy a new set. the code is
usually "portable" to another MCU in the same family anyway.
In article <11**********************@h76g2000cwa.googlegroups .com>,
jj*@bcs.org.uk writes
>
>The fact that earlier Standards become non-Standard and obsolete when a
>new version is published is one of the bigger sillinesses of the ISO
>process.


Yes and no. The new one has to supersede the old and in some cases there
are legal requirements to use the current ISO standard. ISO does a lot
more than programming languages.


It doesn't necesarily have to 'supersede'.


It does by definition in ISO.
That could be enforced by
whatever environment brings in legal or other obligations. That is,
contracts, safety law, or whatever could either specify "the most
recently approved whatever standard" or could explictly refer to a
particular one.


Where a specific version of the standard is not explicitly cited then it
is the current or latest. Ie C99 at the monment and depending on wording
with or without the TC's

MISRA-C for example explicitly specifies 9899:1990 + A1 and the two
TC's. Most other guides, contracts and legal requirements usually just
specific the current/latest version either explicitly or implicitly as
they don't want to have to update every time there is a "New and
Improved" version.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 11 '06 #48

P: n/a
Chris Hills (in Wa**************@phaedsys.demon.co.uk) said:

| In article <11**********************@f6g2000cwb.googlegroups. com>,
| jj*@bcs.org.uk writes
||
|| Chris Hills wrote:
|||
||| I rarely see portability high on anyone's list out side C.l.c
||
|| I'm astonished.
|
| It's true. Some people woke in an environment where portability is a
| concern. A lot of the people like PJP who write libraries and
| components etc do write portable code but the majority of the C I
| see is definitely NOT portable. There is not point to having it
| portable and in fact if it were portable C the programmer would
| probably be fired.
|
| Why because in most embedded systems you are talking directly to HW
| there is no OS. Their architectures require non standard C.
|
| To write it as portable C would make it slower and larger. If
| Larger so that it requires more memory it could add 50cents to a
| unit... over 100K units a year that is 50,000 USD a year... that is
| why small and fast and never mind the portability is way it works.

That's an interesting observation. My experience has been somewhat
different, in that I've been able to efficiently isolate processor-
and device-specific code and write the remainder in standard C. By so
doing, I've made possible the re-use of large amounts of expensively
produced code. One can isolate PHY-, MAC-, and timer-specific code and
implement the remainder of an ethernet driver portably. Interestingly,
rewriting large amounts of the code in a cable modem product as
standard C allowed turning on full gcc optimization resulting (all by
itself) in both smaller and faster code. I believe that since that
time, that firm has replaced the MIPS processor with an ARM and, if
so, very probably saved enough by reusing the standard-conforming
modules to make the $50K savings seem almost trivial.

In my next embedded system project, I wrote a p-code processor in
standard C that used an array of function pointers to dispatch /all/
of the hardware-specific functions which allowed that code to be used
to control all of the company's products that used embedded
controllers - where they had previously developed (from scratch)
complete software controller packages for each _model_ of every
product line. The expected short-intermediate term savings were huge
(I could happily retire on a new ocean-going yacht for less than 10%
of that.)

| Besides once you have invested in the tools for a particular
| processor IE compilers and ICE you don't want to buy a new set. the
| code is usually "portable" to another MCU in the same family anyway.

I'll agree with what you say about "want" and 'same-family
portability'; but there's often a (winning) business case for moving
on to newer, more-efficient architectures.

I'm not questioning the validity of your experience - just pointing
out that my own has been somewhat different.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jun 11 '06 #49

P: n/a
"Chris Hills" <ch***@phaedsys.org> wrote in message
news:iy**************@phaedsys.demon.co.uk...
I rarely see portability high on anyone's list out side C.l.c


I've been programming, in C, since the 70's. Portability is always one of my
objectives, tempered by the target environment. The frequency with which I've
had to port to a new compiler or a new platform is frequent enough that doing
anything else is equivalent to write-once coding. This has, on several
occasions, allowed me to move a program from one platform to another so quickly
that people sometimes think I've "cheated" some how on the port.

On the non-imbedded side, I've had more than a few programs run successfully
on CP/M, MS-DOS, VMS and Unix, on Z80, 8086, VAX and Sun.

On the imbedded side I've had nearly identical code running on 8051's, Z80's
and Coldfires. I've also had the good fortune to work with someone who has
similar attitudes. He moved code from a 8051 (Implemented by yet another
engineer) to a MIPS then to a Coldfire with only those changes dictated by the
hardware, and did it quite quickly. I've lately come in to do maintenance on
the 8051 and Coldfire versions and further development on the Coldfire version.
The Coldfire is the second port of the 8051 code, but I find that my knowledge
of the 8051 code is applicable to the Coldfire code. And the other way around.
It's often possible to move source from one version to another and have it just
work.

The portions where I skip portability are either due to the application
(different features of the hardware, feature set, or OS) or performance. Even
then, I find that I can usually do something which will make it easier to port
later (isolation to a subroutine, #ifdefs for machine specific code, etc.) It
usually pays off in the end. Even in cases where it doesn't pay off in direct
ways, such as a quick port or knowledge reuse, it still pays off in that it
makes clear what's "just code" and what's specific to this machine or OS. This
has always helped people who came in from other environments see where they
need to apply their attention to learning new things as opposed to other areas
which are just C as they learned it.

However, there is truth in what you say. I often encounter portability as
having either been low priority or entirely ignored. I've usually found that
this was due to programmers with little breadth of experience, often (but
surely not always) these days with Windows. In the past it was MS-DOS. I'm
also starting to encounter more with Linux backgrounds. Lack of breadth, not
depth. They're often quite inventive, but simply don't see the advantages of
making it possible to reuse their hard won accomplishments in other
applications. Their ports, especially when the target count starts to rise,
then create source control nightmares.

- Bill
Jun 11 '06 #50

52 Replies

This discussion thread is closed

Replies have been disabled for this discussion.