Topic: long long" and C++


Author: gjb@fig.citib.com (Greg Brail)
Date: Wed, 16 Dec 1992 20:22:42 GMT
Raw View
In article <1992Dec15.182228.23669@taumet.com> steve@taumet.com (Steve Clamage) writes:
>gjb@fig.citib.com (Greg Brail) writes:
>
>>The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
>>integer type called "long long". Since this type is only available with
>>the compiler in "strict ANSI" mode, I suppose it is part of the proposed
>>ANSI C standard. Is this true?
>The locution "long long" violates a constraint in section 3.5.2 of the
>ANSI Standard, and must be diagnosed as an error by a conforming
>implementation.  If the "long long" extension is available only in
>"strict ANSI" mode, they got it backwards.  I would expect such an
>extension to be available only when "strict" mode is disabled.

Sorry. I just looked at the man page for the new compiler, which says
"long long" is available in "ANSI plus Sun extensions" mode, but disabled
in "strict ANSI" mode. So Sun didn't get it backwards.

>>But more importantly, are there any existing proposals to add "long long"
>>to the C++ standard? Such a data type would be quite useful. Are there
>>any existing C++ compilers that support, or plan to support this type?
>
>The next C standard will probably support an integer type longer than
>type long.  The C++ Committee has no proposals that I know of for
>adding such a type.  When it is added to C, it will certainly be
>added to C++.  If the ANSI C numerical extensions group decides on a
>longer integer type and it looks likely to be included in C, I would
>expect the C++ Committee to adopt it.  It is thus possible that C++
>will have it officially before C, if only due to timing.

Thanks for the help.

    greg
--
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.




Author: davidm@consilium.com (David S. Masterson)
Date: 17 Dec 92 05:20:40 GMT
Raw View
>>>>> On 15 Dec 92 18:22:28 GMT, steve@taumet.com (Steve Clamage) said:

> The next C standard will probably support an integer type longer than
> type long.  The C++ Committee has no proposals that I know of for
> adding such a type.  When it is added to C, it will certainly be
> added to C++.  If the ANSI C numerical extensions group decides on a
> longer integer type and it looks likely to be included in C, I would
> expect the C++ Committee to adopt it.  It is thus possible that C++
> will have it officially before C, if only due to timing.

> Whether the longer type will be called "long long" or something else is
> anyone's guess.

I've heard a lot of talk about "long long", but never understood why C would
need new syntax to represent a 64-bit integer.  Is there anything wrong with:

 char - 8 bits
 short - 16 bits
 int - 32 bits  (16 on 16-bit architecture)
 long - 64 bits  (32 on 16-bit architecture)
 long long - 128 bits (64 on 16-bit architecture)

--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
davidm@consilium.com    Mtn. View, CA  94043
====================================================================
"Bureaucracy is a giant mechanism operated by pygmies."
-- Honore de Balzac




Author: gjb@fig.citib.com (Greg Brail)
Date: Mon, 14 Dec 1992 19:56:20 GMT
Raw View
The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
integer type called "long long". Since this type is only available with
the compiler in "strict ANSI" mode, I suppose it is part of the proposed
ANSI C standard. Is this true?

But more importantly, are there any existing proposals to add "long long"
to the C++ standard? Such a data type would be quite useful. Are there
any existing C++ compilers that support, or plan to support this type?

    greg
--
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.




Author: steve@taumet.com (Steve Clamage)
Date: Tue, 15 Dec 1992 18:22:28 GMT
Raw View
gjb@fig.citib.com (Greg Brail) writes:

>The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
>integer type called "long long". Since this type is only available with
>the compiler in "strict ANSI" mode, I suppose it is part of the proposed
>ANSI C standard. Is this true?

There is an official ANSI C Standard, and has been since 1989.

The locution "long long" violates a constraint in section 3.5.2 of the
ANSI Standard, and must be diagnosed as an error by a conforming
implementation.  If the "long long" extension is available only in
"strict ANSI" mode, they got it backwards.  I would expect such an
extension to be available only when "strict" mode is disabled.

>But more importantly, are there any existing proposals to add "long long"
>to the C++ standard? Such a data type would be quite useful. Are there
>any existing C++ compilers that support, or plan to support this type?

The next C standard will probably support an integer type longer than
type long.  The C++ Committee has no proposals that I know of for
adding such a type.  When it is added to C, it will certainly be
added to C++.  If the ANSI C numerical extensions group decides on a
longer integer type and it looks likely to be included in C, I would
expect the C++ Committee to adopt it.  It is thus possible that C++
will have it officially before C, if only due to timing.

Whether the longer type will be called "long long" or something else is
anyone's guess.

In the mean time, a number of compilers support this type, such as
Sun C, as you noted.
--

Steve Clamage, TauMetric Corp, steve@taumet.com