home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 15819 < prev    next >
Encoding:
Text File  |  1992-11-05  |  1.5 KB  |  41 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!pipex!warwick!bham!bhamvx!mccauleyba
  3. From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
  4. Subject: Re: Making qsort type-safe
  5. Sender: usenet@rs6000.bham.ac.uk (USENET News Service)
  6. Message-ID: <1992Nov5.125947.1@vax1.bham.ac.uk>
  7. Date: Thu, 5 Nov 1992 12:59:47 GMT
  8. Lines: 29
  9. References: <1992Nov4.162131.10289@cs.brown.edu>
  10. Organization: University of Birmingham
  11.  
  12. In article <1992Nov4.162131.10289@cs.brown.edu>, sdm@cs.brown.edu (Scott Meyers) writes:
  13. > So I thought of doing this:
  14. > 
  15. >     typedef int (*CMP)(const void*, const void*);
  16. > 
  17. >     template<class T>
  18. >     inline
  19. >     void safeQSort(T array[], int arraySize,
  20. >                    int (*cmp)(const T *val1, const T *val2)) 
  21. >     {
  22. >         qsort(array, arraySize, sizeof(T), (CMP) cmp);
  23. >     }
  24. > 
  25. > But casts make me queasy, especially so after the mail I got telling me
  26. > about bit pattern conversions when types change.  So -- is this a safe
  27. > thing to do, or does the devil lurk within?
  28.  
  29. Other responses address the possibility that you could write the wholw qsort in
  30. C++. In answer to your direct question yes the devil does lurk within. It is
  31. possible for a conforming compiler to generate code from your source that will
  32. not work - it is however very unlikely. (I'm sure loads of people will now tell
  33. me of compilers that would fail in this case).
  34.  
  35.     \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)          
  36.  .  _\\__[oo  ============
  37. .__/  \\ /\@
  38. .  l___\\     E-mail: B.A.McCauley@bham.ac.uk
  39.  # ll  l\\ 
  40. ###LL  LL\\
  41.