C89 Standard for Britons

[Keith Thompson]

We have been around this several times.

It's quite simple I write a lot of specialised embedded software for
specific processors. You need the SW to be as small and fast as
possible. You don't have the luxury of adding more memory.

Therefore you have to interact with the hardware directly no OS. One
MCU I use has directly addressable bit memory. So you use 1 bit
flags. These are not standard C.

For the serial IO you directly address the UART registers the same for
CAN or USB. That is all with non standard C.

However the rest off the App will be in standard C which you would
like the be have as per the standard. Ie the if, while, switch etc .

However there is no way I will port 8051 code to a 68040 It would be
better two re-write it in standard C in a way that takes advantage of
the underlying MCU architecture.

It is the model or algorithms which are portable. Not the C a lot of
the time .

That's *your* application domain. Portability may not be important to
you, but it's very important to a lot of C programmers. And if you're
talking about going back to the C95, then portability is entirely
possible.

One of C's greatest strengths is that it allows you write non-portable
system-specific code when you have to. Another of its greatest
strengths is that it allows you to write *portable* code when
system-specificity isn't necessary. Ignoring either aspect of the
language is foolish.

 

[Keith Thompson]

See private email

[...]

To repeat what I wrote in my e-mail response:

| Thanks for the information, but why send it to just me? I'm sure it
| would be of great interest to a lot of people. If it's confidential,
| why tell me?

 

[Richard Tobin]

| Thanks for the information, but why send it to just me? I'm sure it
| would be of great interest to a lot of people. If it's confidential,
| why tell me?

Because you're a model of discretion?

-- Richard

 

[Keith Thompson]

I will let them know Richard, and I am sure that this will reassure
them greatly

DON'T PANIC the sort of things they were looking at are the ones that
(virtually) no one has implemented.

Please be more specific.

 

[CBFalconer]

.... snip ...

One of C's greatest strengths is that it allows you write non-
portable system-specific code when you have to. Another of its
greatest strengths is that it allows you to write *portable* code
when system-specificity isn't necessary. Ignoring either aspect
of the language is foolish.

Oh, nicely put.

 

[Chris Hills]

Posix requires C99. The next revision of the C++ Standard will
require the entire C99 library and a preprocessor that matches
C99, plus other bits.

POSIX will be a problem as it is published though it can still refer
back to a specific version of the C standard.

As for C++ "The next revision"... well if it is not published yet then
they can be for warned that the C standard will change.

Do we really want a C++ that is merged with the C library? That idea
seems a bit of a mess to me. We end up with the infamous "C/C+" language
:-(


Regards
Chris

 

[Ian Collins]

POSIX will be a problem as it is published though it can still refer
back to a specific version of the C standard.

As for C++ "The next revision"... well if it is not published yet then
they can be for warned that the C standard will change.

Do we really want a C++ that is merged with the C library? That idea
seems a bit of a mess to me. We end up with the infamous "C/C+" language
:-(

The current C++ standard includes the previous C standard library (with
a few modifications), so it makes sense for the next standard to include
the current C standard library and preprocessor changes.

 

[Kelsey Bjarnason]

[snips]

Because you will never again have a conforming C compiler.

If, as noted above, some compilers have actually implemented all the
features, then there are conforming compilers - and presumably will
continue to be as new features are added. If other compilers don't
support the standard, it's a QoI issue. "You'll never again have a
conforming C compiler" doesn't work.

That said, if QoI is consistently poor over a wide variety of compilers as
pertains to a particular feature, it might argue that the specific feature
is simply unreasonably difficult to implement.

 

[Chris Hills]

[snips]

Because you will never again have a conforming C compiler.

If, as noted above, some compilers have actually implemented all the
features, then there are conforming compilers

Very few and not main steam compilers.

- and presumably will
continue to be as new features are added. If other compilers don't
support the standard, it's a QoI issue. "You'll never again have a
conforming C compiler" doesn't work.

It does work in practice.

That said, if QoI is consistently poor over a wide variety of compilers as
pertains to a particular feature, it might argue that the specific feature
is simply unreasonably difficult to implement.

Or the market just does not want them.

You have a standard that is at variance with what the users want.

 

[Richard Heathfield]

Chris Hills said:

Very few and not main steam compilers.

True, but irrelevant, since most compilers have already been converted
to Diesel.

 

[Jean-Marc Bourguet]

Chris Hills said:


True, but irrelevant, since most compilers have already been converted
to Diesel.

http://wasp.cs.washington.edu/wasp_diesel.html

Yours,

 

[CBFalconer]

Chris Hills said:

True, but irrelevant, since most compilers have already been
converted to Diesel.

Actually, modern compilers are much more energy efficient and can
usually operate on water vapor at about 70 deg. F (20 C). They
have become somewhat larger, and may require temperature inverters
when the ambient is above normal room temp (in either F or C). The
..net system is unable to use these advances, due to the abnomal
vapor absorption qualities of the software.