Platform Independence

[Andy]

Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?
Thanks
Andy

 

[Ian Collins]

Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?

I don't think you should differentiate between them, they are
complimentary. You can get a C compiler for just about any processor
and standard conforming code will compile and run on them.

 

[Eric Sosman]

Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?

Neither term has a precise definition, as far as I know.
By my own notions (others may disagree), I would say that C
is *not* platform-independent: Too many characteristics of the
environment a C programmer confronts are inherited from and
controlled by the underlying platform. The number of bits in
an `int', the way negative integers are represented, the range
and precision of `double', whether floating-point types support
infinities, the syntax and semantics of file name strings -- all
these and more are at the platform's discretion, within broad
limits set by the language Standard. Search the Standard for the
phrase "implementation-defined" and you will find that it appears
quite often; each appearance diminishes the language's degree of
platform independence.

On the other hand, the C language is portable in the sense
that it is available on many differing platforms; porting a C
program to a new platform will seldom require that you translate
the code into a different language. C programs can be portable
to varying degrees, depending on how much they rely on the specific
characteristics of a platform. (I find it odd that C programmers
as a class seem apt to resort to non-portable techniques even when
C offers portable techniques that are no trickier; the observation
that "C combines the power of assembly language with the portability
of assembly language" is really more about the way programmers use
C than about C itself.) The ability to write non-portable programs
is both a weakness and a strength of C: a weakness because you cannot
be sure that "an ANSI C program" will port smoothly to a new platform,
and a strength because when you simply *must* stuff a special value
into location 2fff:0800 there's probably a way to do it even if it's
heavily platform-dependent.

A final note: In my view, neither "platform independence" nor
"portability" are Boolean attributes. Nor are they scalar; they
seem to me to be multi-dimensional. They are not even objective:
portability is always assessed in terms of the likely universe of
desirable target platforms, and different programmers anticipate
different audiences.

 

[Thad Smith]

I have read that 'C' is platform-independent and portable.

Standard C /can/ be used in a platform-independent way, but it takes
care and effort to achieve this, since there are many
implementation-defined and unspecified aspects of C. Two's complement
arithmetic and integer bit length which is a power of two are examples
of features that are common to most platforms, but not guaranteed in the
Standard.

To achieve the most portability, use only the features that Standard C
supports. Unfortunately, there are often implementation-dependent
things that the programmer wants to do, so he must use platform-specific
extensions or libraries. Common examples are graphics, multi-threading,
and menu systems. There are some multiple-platform libraries that make
portability easier.

The best approach is usually to use Standard C as much as feasible and
collect non-standard usage to a few functions and modules. This makes
porting easier.

 

[napi]

Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?

Hi:

You can try AMPC at http://www.axiomsol.com
It is a C compiler that generate Java class files for the purpose of
achieveing platform independence via the JVM.

Regards.

Napi

 

[Ian Collins]

Hi:

You can try AMPC at http://www.axiomsol.com
It is a C compiler that generate Java class files for the purpose of
achieveing platform independence via the JVM.

On an 8 bit micro?

 

[Flash Gordon]

On an 8 bit micro?

Nope. I doubt it would run on my (or my customers) SCO boxes not a
number of others when I run standard C programs built with the standard
port of gcc to those platforms.

