"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

>Fergus Henderson wrote:
>>
>> The C9X draft guarantees that `long long'
>> can store values from -(2**64 - 1) to +(2**64 - 1).
>
>(I assume you mean an exponent of 63.)

Yes, thanks for the correction.

>Good. I don't have a copy of the draft, so I only know what I
>read here. Is the C9X draft available for free online?

No.  See the recent discussion on this topic in comp.std.c.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

>Valentin Bonnard wrote:
>>
>> If you want to portably store a number which is greater
>> than 4G you need long long.
>
>But only if a long long is longer than 32 bits.

Yes.  But this is guaranteed.  The C9X draft guarantees that `long long'
can store values from -(2**64 - 1) to +(2**64 - 1).

>What I meant to
>say (and thought I said) was that if we simply ask for a long
>long type, without insisting in the standard that it be _longer_
>than long, then a compiler vendor might simply add a long long
>type that's no different from long, leaving us back where we
>started.

The C9X draft does not guarantee that `long long' is longer than
`long', (e.g. both could be 64 bits, or both could be 128 bits),
but it guarantees that `long long' is at least 64 bits, whereas
`long' is only guaranteed to be at least 32 bits.

>The reason people want long long is that in most implementations
>long is 32 bits, and they want 64 bits. The only way to
>guarantee that people's desire for a 64-bit data type will be
>satisfied is to write the standard to guarantee that long long
>be 64 bits. But that would be a bit odd, since none of the other
>types are so specified.

None of the builtin types (char, short, int, long) have guaranteed
sizes, but there are guarantees about the set of values which can be
represented for each of these types, so there are effectively some
minimum sizes for each of these types.

>Therefore, I suggested the alternative, which is to add
>specified-size types, e.g. int8, int16, int32 and int64, for
>those situations where the programmer wants exactly a particular
>number of bits.

The C9X draft has a new header file <inttypes.h> which does exactly
that (and more).

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard wrote:
>
> Paul D. DeRocco wrote:
> >
> > So what if
> > we add a long long type in the standard? Who's to say that some
> > compiler vendor won't simply define it to be the same as a long,
>
> So what ?
>
> > thus making us wish for a long long long?
>
> I fail to understand this reasonning.
>
> If you want to portably store a number which is greater
> than 4G you need long long.

But only if a long long is longer than 32 bits. What I meant to
say (and thought I said) was that if we simply ask for a long
long type, without insisting in the standard that it be _longer_
than long, then a compiler vendor might simply add a long long
type that's no different from long, leaving us back where we
started.

The reason people want long long is that in most implementations
long is 32 bits, and they want 64 bits. The only way to
guarantee that people's desire for a 64-bit data type will be
satisfied is to write the standard to guarantee that long long
be 64 bits. But that would be a bit odd, since none of the other
types are so specified.

Therefore, I suggested the alternative, which is to add
specified-size types, e.g. int8, int16, int32 and int64, for
those situations where the programmer wants exactly a particular
number of bits.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  Valentin Bonnard wrote:
|>  >
|>  > Paul D. DeRocco wrote:
|>  > >
|>  > > So what if
|>  > > we add a long long type in the standard? Who's to say that some
|>  > > compiler vendor won't simply define it to be the same as a long,
|>  >
|>  > So what ?
|>  >
|>  > > thus making us wish for a long long long?
|>  >
|>  > I fail to understand this reasonning.
|>  >
|>  > If you want to portably store a number which is greater
|>  > than 4G you need long long.
|>
|>  But only if a long long is longer than 32 bits. What I meant to
|>  say (and thought I said) was that if we simply ask for a long
|>  long type, without insisting in the standard that it be _longer_
|>  than long, then a compiler vendor might simply add a long long
|>  type that's no different from long, leaving us back where we
|>  started.

The standard (probably) won't insist that long long be longer than long,
any more than it insists that long be longer than int.  It will require
long long to be at least 64 bits -- this was Valentin Bonnard's point:
if you want to be sure that you have more than 32 bits (in portable
code), then you need long long.

Of course, this reasoning very quickly leads us to "long long long", to
be sure that you have at least 128 bits, and "long long long long", to
be sure of at least 256 bits, and ...

In sum, long long must be considered a quick and dirty hack, and not a
real solution.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:
>
> The C9X draft guarantees that `long long'
> can store values from -(2**64 - 1) to +(2**64 - 1).

(I assume you mean an exponent of 63.)

Good. I don't have a copy of the draft, so I only know what I
read here. Is the C9X draft available for free online? I know
the real standard costs money, which I'm generally unwilling to
shell out for languages I don't program in.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

It seems to me that there is an inherent contradiction between
the desire for a long long type and the desire for a standard
that doesn't specifically define the sizes of types. So what if
we add a long long type in the standard? Who's to say that some
compiler vendor won't simply define it to be the same as a long,
thus making us wish for a long long long? The desire for
something longer than a long in fact reflects a dissatisfaction
with the _particular_ length of most longs (i.e., 32 bits) and a
desire for a _particular_ longer version (64 bits).

Personally, I prefer the approach of defining a standard set of
fixed-size types, e.g., int8, int16, int32 and int64 (with
signed and unsigned variants). The standard should require that
compilers that support those sizes do so under those particular
names (in addition to the usual ones), and also require that
compilers that don't support those sizes simply leave them out.
Thus, if you try to compile a program that uses int32 on a
36-bit machine, you get an error message, indicating that you're
asking more of the compiler than you have a right to expect.
However, as long as you're sticking to 2^n size machines, you
will be guaranteed that your int32 will work, and that the
compiler vendor won't have invented some different name for that
type.

I also don't have any problem with expressly excluding these
types from the rule that any integral type can be cast to a long
and back without loss. That rule should apply to the usual
"variable" sized types. The use of the fixed size types should
imply that the user takes responsibility for the sizes of
things.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul D. DeRocco wrote:
>
> It seems to me that there is an inherent contradiction between
> the desire for a long long type and the desire for a standard
> that doesn't specifically define the sizes of types.

I don't why there is more contradiction than in the desire to
have 4 different signed integral types (ignoring the type char):
signed char, short, int, long with different imposed sizes.

signed char can hold -2^7 to 2^7
short    .......     -2^15 to 2^15
int      ......      -2^15 to 2^15
long     ......      -2^31 to 2^31
and
long long  ......   -2^63 to 2^63

> So what if
> we add a long long type in the standard? Who's to say that some
> compiler vendor won't simply define it to be the same as a long,

So what ?

> thus making us wish for a long long long?

I fail to understand this reasonning.

If you want to portably store a number which is greater
than 4G you need long long.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]