cygwin g++ strictness

Mike Marchywka
Thu Nov 6 21:15:00 GMT 2008

> From:
> To:> Subject: RE: cygwin g++ strictness
> Date: Sat, 1 Nov 2008 10:05:54 -0400
>>>> 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.
If anyone wants to pursure this further, there are real devices like this and AFAIK
the mfg's still keep data sheets and app notes online, FWIW,

> 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.
Get 5 GB of storage with Windows Live Hotmail.

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list