home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1823 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!psinntp!ibism!gjb
  3. From: gjb@fig.citib.com (Greg Brail)
  4. Subject: Re: "long long" and C++
  5. Message-ID: <BzDCLu.IHM@fig.citib.com>
  6. Sender: news@fig.citib.com
  7. Organization: Citibank IBISM
  8. References: <Bz9M1x.8vp@fig.citib.com> <1992Dec15.182228.23669@taumet.com>
  9. Date: Wed, 16 Dec 1992 20:22:42 GMT
  10. Lines: 37
  11.  
  12. In article <1992Dec15.182228.23669@taumet.com> steve@taumet.com (Steve Clamage) writes:
  13. >gjb@fig.citib.com (Greg Brail) writes:
  14. >
  15. >>The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
  16. >>integer type called "long long". Since this type is only available with
  17. >>the compiler in "strict ANSI" mode, I suppose it is part of the proposed
  18. >>ANSI C standard. Is this true?
  19. >The locution "long long" violates a constraint in section 3.5.2 of the
  20. >ANSI Standard, and must be diagnosed as an error by a conforming
  21. >implementation.  If the "long long" extension is available only in
  22. >"strict ANSI" mode, they got it backwards.  I would expect such an
  23. >extension to be available only when "strict" mode is disabled.
  24.  
  25. Sorry. I just looked at the man page for the new compiler, which says 
  26. "long long" is available in "ANSI plus Sun extensions" mode, but disabled
  27. in "strict ANSI" mode. So Sun didn't get it backwards.
  28.  
  29. >>But more importantly, are there any existing proposals to add "long long"
  30. >>to the C++ standard? Such a data type would be quite useful. Are there
  31. >>any existing C++ compilers that support, or plan to support this type?
  32. >
  33. >The next C standard will probably support an integer type longer than
  34. >type long.  The C++ Committee has no proposals that I know of for
  35. >adding such a type.  When it is added to C, it will certainly be
  36. >added to C++.  If the ANSI C numerical extensions group decides on a
  37. >longer integer type and it looks likely to be included in C, I would
  38. >expect the C++ Committee to adopt it.  It is thus possible that C++
  39. >will have it officially before C, if only due to timing.
  40.  
  41. Thanks for the help.
  42.  
  43.                 greg
  44. -- 
  45. Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
  46. lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the 
  47. deprivation of, as by negligence or accident. 2. To be unable to maintain,
  48. sustain, or keep. 3. The most commonly misspelled word on Usenet.
  49.