On Thu, 30 Nov 2006 10:26:05 CST, "James Kanze"
<james.kanze@gmail.com> wrote:

> "Kristof Zelechovski" wrote:
> > Uzytkownik <kuyper@wizard.net> napisal w wiadomosci

> > I prefer this convention because I would like the range of long int to be
> > well defined.
> > It is very strange that the basic types are so vaguely defined by the
> > standard.
> > It does not happen in any other language I know about.
>
> Really.  I think that Java is about the only language which does
> define the size.  Fortran certainly didn't, nor does Lisp, nor
> any of the languages in the Pascal family (including Ada).

The predefined _named_ types in Ada are 'whatever is good for target
platform', but the core language types use range (precision for float)
and optionally size. (And it's a point of much contention whether it's
actually in the Pascal 'family'. <G>)

COBOL mostly specifies size in (decimal) digits, and PL/I (partly
following it) optionally bits or digits. SQL does vague or digits.

Otherwise agree. Noting that (nonclassic) Lisp can overflow integer to
bignum silently preserving mathematical correctness. (Except of course
Z isn't closed under division, though Z_n can be differently.)

- David.Thompson1 at worldnet.att.net

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski wrote:

>
> The name for the 64-bit type was always long long int

Huh?  C++ doesn't even have that type.

> and the rule was that a plain int is equivalent to a short int or to a long
> int depending on the platform.


> I prefer this convention because I would like the range of long int to be
> well defined.
> It is very strange that the basic types are so vaguely defined by the
> standard.

The sizes were designed to be implementation defined to accommodate
a variety of machines efficiently.  You know that C exists on machines
where sizeof(int) is 36?   I've worked on a variety of supercomputers
that have had integer types all over the place.

C does have some typedefs now that assure you of "at least" and
"exactly" a certain number of bits.  If you need to rely on this
these are the way to go.   Eventually that feature will be subsumed
in to C++.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:

> Strictly defining the size limits the number of platforms for
> which you can have an efficient implementation, and really
> doesn't help the programmer that much.

As far as int's go, neither do you know what the safe range of values
is, nor when overflow has occurred. I don't consider that combination
helpful, in fact I consider it downright dangerous.  OTOH Anything that
eliminates variability, and increases predictability and reliability is
helpful to me as a programmer and for the repuation of C++ in general
AFAICS.

Cross platform API's generally do provide integer types guaranteeing
e.g 16 ,32 bits. They do this presumably because it helps them too.

regards
Andy Little

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> James Kanze wrote:

> > Strictly defining the size limits the number of platforms for
> > which you can have an efficient implementation, and really
> > doesn't help the programmer that much.

> As far as int's go, neither do you know what the safe range of values
> is, nor when overflow has occurred.

The safe range of values for an int is INT_MIN...INT_MAX.  And
of course, you validate your input up front to ensure that your
intermediate values never exceed these ranges.  (Often, in fact,
you'll enforce a significantly smaller range.)

> I don't consider that combination
> helpful, in fact I consider it downright dangerous.  OTOH Anything that
> eliminates variability, and increases predictability and reliability is
> helpful to me as a programmer and for the repuation of C++ in general
> AFAICS.

There are a very few cases where you might need an exact number
of bits, but most of the time, you either need at least so many
bits (e.g. the day of the month requires 5 bits), or you need
symbolic constants with the maximum and minimum values, so you
can check up front.

> Cross platform API's generally do provide integer types guaranteeing
> e.g 16 ,32 bits. They do this presumably because it helps them too.

Well, you do have to ensure that whatever you write on one
platform has the same format as you read it with on the other.
The representation and the number of bits don't matter, but they
have to be the same at both ends.  Thus, for example, cross
platform API's also specify byte order.  But we don't want to
specify that in C++, since it would radically penalize some
machines.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

ron@spamcop.net (Ron Natalie) writes:
[...]
> The sizes were designed to be implementation defined to accommodate
> a variety of machines efficiently.  You know that C exists on machines
> where sizeof(int) is 36?   I've worked on a variety of supercomputers
> that have had integer types all over the place.
[...]

Really?  That's at least 288 bits.  (I presume you mean
sizeof(int) * CHAR_BIT == 36.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> kwikius wrote:
> > James Kanze wrote:

> The safe range of values for an int is INT_MIN...INT_MAX.

A constant is a value that is immutable. Are these macros constants?

regards
Andy Little

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> James Kanze wrote:
> > kwikius wrote:
> > > James Kanze wrote:

> > The safe range of values for an int is INT_MIN...INT_MAX.

> A constant is a value that is immutable. Are these macros constants?

The are required to evaluate to integral constant expressions,
with the promoted type of the target.

Did you really think that they could change?

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> James Kanze wrote:
> > kwikius wrote:
> > > James Kanze wrote:
>
> > The safe range of values for an int is INT_MIN...INT_MAX.
>
> A constant is a value that is immutable. Are these macros constants?

Yes. Those macros are in the portion of the C++ standard library which
is inherited from the C standard library. The C++ standard does not
describe the C standard library in any detail, deferring to the C
standard for that description.  The C standard does require that those
macros expand to constant expressions with implementation-defined
values.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> kwikius wrote:
> > James Kanze wrote:
> > > kwikius wrote:
> > > > James Kanze wrote:
>
> > > The safe range of values for an int is INT_MIN...INT_MAX.
>
> > A constant is a value that is immutable. Are these macros constants?
>
> The are required to evaluate to integral constant expressions,
> with the promoted type of the target.
>
> Did you really think that they could change?

Changing its value is easy to achieve by moving it between two
different compilers, say by serialising it to a file, a perfectly
reasonable proposition one might think.

It's not constant because the type it represents is a pseudonym for
some semantics which you can only fathom by looking in detail at the
context in which the term is used. Once ouside a particular very
limited environment the term INT_MAX has no meaning. There are as many
meanings as there are platform compiler environment combinations

true constants are values such as pi which have a well defined meaning
irrespective of context. That makes pi a very powerful constant and
INT_MAX a very weak and unsatisfying one.

regards
Andy Little

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> James Kanze wrote:
>> kwikius wrote:
>>> James Kanze wrote:
>>>> kwikius wrote:
>>>>> James Kanze wrote:
>>>> The safe range of values for an int is INT_MIN...INT_MAX.
>>> A constant is a value that is immutable. Are these macros constants?
>> The are required to evaluate to integral constant expressions,
>> with the promoted type of the target.
>>
>> Did you really think that they could change?
>
> Changing its value is easy to achieve by moving it between two
> different compilers, say by serialising it to a file, a perfectly
> reasonable proposition one might think.
>
> It's not constant because the type it represents is a pseudonym for
> some semantics which you can only fathom by looking in detail at the
> context in which the term is used. Once ouside a particular very
> limited environment the term INT_MAX has no meaning. There are as many
> meanings as there are platform compiler environment combinations
>
> true constants are values such as pi which have a well defined meaning
> irrespective of context. That makes pi a very powerful constant and
> INT_MAX a very weak and unsatisfying one.

Because they serve different purposes; INT_MIN and INT_MAX exist to tell
you something about the specific implementation that defines them, which
is trivial but very important.

I would have said: "The *safe* range of values for int across any
conforming implementations is -32767...32767, and the *actual* range of
values for int on a specific implementation is INT_MIN...INT_MAX."

The numbers -32767 and 32767 are not given as macros. :)

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> James Kanze wrote:
> > kwikius wrote:
> > > James Kanze wrote:
> > > > kwikius wrote:
> > > > > James Kanze wrote:
> >
> > > > The safe range of values for an int is INT_MIN...INT_MAX.
> >
> > > A constant is a value that is immutable. Are these macros constants?
> >
> > The are required to evaluate to integral constant expressions,
> > with the promoted type of the target.
> >
> > Did you really think that they could change?
>
> Changing its value is easy to achieve by moving it between two
> different compilers,

That's not changing the value. That's changing to a different value.
Maybe an analogy will make that difference clearer. The number of
letters in "Indiana" is a constant; the fact that the number of letters
in "Hello" is a different number doesn't make the number of letters in
"Indiana" non-constant. Similarly, INT_MAX is the maximum value of an
integer for a given implementation of C++. The fact that INT_MAX might
be different on a different implementation doesn't make the value of
INT_MAX for a given implementation non-constant.

> ... say by serialising it to a file, a perfectly
> reasonable proposition one might think.

That depends upon what you know. That's not what you would think if you
were aware of the fact that INT_MAX expands to an integer constant
expression with an implementation-defined value.

> It's not constant because the type it represents is a pseudonym for
> some semantics which you can only fathom by looking in detail at the
> context in which the term is used. Once ouside a particular very
> limited environment the term INT_MAX has no meaning. There are as many
> meanings as there are platform compiler environment combinations

INT_MAX can have different values in those different environments, but
it has the same meaning in all of them. Just like "height" has a
different value for each human being, and even different values for the
same human being at different times, but it has the same meaning for
all human beings at all times.

> true constants are values such as pi which have a well defined meaning
> irrespective of context. That makes pi a very powerful constant and
> INT_MAX a very weak and unsatisfying one.

More accurately, it's a very strong and satisfying constant, when used
within it's proper domain, even though it's a far weaker and less
satisfying constant than pi.

Be careful what you wish for. If INT_MAX had been defined as an
absolute constant from the beginning, it might easily have been set to
a value like 32767, which would have made C++ somewhat inefficient on
32-bit processors, and very inefficient on 64-bit processors. Backwards
compatibilty would have made it politically impossible to change the
value as new processors came out. Leaving room for C++ to adapt to
future environments that might be quite different from current ones was
a deliberate design choice; it means that the C++ language can be
ported to a wider variety of platforms than more tightly constrained
languages. The result is that while porting code from one
implementation of C++  is more problematic than it could be with
tighter implementation constraints, there's a wider variety of
platforms that C++ code can be ported to than for almost any other
language (except possibly C, for the same reasons).

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 29 Nov 2006 16:03:12 CST, kuyper@wizard.net wrote:

>There's a lot of code out there written back in the days when 32-bit
>machines were the state of the art, which therefore assumes that long
>is 32 bits.

Wish there was no "therefore" in that sentence :-)

