This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: cygwin g++ strictness

>>> It is not portable to platforms with 16-bit int (although 
>>> these days, such platforms are museumware).
>> That, or:
>> - Running your car's engineware.
>> - Exploding an airbag into your face on detecting a collisionware.
>> - Recording your vital signsware.
>> - Pumping insulin into youware.
>> - Doing your laundyware
>> - Computerized exercise machinewear
>> - Microwaveware
>> - A billion other products with 8- and 16-bit microcontrollers in themware.
These "resource constrained" devices are important to remember as even desktop
computers have limitations - and desktop programmers, from 
what I can see in how Flash and Acrobat function, often forget this. 
>> CSci doesn't begin and end with the CPU currently on our desks!
> Thanks for reminding everyone that GCC is used for more than building
> desktop software. And to bring this around to Cygwin again, I've been
> using GCC for ARM under Cygwin for a few years now to build my Lua
> Having been through the gauntlet porting C code from 8 to 16 to 32 bit
> machines, I've been bitten by almost every possible portability bug
> there is - and I agree with Gary

Having been raised on the Z80, I find it refreshing to write phone apps
and I still can't figure out how you write code that you just rebuild between
ARM and Pentium. 
> Fix it the right way so that it's truly protable.

The problem of course is that "your architecture may vary."
This is a qualitative as well as quantitative ( as in the case of MPG)
variation. Java is supposed to be the same on all platforms regardless
of hardware and even floating point should always be exactly the same.
Of course, in reality, your medical device and airbag care about time but
the diff output doesn't.
Having ported an audio codec from java to various c++ targets,
I can assure this is usually more than just getting int size right.
As resources and constraints and objectives change, the implementation details
can effect best choice of algorithm making portable optimized code very difficult
( this isn't just typedefs or picking up a few run time parameters). Existence
of a cache is one important detail, and maybe you could argue that a 
computationally intensive app would never get ported from a desktop to a 
Z80 but the point of portability to make it limp along correctly if anyone needed to try. 
Remember, truely platform independent code would not need a platform
at all ( in fact, "independent" normally means "free of" or "unencumbered by"
not " need one of a list of things "). 
Stay up to date on your PC, the Web, and your mobile phone with Windows Live.

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]