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

[lovecreatesbeauty]

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

[William J. Leary Jr.]

"Chris Hills" <ch***@phaedsys.org> wrote in message
news:Wa**************@phaedsys.demon.co.uk...

Why because in most embedded systems you are talking directly to HW
there is no OS. Their architectures require non standard C.
Only in those portions which contact the hardware directly. In most cases
quite large portions have, or with proper abstraction can have, no real
hardware dependancies.
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.
I've rarely found this to be the case. When it is, the section gets isolated
in some way. If I'm really stuck (subroutine call too expensive, compiler
won't inline a function, etc.) I'll at least put a #ifdef around it hooked into
a global #define with the #else calling attention to the code.
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.

But, as McCoy said, "I know engineers, they LOVE to change things." Well, I
known them too. If they can save two components and $1.00, they'll do it. And
in the overall scheme of things, they're probably right. When the MCU du-jour
blows away your tool set, it's good to be able to re-use 80% of your code and
concentrate on just the hardware differences and, usually, new features. The
inverse is true as well. When they want to save many thousands of dollars and
you tell them you can't because rather than port your code you'd have to
rewrite it, management takes a very dim view of your talents.

- Bill

[Dave Vandervies]

In article <44**************@news.alphalink.com.au>,
Peter "Shaggy" Haywood <ph******@alphalink.com.au.REMOVE.THIS.BIT> wrote:

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?

Any system with a C compiler, most likely.
Targetting which system? Hosted or free
standing?
A hosted system running in a bytecode-interpreted virtual machine (which
could be implemented in C) would make the most sense. (This would
also make it possible to re-use most of the VM code for a freestanding
implementation just by running it without the entry points for the
standard library and allowing a user-defined substitute for main()
as the entry point to the user code.)

This would, of course, require a C implementation to run on, but surely
there are enough of those out there. If that's too much to require,
then it could always be written to the previous version of the standard
instead of the new one.

An officially-endorsed reference implementation could be quite useful,
actually, even if it did require an already-existing C implementation
to run - especially if it's clear enough to be easily understood and
modified (as a base to work from for other implementations) and if it
aggressively tries to break bad code (as a sanity-checking tool for code
intended to be portable).
Tell me, how do you perform system dependant tasks (such as file
I/O, memory management, interaction with hardware, etc.) in standard
C?

By calling the underlying C implementation, of course. How else would
you do it portably?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I once saw a VB program written properly. Strange, but true. It was
astonishing.
--Richard Heathfield in comp.lang.c

[av]

On Sun, 11 Jun 2006 01:57:07 +0100, "Malcolm"
<re*******@btinternet.com> wrote:

"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
there will be not the first time that people wrong
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.

it is good if C/89standard is a subset of C++
but in that case why not consider only C++? :)
there is a difference between C and C++
the C language is writing the essential the C++ not
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.
the only reason that i see for "to fail" of a my "constructor" is an
out of memory error. then if a program goes out of memory it has only
to save all it can save show a message and exit: right?
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.
the peaple like "barocco" style but i not like it :)
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.

i too