>I consider that to be defective code - it's always possible
>to write code so that it works correctly, regardless of whether long is
>32 bits or 64 bits. However, when 64-bit machines came out, as a
>practical matter, many implementations  chose to deal with such code by
>keeping 'long' as a 32-bit type, rather than breaking it by making
>'long' a 64-bit type.

I thought the main reason was not breaking ABI. No?

--
Gennaro Prota.    C++ developer. For hire.
(to mail me, remove any 'u' from the address)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Seungbeom Kim wrote:
> kwikius wrote:
> > James Kanze wrote:
> >> kwikius wrote:
> >>> James Kanze wrote:
> >>>> kwikius wrote:
> >>>>> James Kanze wrote:
> >>>> The safe range of values for an int is INT_MIN...INT_MAX.
> >>> A constant is a value that is immutable. Are these macros constants?
> >> The are required to evaluate to integral constant expressions,
> >> with the promoted type of the target.
> >>
> >> Did you really think that they could change?
> >
> > Changing its value is easy to achieve by moving it between two
> > different compilers, say by serialising it to a file, a perfectly
> > reasonable proposition one might think.
> >
> > It's not constant because the type it represents is a pseudonym for
> > some semantics which you can only fathom by looking in detail at the
> > context in which the term is used. Once ouside a particular very
> > limited environment the term INT_MAX has no meaning. There are as many
> > meanings as there are platform compiler environment combinations
> >
> > true constants are values such as pi which have a well defined meaning
> > irrespective of context. That makes pi a very powerful constant and
> > INT_MAX a very weak and unsatisfying one.
>
> Because they serve different purposes; INT_MIN and INT_MAX exist to tell
> you something about the specific implementation that defines them, which
> is trivial but very important.
>
> I would have said: "The *safe* range of values for int across any
> conforming implementations is -32767...32767, and the *actual* range of
> values for int on a specific implementation is INT_MIN...INT_MAX."
>
> The numbers -32767 and 32767 are not given as macros. :)

