🚀 go-pugleaf

nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:

>In article <9602092127.AA24456@ues5.cern.ch>, Dan Pop
><danpop@ues5.cern.ch> wrote:
>
>> These are
>> the typical programs developed by scientists and engineers and they're
>> damn portable (if their authors are smart enough to avoid the language
>> extensions provided by the compiler vendors).
>
>And they manage to avoid all the problems with endianess, number of bits
>in a char/short/int/long/float/double/pointer to all of the above,
>structure packing, etc.?  All of this w/o #ifdefs in the code and trying
>it out on more than one architecture??  It's damn hard to write
>non-trivial portable ANSI C.

It's damn easy to write non-trivial portable ANSI C.  All you have to do
is not to rely on platform-specific features (size of certain types,
byte sex, etc) and functions.  Contrary to what some people believe, C is
more than a high-level assembler and there are plenty of applications
which can be implemented in portable C (I wrote a crossassembler for an
embedded controller which ran without a single #ifdef on VAX/VMS, RSX-11M
and MSDOS, despite all the differences between these platforms).

You cannot do system programming in portable ANSI C and this is where
the plethora of #ifdefs comes into play.  When it comes to GUI programming,
not even the #ifdefs can be of any help.

>If the code is this portable, it would be fairly easy to add a compiler
>option to have calls to WaitNextEvent() automatically generated (some
>versions of FORTRAN already do this), or a simple framework that calls
>this code if you don't/can't mess with the compiler.

The nice thing in C is that things don't happen behing programmer's back.
I wouldn't like a compiler to insert its WaitNextEvent() calls in my
carefully designed loops.  I prefer to be able to decide myself where
the cpu cycles go in my program.

Ever wondered why C compilers don't insert WaitNextEvent() calls?

Naive question: if CMT is so great, why is Apple (finally) introducing
PMT in the next version of MacOS (the mythical Copland)?

Dan
-- 
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland