C++ vs. C#

[Bo Persson]

OK, I think I know what you meant now.

I was saying: that the C++ language doesn't address portability
concerns other than by providing the standard library. (Do you have
threads available? 64-bit integers? IEEE floating point? Little
endian? Struct layout control? Etc.) Rather it leaves that as an
exercise for the developer to do.

There are two sides of this, portability of an application and
language implementability on a platform.

Here is one platform that does not have 64 bit integers,

http://unisys.com/products/mainframes/os__2200__mainframes/index.htm

but it does have 36 and 72 bit integers. Should it be disqualified?


Here is another one that does have 32 and 64 bit integers, but it is
big-endian, non-IEEE and has an EBCDIC character set:

http://www-03.ibm.com/systems/z/

It does run C++ though, very well. Most of the applications written
for it is not portable to a PC or a cell phone anyway, so struct
layout doesn't matter. PC games on the other hand, possibly written in
C++, isn't portable to the mainframe because it doesn't have a
graphics device.

Given that, the developer will
find that chore of creating some kind of portability layer (and that
doesn't necessarily mean, nor primarily mean, "finding
abstractions") easier if he defines fewer target platforms (Wintel,
for example) rather than playing the "gotta be portable everywhere
game" (a.k.a, "searching for the holy grail of portability") which
is "massochistic". The developer programs to a higher level (the
target platform set) via the portability layer rather than just
using raw C++ ("the standard").

Very few applications run everywhere, whether the struct layout is
compatible or not. Possibly you can have an "abstraction layer" to
hide the differences between a PC, a PS3 and a Wii, but you can never
abstract away the difference between a Nokia cell phone and an IBM
mainframe. You can use C++ though!


Bo Persson

 

[tonytech08]

There are two sides of this, portability of an application and
language implementability on a platform.

Here is one platform that does not have 64 bit integers,

http://unisys.com/products/mainframes/os__2200__mainframes/index.htm

but it does have 36 and 72 bit integers. Should it be disqualified?

The real question is whether it is one of your target platforms or
not. No need to address it if not. Treat special cases as special
cases.

Very few applications run everywhere, whether the struct layout is
compatible or not. Possibly you can have an "abstraction layer" to
hide the differences between a PC, a PS3 and a Wii, but you can never
abstract away the difference between a Nokia cell phone and an IBM
mainframe. You can use C++ though!

Well thanks for reiterating part of my point.

 

[Bo Persson]

The real question is whether it is one of your target platforms or
not. No need to address it if not. Treat special cases as special
cases.

In a software project, that is the question. In a language design,
perhaps it should not be.

This hardware is one reason why the C++ language standard says that
integers can use ones complement, and doesn't have to be exactly 16 or
32 bits wide. The floating point hardware here also uses 72 bits, and
is definitely not IEEE compliant - because the initial design is much,
much older than the standard.

However, the C++ language standard allows a native implementation for
such hardware. The Java and C# standards do not.

In this particular case, the machine contains extra Xeon processors to
execute the Java VM. So much for platform independence!



Bo Persson