Since the OP was not asking for such tools but asking for definitions of
terms I would say that AMPC was very close to being spammed. It also
still does not support C89 (it doesn't support C99 either).

 

[Herbert Rosenau]

Neither term has a precise definition, as far as I know.
By my own notions (others may disagree), I would say that C
is *not* platform-independent:

You are wrong. C is defined by zhe standard. Write your program in C
as the standard it defines and you ends up in a program that is
absolutely platform independent. I've proven that multiple times.
Write once, compile on each environment and run.

Too many characteristics of the

environment a C programmer confronts are inherited from and
controlled by the underlying platform.

That is why C exists. It is the job of the C environment to hide
platform dependant things from you.

The number of bits in

an `int', the way negative integers are represented, the range
and precision of `double', whether floating-point types support
infinities, the syntax and semantics of file name strings -- all
these and more are at the platform's discretion, within broad
limits set by the language Standard. Search the Standard for the
phrase "implementation-defined" and you will find that it appears
quite often; each appearance diminishes the language's degree of
platform independence.

Don't use yourself platform dependant details in your own code. The
standard guaratees a lot of things. Live inside the guarantees and you
would not change a single bit in your code to get it compiled and
running on highly different platforms - even on such you've never
heard before.

On the other hand, the C language is portable in the sense
that it is available on many differing platforms; porting a C
program to a new platform will seldom require that you translate
the code into a different language. C programs can be portable
to varying degrees, depending on how much they rely on the specific
characteristics of a platform. (I find it odd that C programmers
as a class seem apt to resort to non-portable techniques even when
C offers portable techniques that are no trickier; the observation
that "C combines the power of assembly language with the portability
of assembly language" is really more about the way programmers use
C than about C itself.) The ability to write non-portable programs
is both a weakness and a strength of C: a weakness because you cannot
be sure that "an ANSI C program" will port smoothly to a new platform,

Not true. Write a conforming program any you can pot it by only
compile for the new platform.

and a strength because when you simply *must* stuff a special value
into location 2fff:0800 there's probably a way to do it even if it's
heavily platform-dependent.

Yes, you will write complete incompatible program when your program is
based on functionality only defined on a specific platform. But on the
other hand you can even then write lots of the fuctionality strictly
portable by encapsulationg incomplatible functions and write only the
nonportable sections separately.

I've done that in a team of about 50 peoples for 10 completely
incompatible systems by rewriting only 25% of the total amount of 30
million lines (comments stripped) of code, having the other 75%
strictly conforming.

A final note: In my view, neither "platform independence" nor
"portability" are Boolean attributes. Nor are they scalar; they
seem to me to be multi-dimensional. They are not even objective:
portability is always assessed in terms of the likely universe of
desirable target platforms, and different programmers anticipate
different audiences.

No, you can only been portable or not. You can only been platform
independant or not.
Your progam in whole can be both in same time.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Ancient_Hacker]

Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?
Thanks
Andy

Er, Um, let's put it this way:
"Portability" isnt a yes/no issue. Let's try rating languanges on a
scale from zero to 100%, portability-wise.

Now this is a bit unfair-- many languages were developed before the
concept of "portability" was considered an important language
attribute. But let's plow ahead.

If we define portability as "The average programmer, writing say 1000
lines of code, taking no special emphasis on writing portable code,
will end up with a program that will run on xx% of the machines out
there"

let's take a wild stab at this, you may have other opinions, but this
is my guess:

Perl, COBOL, SNOBOL, Lisp: 85 to 95%

Pascal, Fortran 95, php, Java, SQL, , APL(100 lines): 70 to 84%

C, C++: 30 to 69%

Javascript, csh, sh, BASIC: 1 to 29%

Your opinion may vary.

----
(Explanation)
Some languages were intended to be portable, others have been
rigorously standardized into a semblance of portability, others are
portable because there exist "portable" implementations, others are
soooo loosely designed, or so dependent on system features that the
average program isnt very portable, or it's hard to remember all the
restrictions for writing portable programs.

So to answer your question, IMHO, C falls into the next to the bottom
category for portability. Mildly modify that by the fact that with
macros and #ifdefs and ./configure scripts you can coerce a C program
into a reasonable exterior semblance of portability.

 

[Stephen Sprunk]

Yes, you will write complete incompatible program when your program is
based on functionality only defined on a specific platform. But on the
other hand you can even then write lots of the fuctionality strictly
portable by encapsulationg incomplatible functions and write only the
nonportable sections separately.

I've done that in a team of about 50 peoples for 10 completely
incompatible systems by rewriting only 25% of the total amount of 30
million lines (comments stripped) of code, having the other 75%
strictly conforming.

That seems to be the typical model. The amount of non-portable code you
need in your abstraction layer will depend on your exact needs and whether
or not you're running on top of some sort of OS or having to write your own
drivers, scheduler, etc., but every "portable" program I've seen follows the
same general idea: there's an abstraction layer which has to be rewritten
for each new target, but the bulk of the program logic is portable.

No, you can only been portable or not. You can only been platform
independant or not.
Your progam in whole can be both in same time.