>From the ' I would have said' part, it sounds like you arent absolutely
certain about that ;-)

As may have been stated higher in the thread, I don't think it is spelt
out in the C++ standard, what the ranges are. I think you have to delve
into the C standard and then apply some deduction. Some helper traits
would clarify things:


template <typename Integer>
struct cross_platform_max;

template<>
struct cross_platform_max<signed char>{
   static const signed char value = 127;
};

template<>
struct cross_platform_max<unsigned char>{
   static const unsigned char value = 0xff;
};

(char would have to be limited from 0 - 127 I guess)

template<>
struct cross_platform_max<int>{
   static const int value = 32767;
};
template<>
struct cross_platform_max<long>{
   static const long value = 2147483647;
};

AFAICS a platform independent integer type should be a UDT rather than
a typedef too.

regards
Andy Little

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Thu, 30 Nov 2006 11:24:14 CST, kuyper@wizard.net wrote:

>Alberto Ganesh Barbati wrote:
>> kuyper@wizard.net ha scritto:
>
>> That's plain wrong. There is an explicit requirement about storage in
>> 3.9.1/2: "There are four signed integer types: "signed char", "short
>> int", "int", and "long int." In this list, each type provides at least
>> as much storage as those preceding it in the list."
>
>You're right, of course. I'd like to blame my mistake on confusion
>between the C and C++ standards, since I monitor newgroups devoted to
>both standards. However, I have to admit that I'd never noticed that
>this was one of the differences between those two standards. This
>should probably be mentioned in appendix C.1.

I'm not sure the difference is intentional, though. It almost looks
like nobody in the C++ circles thought that integral types are allowed
to have padding bits. It is good that C99 spelt this out.

--
Gennaro Prota.    C++ developer. For hire.
(to mail me, remove any 'u' from the address)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> James Kanze wrote:
> > kwikius wrote:
> > > James Kanze wrote:
> > > > kwikius wrote:
> > > > > James Kanze wrote:

> > > > The safe range of values for an int is INT_MIN...INT_MAX.

> > > A constant is a value that is immutable. Are these macros constants?

> > The are required to evaluate to integral constant expressions,
> > with the promoted type of the target.

> > Did you really think that they could change?

> Changing its value is easy to achieve by moving it between two
> different compilers, say by serialising it to a file, a perfectly
> reasonable proposition one might think.

> It's not constant because the type it represents is a pseudonym for
> some semantics which you can only fathom by looking in detail at the
> context in which the term is used. Once ouside a particular very
> limited environment the term INT_MAX has no meaning. There are as many
> meanings as there are platform compiler environment combinations

> true constants are values such as pi which have a well defined meaning
> irrespective of context. That makes pi a very powerful constant and
> INT_MAX a very weak and unsatisfying one.

It's not a constant in the same sense that PI is a constant, but
it is a constant in the sense of C++; you cannot modify it, and
you can use it for things like array dimensions.  And that
corresponds to the usual sense of constant.

In practice, if you're serializing, you don't care about the C++
representation, as such.  You need to know the specification of
the serialization format.  The safe range might be less than
INT_MIN...INT_MAX, and it might be more.  But this seems rather
an obvious fact: different machines have different hardware, and
when serializing, you have have to convert your internal format
to the external format, and vice versa.  About the only way to
avoid this is to effectively render an implementation of the
language impossible, or at least extremely expensive, on some
platforms.  Java could take this route because it only targetted
certain types of applications (and even then, to run Java on an
IBM mainframe, you need a hardware extension).  C++ attempts to
be implementable on all, or almost all platforms.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kwikius wrote:
> Seungbeom Kim wrote:
.
> > I would have said: "The *safe* range of values for int across any
> > conforming implementations is -32767...32767, and the *actual* range of
> > values for int on a specific implementation is INT_MIN...INT_MAX."
> >
> > The numbers -32767 and 32767 are not given as macros. :)
>
> >From the ' I would have said' part, it sounds like you arent absolutely
> certain about that ;-)
>
> As may have been stated higher in the thread, I don't think it is spelt
> out in the C++ standard, what the ranges are. I think you have to delve
> into the C standard and then apply some deduction.

Correct, except that very little deduction is needed; the minumum
values for the upper limits, and the maximum values for the minima of
signed types, are spelled out explicitly in section 5.2.4.2.1 of the C
standard.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

If I am not mistaken standard says that:

sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1
the following lengthes satisfy this condition:
     8      >     4     >      2       >      1      ==1
so why int64 on microsoft platform with:
sizeof(int64)==8
sizeof(long)==4
sizeof(int)==4
sizeof(short)==2
sizeof(int64)==1

int64 looks ugly

regards
FM

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

jam wrote:
> If I am not mistaken standard says that:
>
> sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1

Actually, it doesn't. The required relationships are in terms of the
range of values represented, not in terms of the amount of memory used
to store the values. It's perfectly legal for sizeof(short) >
sizeof(long), as long as SHORT_MAX < LONG_MAX.

Of course, as a practical matter, just about everyone uses 2's
complement integer types that use every bit they have available, so the
sizeof(type) and the TYPE_MAX macros will usually be in the same order,
for all types.

> the following lengthes satisfy this condition:
>      8      >     4     >      2       >      1      ==1
> so why int64 on microsoft platform with:
> sizeof(int64)==8
> sizeof(long)==4
> sizeof(int)==4
> sizeof(short)==2
> sizeof(int64)==1

I presume that's a typo for sizeof(char)==1?

There's a lot of code out there written back in the days when 32-bit
machines were the state of the art, which therefore assumes that long
is 32 bits. I consider that to be defective code - it's always possible
to write code so that it works correctly, regardless of whether long is
32 bits or 64 bits. However, when 64-bit machines came out, as a
practical matter, many implementations  chose to deal with such code by
keeping 'long' as a 32-bit type, rather than breaking it by making
'long' a 64-bit type. Instead, they added things like int64 for the new
64 bit type.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik <kuyper@wizard.net> napisal w wiadomosci
news:1164835979.036922.233990@j44g2000cwa.googlegroups.com...
> jam wrote:
>> If I am not mistaken standard says that:
>>
>> sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1
>
> Actually, it doesn't. The required relationships are in terms of the
> range of values represented, not in terms of the amount of memory used
> to store the values. It's perfectly legal for sizeof(short) >
> sizeof(long), as long as SHORT_MAX < LONG_MAX.
>
> Of course, as a practical matter, just about everyone uses 2's
> complement integer types that use every bit they have available, so the
> sizeof(type) and the TYPE_MAX macros will usually be in the same order,
> for all types.
>
>> the following lengthes satisfy this condition:
>>      8      >     4     >      2       >      1      ==1
>> so why int64 on microsoft platform with:
>> sizeof(int64)==8
>> sizeof(long)==4
>> sizeof(int)==4
>> sizeof(short)==2
>> sizeof(int64)==1
>
> I presume that's a typo for sizeof(char)==1?
>
> There's a lot of code out there written back in the days when 32-bit
> machines were the state of the art, which therefore assumes that long
> is 32 bits. I consider that to be defective code - it's always possible
> to write code so that it works correctly, regardless of whether long is
> 32 bits or 64 bits. However, when 64-bit machines came out, as a

The customer need not be happy that your application uses twice as much
memory as it used to.
Although it works correctly, performance suffers.

> practical matter, many implementations  chose to deal with such code by
> keeping 'long' as a 32-bit type, rather than breaking it by making
> 'long' a 64-bit type. Instead, they added things like int64 for the new
> 64 bit type.

Long is a 64-bit type in Visual Basic.  And let it stay there.

The name for the 64-bit type was always long long int
and the rule was that a plain int is equivalent to a short int or to a long
int depending on the platform.
I prefer this convention because I would like the range of long int to be
well defined.
It is very strange that the basic types are so vaguely defined by the
standard.
It does not happen in any other language I know about.
Sometimes the ranges of variables just must have absolute limits.
Chris


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik <kuyper@wizard.net> napisal w wiadomosci
> news:1164835979.036922.233990@j44g2000cwa.googlegroups.com...
> > jam wrote:
> >> If I am not mistaken standard says that:
> >>
> >> sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1
> >
> > Actually, it doesn't. The required relationships are in terms of the
> > range of values represented, not in terms of the amount of memory used
> > to store the values. It's perfectly legal for sizeof(short) >
> > sizeof(long), as long as SHORT_MAX < LONG_MAX.
> >
> > Of course, as a practical matter, just about everyone uses 2's
> > complement integer types that use every bit they have available, so the
> > sizeof(type) and the TYPE_MAX macros will usually be in the same order,
> > for all types.
> >
> >> the following lengthes satisfy this condition:
> >>      8      >     4     >      2       >      1      ==1
> >> so why int64 on microsoft platform with:
> >> sizeof(int64)==8
> >> sizeof(long)==4
> >> sizeof(int)==4
> >> sizeof(short)==2
> >> sizeof(int64)==1
> >
> > I presume that's a typo for sizeof(char)==1?
> >
> > There's a lot of code out there written back in the days when 32-bit
> > machines were the state of the art, which therefore assumes that long
> > is 32 bits. I consider that to be defective code - it's always possible
> > to write code so that it works correctly, regardless of whether long is
> > 32 bits or 64 bits. However, when 64-bit machines came out, as a
>
> The customer need not be happy that your application uses twice as much
> memory as it used to.
> Although it works correctly, performance suffers.
>
> > practical matter, many implementations  chose to deal with such code by
> > keeping 'long' as a 32-bit type, rather than breaking it by making
> > 'long' a 64-bit type. Instead, they added things like int64 for the new
> > 64 bit type.
>
> Long is a 64-bit type in Visual Basic.  And let it stay there.

Too late. It's already a 64-bit type on many C/C++ implementations.

> The name for the 64-bit type was always long long int

Except where it was named 'long', or 'int64' or 'int64_t' or '_int64'
or any of a wide variety of other things. In C99 it has been
standardized as 'int64_t', not 'long long'. C99 has a 'long long' type,
which could be 64 bits, but it could also be 72 bits, or 128 bits, or
any other size greater than 64 bits. These will be included in C++ in
some future version (unless it's already been done - I haven't been
paying as much attention to the TCs as I should).

> and the rule was that a plain int is equivalent to a short int or to a long
> int depending on the platform.

That was commonplace, but not required by any standard, and code which
relied on that was always inherently non-portable.

> I prefer this convention because I would like the range of long int to be
> well defined.

It has never been well-defined, but it has always had well-defined
limits. Adding a requirement that 'int' be the same size as either
'short' or 'long' would not change either of those two facts, it would
just add another constraint on the possible sizes. That constraint
wouldn't prevent 'long' from being 64 bits. 'int' is allowed to be a 64
bit type. For that matter, 'char' is allowed to be a 64 bit type.

> It is very strange that the basic types are so vaguely defined by the
> standard.
> It does not happen in any other language I know about.
> Sometimes the ranges of variables just must have absolute limits.

Then you'll probably like a feature that was added In the C99 standard,
size-named types. I gather that they will be added to the C++ standard
sometime soon. In C99, they have names like int32_t, for an optional
type with exactly 32 bits, int_fast32_t and int_least32_t, for the
mandatory types with at least 32 bits that are, respectively, fastest
to use and smallest in size.

I believe that for almost all purely internal uses, either the fast or
small types should be used; the exact-sized types should only be used
to meet externally imposed interface requirements. However, I expect
that most people will use exact-sized types routinely, whether or not
they need to.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net ha scritto:
> jam wrote:
>> If I am not mistaken standard says that:
>>
>> sizeof(long)>=3Dsizeof(int)>=3Dsizeof(short)>=3Dsizeof(char)=3D=3D1
>=20
> Actually, it doesn't. The required relationships are in terms of the
> range of values represented, not in terms of the amount of memory used
> to store the values. It's perfectly legal for sizeof(short) >
> sizeof(long), as long as SHORT_MAX < LONG_MAX.

That's plain wrong. There is an explicit requirement about storage in
3.9.1/2: "There are four signed integer types: =E2=80=9Csigned char=E2=80=
=9D, =E2=80=9Cshort
int=E2=80=9D, =E2=80=9Cint=E2=80=9D, and =E2=80=9Clong int.=E2=80=9D In t=
his list, each type provides at least
as much storage as those preceding it in the list."

Ganesh

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik <kuyper@wizard.net> napisal w wiadomosci
> news:1164835979.036922.233990@j44g2000cwa.googlegroups.com...
> > jam wrote:
> >> If I am not mistaken standard says that:

> >> sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1

> > Actually, it doesn't. The required relationships are in terms of the
> > range of values represented, not in terms of the amount of memory used
> > to store the values. It's perfectly legal for sizeof(short) >
> > sizeof(long), as long as SHORT_MAX < LONG_MAX.

> > Of course, as a practical matter, just about everyone uses 2's
> > complement integer types that use every bit they have available, so the
> > sizeof(type) and the TYPE_MAX macros will usually be in the same order,
> > for all types.

