// at beginning of line

[Ian Collins]

That is the way it should be.

My worry is they will try and move C closer to C++. A vast amount of C
is in the embedded area on 8-128 bit systems where they don't want C++
(4 bit systems are still used but usually in assembler)

C and C++ are separate languages and should be kept that way. People who
want the features of C++ can use C++ not fit them to C otherwise the
vast majority of the C compilers will not follow the new standard.

I'm sure that isn't the main reason for the poor uptake of C99. The two
most obvious "closer to C++" additions are probably the most widely
supported - // comments and mixed declarations and code.

Oh, and C++ has moved nearer C as well - we now officially have long long!

 

[James Kuyper]

In message <[email protected]>, Ian Collins <ian-
(e-mail address removed)> writes ....

That is the way it should be.

My worry is they will try and move C closer to C++. A vast amount of C
is in the embedded area on 8-128 bit systems where they don't want C++
(4 bit systems are still used but usually in assembler)

C and C++ are separate languages and should be kept that way. People who
want the features of C++ can use C++ not fit them to C otherwise the
vast majority of the C compilers will not follow the new standard.

The most poorly supported of the new C99 features are those which moved
C away from C++, not those which moved it closer, so I don't think
that's as big of an issue as you suggest.

In fact, the existence of compilers which can compile code as either C
or C++ means that changes (to either standard) which bring C and C++
closer together tend to get adopted faster than those which do not.

 

[Nobody]

My worry is they will try and move C closer to C++. A vast amount of C
is in the embedded area on 8-128 bit systems where they don't want C++

I doubt that they'll add features which increase the run-time overhead
even if you don't use those features. And even if they did, embedded
compilers will inevitably provide an option to disable support for such
features, in the same way that C++ compilers typically allow support for
exceptions and RTTI to be disabled.

It's not as if you can run typical C89/C99 code on a small embedded
system. Most such code assumes a hosted implementation, while small
embedded systems often only provide a freestanding implementation plus the
most critical portions of the standard library (e.g. most of <string.h>,
maybe malloc() etc if memory is measured in kilobytes rather than bytes,
but probably not <stdio.h>).

At the low end, compilers won't hesitate to deviate from the standard if
it's appropriate. E.g. "rom"-qualified pointers (and RAM/ROM variants of
much of <string.h>) on systems where flash is more plentiful than RAM.

 

[Chris H]

It's not as if you can run typical C89/C99 code on a small embedded
system.

Yes you can... though it depends what you call "typical" C is widely
used on the 8051 family which up to a few years ago was 1 in 3 of the
MCU's on (or off) the planet.

Most such code assumes a hosted implementation, while small
embedded systems often only provide a freestanding implementation plus the
most critical portions of the standard library (e.g. most of <string.h>,
maybe malloc() etc if memory is measured in kilobytes rather than bytes,
but probably not <stdio.h>).

Well you are wrong there.

At the low end, compilers won't hesitate to deviate from the standard if
it's appropriate.

Quite true.

 

[Keith Thompson]

Yes you can... though it depends what you call "typical" C is widely
used on the 8051 family which up to a few years ago was 1 in 3 of the
MCU's on (or off) the planet.


Well you are wrong there.

That's an utterly useless remark unless you provide more details. Which
parts of his statement are wrong?

 

[Nobody]

Yes you can... though it depends what you call "typical"

I mean code which is portable insofar as it doesn't assume any particular
platform (CPU and OS), but was targeted at general-purpose computing
platforms designed to run third-party programs: desktops, servers,
consoles, larger embedded systems (smartphones, tablets, hand-held
consoles etc; a 32-bit CPU with RAM measured in megabytes).

As opposed to code which was explicitly written with support for smaller
(8-bit/16-bit) embedded platforms in mind.

 

[Chris H]

That's an utterly useless remark unless you provide more details. Which
parts of his statement are wrong?

Most embedded systems do provide most of the standard library including
stdio.h

 

[Chris H]