Not in whole, no, but the beauty of C is that you can have individual
modules that are one or the other _written in the same language_ within the
same program.

S

 

[Eric Sosman]

Herbert Rosenau wrote On 08/13/06 07:06,:

Andy wrote:



Neither term has a precise definition, as far as I know.
By my own notions (others may disagree), I would say that C
is *not* platform-independent:

You are wrong. C is defined by zhe standard. [...]

The Standard's definition of C is incomplete. For example,
the Standard does not define the values of INT_MIN and INT_MAX,
nor whether an `int' bit-field is signed or unsigned, nor what
happens when a negative `int' is right-shifted, nor whether a
`char' value promotes to `int' or to `unsigned int', nor ...
All these matters and more are left to the implementation's
discretion.

The Standard uses the phrase "implementation-defined"
one hundred sixty-one times, by my count. Not all of these
uses are in normative text, but the number that are normative
is non-negligible. The language is platform-dependent.

Don't use yourself platform dependant details in your own code.
[...]

Good advice, to be followed to whatever extent is practical.
Portability (to my way of thinking -- as I said, I'm unaware of
any formal definitions for these terms) is not the same thing
as platform independence, and platform DEpendence need not be
antithetical to it.

 

[Ark]

Herbert Rosenau wrote On 08/13/06 07:06,:

Andy wrote:


Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?
Neither term has a precise definition, as far as I know.
By my own notions (others may disagree), I would say that C
is *not* platform-independent:

You are wrong. C is defined by zhe standard. [...]

The Standard's definition of C is incomplete. For example,
the Standard does not define the values of INT_MIN and INT_MAX,
nor whether an `int' bit-field is signed or unsigned, nor what
happens when a negative `int' is right-shifted, nor whether a
`char' value promotes to `int' or to `unsigned int', nor ...
All these matters and more are left to the implementation's
discretion.

The Standard uses the phrase "implementation-defined"
one hundred sixty-one times, by my count. Not all of these
uses are in normative text, but the number that are normative
is non-negligible. The language is platform-dependent.

Don't use yourself platform dependant details in your own code.
[...]

Good advice, to be followed to whatever extent is practical.
Portability (to my way of thinking -- as I said, I'm unaware of
any formal definitions for these terms) is not the same thing
as platform independence, and platform DEpendence need not be
antithetical to it.

