home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / misc / 4026 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  4.1 KB
  1. Path: sparky!uunet!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Safety.  Was: Re: Pointers
  5. Summary: inadequacy of unions not explained, why teach atypical applications first not explained
  6. Message-ID: <724312516@sheol.UUCP>
  7. Date: 14 Dec 92 05:42:05 GMT
  8. References: <Bz0Iy5.A9K@mentor.cc.purdue.edu>
  9. Lines: 97
  10.  
  11. : From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  12. : Message-ID: <Bz0Iy5.A9K@mentor.cc.purdue.edu>
  13. : C does not allow type coercions.  I do not consider unions an adequate
  14. : way to do that.
  15.  
  16. I have not seen any posting in which Herman explains *why* he does not
  17. consider unions an adequate way to specify type punning, despite having
  18. seen the claim that they *aren't* adequate several times.  (Type coercions
  19. are something else, in standard usage.)
  20.  
  21. In particular, I'll quote an example from message
  22. <723522717@sheol.UUCP>, and I would appreciate it if somebody would
  23. explain what's so horrible or "inadequate" about the use of unions in
  24. the example.  I'd especially appreciate comments on the last usage
  25. below, involving inline functions. 
  26.  
  27. -- begin excerpt from <723522717@sheol.UUCP> --
  28.  : Telling the compiler that that number which you used as an integer before
  29.  : is now to be considered a float is not ambiguous, except that most of the
  30.  : current languages will object strongly.
  31.  
  32.  "Most of the current languages" object strongly because THEY HAVE
  33.  NO SUCH OPERATION.  Herman is simply using an operation that is
  34.  MEANINGLESS IN THE LANGUAGE.
  35.  
  36.  Now, Ada, PL/I and C DO have such operations, and in the specific case
  37.  of C, the compilers I've tried them out upon don't "object strongly".
  38.  They don't object at all.  For example:
  39.  
  40.          void g(float);
  41.          void f(void){
  42.              union {float f; int i;} u;
  43.              g((u.i=0xABCD,u.f));
  44.          }
  45.  
  46.  This says, "take this number I've been treating as an int, treat it as
  47.  a float, and pass it to g", quite clearly and fairly unambiguously.  Of
  48.  course, Herman probably objects that this "syntax is clumsy", and
  49.  presumably wishes to write something like
  50.  
  51.          void g(int);
  52.          void f(void){
  53.              g(0xABCD);
  54.          }
  55.  
  56.  and then in a separate file, implement g like so
  57.  
  58.          void g(float){ ... }
  59.  
  60.  The problem with this is, the C compiler is not obliged to treat this as
  61.  anything other than the gibberish (in the context of the C language)
  62.  that it is.  And if the syntax of the correct way of expressing this in
  63.  C is clumsy, one can (in gcc at least) implement the conversion as an
  64.  inline function in an include file:
  65.  
  66.          inline float iasf(int i) {
  67.              /* treat the bits of an integer as a float */
  68.              union {long f; int i;} u;
  69.              return(u.i=i,u.f);
  70.          }
  71.  
  72.  and then use it where needed
  73.  
  74.          #include "taken_as.h"
  75.          void g(float);
  76.          void f(void){
  77.              g(iasf(0xABCD));
  78.          }
  79.  
  80.  This notation at the use point is not much more clumsy than what Herman
  81.  probably wanted, and is at least meaningful in the language, since care
  82.  was taken to explain to the compiler what was going on.
  83. -- end excerpt from <723522717@sheol.UUCP> -- 
  84.  
  85. While I'm at it, I'd appreciate any explanation for Herman's
  86. position on "first course" exposure:
  87.  
  88. -- begin additional excerpt --
  89.  : Possibly the situation would eventually improve if CS students, in their
  90.  : FIRST course, would be placed in situations where their code would crawl
  91.  : unless they did such things.
  92.  
  93.  Why should their FIRST course introduce them to situations
  94.  that are strikingly atypical of most software development?
  95.  Well, Herman's hope is:
  96.  
  97.  : This might cause more language producers and hardware designers to
  98.  : realize that there can be large costs with separate integer and floating
  99.  : registers, and that Boolean operations on floating numbers do make sense. 
  100.  
  101.  It is possible that the cause (ie: early introduction of atypical
  102.  application-specific difficulties) would have this effect (having
  103.  undue attention payed to niche requirements).  It is not clear
  104.  that this is a good thing, however.
  105. -- end additional excerpt --
  106. --
  107. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  108.