I mean code which is portable insofar as it doesn't assume any particular
platform (CPU and OS), but was targeted at general-purpose computing
platforms designed to run third-party programs: desktops, servers,
consoles,

Most assume a particular OS.

larger embedded systems (smartphones, tablets, hand-held
consoles etc; a 32-bit CPU with RAM measured in megabytes).

Those are not larger embedded systems.... many hare and have been far
larger for a decade or two. Eg defence, telecoms etc.

As opposed to code which was explicitly written with support for smaller
(8-bit/16-bit) embedded platforms in mind.

There are vastly more of these systems (both in number of different
applications and numbers in use) than the "typical" ones you mention.

Up until about 5 years ago the 8 bit 8051 family may up just over 30% of
the MCU on or off the planet!

So your "typical" platform is in fact a non typical one.

On the other hand I do have libraries that are designed to be portable
across most 8,16 and 32 bit embedded systems

 

[Keith Thompson]

Most embedded systems do provide most of the standard library including
stdio.h

Including 8051 systems?

 

[Chris H]

Including 8051 systems?

Yes.

 

[Keith Thompson]

Yes.

For example,
http://www.keil.com/support/man/docs/c51/c51_lib_stream.htm
Is that typical?

It looks like a *partial* implementation of ISO C <stdio.h>; for
example, it has versions of printf and sprintf, but not fprintf or
fopen.

Interesting.

 

[Roberto Waltman]

For example,
http://www.keil.com/support/man/docs/c51/c51_lib_stream.htm
Is that typical?

It looks like a *partial* implementation of ISO C <stdio.h>; for
example, it has versions of printf and sprintf, but not fprintf or
fopen.

I wouldn't call it typical, but it is not unexpected.
Many embedded systems, (your microwave oven, for example,) do not have
file systems, so fopen() and family are no implemented. (Or are
implemented as do-nothing stubs.)

The display on the other hand, could be masquerading as whatever
stdout goes to, and string conversion and handling functions are
needed most of the time.

 

[Roberto Waltman]

I wouldn't call it typical, but it is not unexpected.
Many embedded systems, (your microwave oven, for example,) do not have
file systems, so fopen() and family are no implemented. (Or are
implemented as do-nothing stubs.)

(Clicked on send instead of save ...)

The oven's display and keypad, on the other hand, could be
masquerading as stdout and stdin, and string conversion and handling
functions are needed most of the time, so there is a justification to
have printf() and sprintf().

(There could be also a serial port assigned as stdin/stdout, ditto for
a serial channel available only when a hardware debugging tool is
connected, etc.)

 

[Nobody]

Most assume a particular OS.

Most (but not all) complete programs assume a particular OS (or one OS
from a fixed set, using preprocessor conditionals). There's plenty of
library code which doesn't assume any specific OS, but much of it does
assume at least 32 bits for int and/or size_t (or, even if technically it
works on a 16-bit platform, in practice it won't be useful because it's
too wasteful of memory).

Those are not larger embedded systems.... many hare and have been far
larger for a decade or two. Eg defence, telecoms etc.

Larger. Not largest. Meaning: excluding the smallest systems (8/16-bit).

There are vastly more of these systems (both in number of different
applications and numbers in use) than the "typical" ones you mention.

The word "typical" referred to code, not platforms. Code aimed at 8-bit
and 16-bit systems is less common and more likely to be platform-specific.

On the other hand I do have libraries that are designed to be portable
across most 8,16 and 32 bit embedded systems

I don't doubt that such libraries exist, but they're much less common than
code which assumes a 32-bit (or better) target. Writing (and testing) code
which works on smaller platforms takes extra effort.

Practically anyone who can program has ready access to at least one 32-bit
(or 64-bit) system and a suitable toolchain. Fewer people have both ready
access to a suitable 8/16-bit system and a reason to ensure that their
code actually works on such.

Many of the libraries used on a Linux system can be compiled for Windows,
MacOSX or various other 32-bit targets with little or no changes. Very
little of it would compile (and be useful) on a 16-bit platform without
significant changes.