Agreed completely. For those theorizing about recompile and run, consider
int a,b;
...............
if(a+b>66000) ....
and port a pile of such code from 32-bitter to a 16-bitter.
Writing a useful portable program requires a lot of preparation and
discipline, and usually is not free from apparent runtime penalties
(which the platform's compiler will or will not optimize away).
Those still unconvinced are referred to MISRA guidelines (2004 edition);
they have some pretty horrible proposals but the criticism looks valid.
- Ark

 

[Herbert Rosenau]

Herbert Rosenau wrote On 08/13/06 07:06,:

Andy wrote:


Hi,
I have read that 'C' is platform-independent and portable. I can'tsee
much a difference between the two terms. Could anyone differentiate the
two? Also is the statement actually true?

Neither term has a precise definition, as far as I know.
By my own notions (others may disagree), I would say that C
is *not* platform-independent:

You are wrong. C is defined by zhe standard. [...]

The Standard's definition of C is incomplete. For example,
the Standard does not define the values of INT_MIN and INT_MAX,

Why should it? It does define well the minimum and maxmimum values a
conforming implementation must hold. True, it does not define that an
int can not be hold a value lower/greater an 16 bit int can hold. It
allows that an int can be significantly wider than 16 bit.

But it defines values who have at least to hold on each conforming
implementation. That is more than any other programming language will
guarantee.

nor whether an `int' bit-field is signed or unsigned,

Right, you may have a need to define signed or unsignded bitfields.
That gives you the guarantee that it works on every mashine you can
find an conforming implementation. There are programming languages
where you not even has the chance to define bitfields at all.

nor what

happens when a negative `int' is right-shifted,

True, because there is hardware existent who will produce something
undefined on negative ints.

nor whether a

`char' value promotes to `int' or to `unsigned int', nor ...
All these matters and more are left to the implementation's
discretion.

That is good so because it increases the chance to write conforming
implementations.

The Standard uses the phrase "implementation-defined"
one hundred sixty-one times, by my count. Not all of these
uses are in normative text, but the number that are normative
is non-negligible. The language is platform-dependent.

No, the language is completely platform independant. For that you have
only to avoid implementation dependant things. And that is easy when
you are able to read and understund the standard. When you are unable
to read or to understund what the standard says then you should never
program a single program anyway.

Don't use yourself platform dependant details in your own code.
[...]

Good advice, to be followed to whatever extent is practical.
Portability (to my way of thinking -- as I said, I'm unaware of
any formal definitions for these terms) is not the same thing
as platform independence, and platform DEpendence need not be
antithetical to it.

When you comes to a point where you has to write a program that has to
run on 16, 62 and 64 bit environments without any change on the source
you'll be happy that the standard defines the language well. I know
that some of my programs I've written with strictly confirmance in
mind is running on platforms I've never seen. I were not able to write
them when the standard were not existent.

The trick was simple. Strongly avoid anything that is not strictly
defined by the standard. Don't use features defined as implementation
defined. It is possible to write even big programs in C (100,000 lines
and more of code, counted without comments and empty lines).

Yes, I've written programs defined and running for a single platform -
and got a hard job every time the version number of the OS was
changed. My customers gets what they payed for,

Truly, some apps are impossible to write 100% portable but there is no
other language that makes it so easy to encaplulate importable
fragments from portable code than C. Don't tell me about Java. Jave
claims to be portable - but in reality it is far fom that in special
when it has to work under the crap from Redmont.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Agreed completely. For those theorizing about recompile and run, consider
int a,b;
..............
if(a+b>66000) ....
and port a pile of such code from 32-bitter to a 16-bitter.
Writing a useful portable program requires a lot of preparation and
discipline, and usually is not free from apparent runtime penalties
(which the platform's compiler will or will not optimize away).
Those still unconvinced are referred to MISRA guidelines (2004 edition);
they have some pretty horrible proposals but the criticism looks valid.
- Ark

When you leaves the limit the standard defines as you does above then
you are leaves the portability of C. Don't cry that C is inportable
when you don't hold its limits.

That is e.g.:

int has to be between -32767 and +32767 inclusive.
unsigned int has to be between 0 and 65535
even on 256 bit mashines.

When you has to use bigger values use (undsigned) long or you gets
only limited portable.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Keith Thompson]

[...]

The language is platform-dependent.

No, the language is completely platform independant.

[...]

Neither statement is really true. (And yes, I'm quoting both of you
out of context.)

Platform dependence or independence applies more to programs than to
languages. C is specifically designed to enable both portable and
non-portable programs.

Quoting the Rationale:

C code can be portable. Although the C language was originally
born with the UNIX operating system on the PDP-11, it has since
been implemented on a wide variety of computers and operating
systems. It has also seen considerable use in cross-compilation of
code for embedded systems to be executed in a free-standing
environment. The C89 Committee attempted to specify the language
and the library to be as widely implementable as possible, while
recognizing that a system must meet certain minimum criteria to be
considered a viable host or target for the language.

C code can be non-portable. Although it strove to give programmers
the opportunity to write truly portable programs, the C89
Committee did not want to force programmers into writing portably,
to preclude the use of C as a "high-level assembler": the ability
to write machine specific code is one of the strengths of C. It is
this principle which largely motivates drawing the distinction
between strictly conforming program and conforming program.

 

[Walter Roberson]

But it defines values who have at least to hold on each conforming
implementation. That is more than any other programming language will
guarantee.

As I recall, someone said that Java requires each of the integral
types to be an exact size. I don't know enough Java to know if
that is the case.

 

[jmcgill]

As I recall, someone said that Java requires each of the integral
types to be an exact size. I don't know enough Java to know if
that is the case.

Yes, the constraints are explicit, in terms of bit width and range, and
the language spec requires IEEE-754 floating point types and behaviors,
32-bit floats and 64-bit doubles, and requires signed two's-complement
byte, int, short, and long (of 8, 16, 32, 64 bits respectively), and an
unsigned 16-bit char.

Followup-To: comp.lang.java.programmer