> >> the following lengthes satisfy this condition:
> >>      8      >     4     >      2       >      1      ==1
> >> so why int64 on microsoft platform with:
> >> sizeof(int64)==8
> >> sizeof(long)==4
> >> sizeof(int)==4
> >> sizeof(short)==2
> >> sizeof(int64)==1

> > I presume that's a typo for sizeof(char)==1?

> > There's a lot of code out there written back in the days when 32-bit
> > machines were the state of the art, which therefore assumes that long
> > is 32 bits. I consider that to be defective code - it's always possible
> > to write code so that it works correctly, regardless of whether long is
> > 32 bits or 64 bits. However, when 64-bit machines came out, as a

> The customer need not be happy that your application uses twice as much
> memory as it used to.
> Although it works correctly, performance suffers.

I'm not sure what you're getting at.  If you're concerned with
space, C++ gives you enough alternatives (and you certainly
aren't using long).

> > practical matter, many implementations  chose to deal with such code by
> > keeping 'long' as a 32-bit type, rather than breaking it by making
> > 'long' a 64-bit type. Instead, they added things like int64 for the new
> > 64 bit type.

> Long is a 64-bit type in Visual Basic.  And let it stay there.

long is a 64 bit type on most modern machines, I think.  But the
standard doesn't guarantee it.  It could be 32 bits, or 36, or
48, or 60, or maybe 72 (just to name some of the possibilities
I'm actually familiar with).

> The name for the 64-bit type was always long long int

Since when?  long long was added to C99; it didn't exist before.
And all that is required is that it be at least 64 bits.  On
some machines, it might be 72 bits, or 92, or 120.

> and the rule was that a plain int is equivalent to a short int or to a long
> int depending on the platform.

Again, since when.  That's likely to be the case where the
machine only has two available sizes.  If the machine only has
one available size, and it is at least 32 bits, it's even likely
that short, int and long all have the same size.

> I prefer this convention because I would like the range of long int to be
> well defined.
> It is very strange that the basic types are so vaguely defined by the
> standard.
> It does not happen in any other language I know about.

Really.  I think that Java is about the only language which does
define the size.  Fortran certainly didn't, nor does Lisp, nor
any of the languages in the Pascal family (including Ada).
Strictly defining the size limits the number of platforms for
which you can have an efficient implementation, and really
doesn't help the programmer that much.

> Sometimes the ranges of variables just must have absolute limits.

So you impose them.  It would be a rather exceptional case where
those limits happened to correspond exactly to the word size of
the machine anyway.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> kuyper@wizard.net ha scritto:
> > jam wrote:
> >> If I am not mistaken standard says that:
> >>
> >> sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1
> >
> > Actually, it doesn't. The required relationships are in terms of the
> > range of values represented, not in terms of the amount of memory used
> > to store the values. It's perfectly legal for sizeof(short) >
> > sizeof(long), as long as SHORT_MAX < LONG_MAX.
>
> That's plain wrong. There is an explicit requirement about storage in
> 3.9.1/2: "There are four signed integer types: "signed char", "short
> int", "int", and "long int." In this list, each type provides at least
> as much storage as those preceding it in the list."

You're right, of course. I'd like to blame my mistake on confusion
between the C and C++ standards, since I monitor newgroups devoted to
both standards. However, I have to admit that I'd never noticed that
this was one of the differences between those two standards. This
should probably be mentioned in appendix C.1.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

farid.mehrabi@gmail.com (jam) wrote (abridged):
> If I am not mistaken standard says that:
>
> sizeof(long)>=sizeof(int)>=sizeof(short)>=sizeof(char)==1
> the following lengthes satisfy this condition:
>      8      >     4     >      2       >      1      ==1
> so why int64 on microsoft platform with:
> sizeof(int64)==8
> sizeof(long)==4
> sizeof(int)==4
> sizeof(short)==2
> sizeof(int64)==1
>
> int64 looks ugly

Microsoft wanted sizeof(long)==4 for their 64-bit platform to ease porting
from their 32-bit platform. In particular, they wanted binary
compatibility for structures such as:

     struct Demo {
         long a;
         long b;
     };

They weren't so concerned about the size of pointers because structures
with pointers are rarely memcpy'd into permanent memory.

I gleaned the above from a blog entry at:
   http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

There is much discussion in the comments as to the wisdom of Microsoft's
choice.

-- Dave Harris, Nottingham, UK.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]