Path: utzoo!mnetor!uunet!nuchat!sugar!sms
From: sms@sugar.UUCP (Stanley M. Sutton)
Newsgroups: comp.lang.c
Subject: Re: Pragmas
Message-ID: <1353@sugar.UUCP>
Date: 5 Jan 88 07:17:20 GMT
References: <17196@topaz.rutgers.edu> <1620005@hpcilzb.HP.COM> <5724@ccv.bbn.COM> <3902@uw-june.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 25
Summary: pragmas for non-portable extensions



I've yet to run into a vendor that hasn't "improved" a language
with extensions for his particular hardware.  If used properly, a 
pragma may be a useful way to extend a language that warns the code
reader that something non-standard is being used.  Code is almost always
developed with two purposes in mind.  The first is to solve a problem;
the second, to allow someone else to understand both the problem to be
solved, and the actual solution.
   
Portability is a design criteria for some projects, efficency for others,
and "getting it working" for others.  Pragmas can be used for all
three goals, if they are used and implemented correctly.  
   
For example, the use of inline assembly.  A module can be developed in
portable C until the application is functional.  Time studies may then 
be performed on the code.  If a memory transfer operation is taking a 
significant portion of the time of the application, the actual memory
transfer may be done in assembly to take advantage of hardware specific
features (such as the blitter and/or DMA controller on an Amiga) using
#ifdef ... #else ... #endif to improve performance.
   
Almost any feature available to a programmer can be used or abused.  The
feature is not inheriently good or bad.  It's the purpose the programmer
uses it to accomplish that is good or bad.