kanze wrote:

>"Alan M. Feldstein" wrote:
>
>
>>if ( form == hexadecimal )
>>    type = ( first of ... in which its value can be represented )
>>
>>
>
>
>
>>I asked myself if the "value" can be represented in type int.
>>To answer this question, I need to know the value of literal
>>0xffffffff /before/ I try to apply the rule in Section 2.13.1
>>paragraph 2, since that paragraph only deals with determining
>>the type.
>>
>>
>>Up to this point in my argument, we are still free to decide
>>that the value is -1, and conclude that the value /can/ be
>>represented in type int.
>>
>>
>
>I don't think so, and I think you clearly explained why in your
>first paragraph: we have to know the value of the literal before
>applying the rules, to determine the type.  Given this, it would
>seem rather obvious that the value cannot depend on the type --
>otherwise, we have a circular definition.
>
Yes, we have to know the value of the literal before applying the rule
in Section 2.13.1 paragraph 2. And the value cannot depend on the type
because, as you pointed out, we would have a circular definition.

My point was that Section 2.13.1 paragraph 2 does not constrain the
decision about value. Specifically, it does not depend on type.

>  The only reasonable
>interpretation is that the value here is the actual value, over
>the set of integers, without any considerations of how any
>specific type might be represented internally in the
>implementation.
>
>
I agree, and this interpretation is even more reasonable when Section
2.13.1 paragraph 1 is considered. That paragraph seems to provide the
constraint on the decision about value.

>--
>James Kanze                                           GABI Software
>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                      ]
>
>
>


--

Alan Feldstein

Cosmic Horizon logo

http://www.alanfeldstein.com/

---
[ 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                      ]

#include <cstdio>
using std::printf;
void f(int) { printf("signed int\n"); }
void f(unsigned int) { printf("unsigned int\n"); }
void f(long) { printf("signed long\n"); }
void f(unsigned long) { printf("unsigned long\n"); }
int main()
{
    f(0xffffffff);
}

With the LP64 data model and INCITS/ISO/IEC 14882-2003, I expect "signed
int" to appear on the screen. On Sun Studio 11 however, "unsigned int"
appears, leading me to the conclusion that that is a nonconforming compiler.
--

Alan Feldstein

http://www.alanfeldstein.com/

---
[ 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                      ]

Alan M. Feldstein wrote:
> #include <cstdio>
> using std::printf;
> void f(int) { printf("signed int\n"); }
> void f(unsigned int) { printf("unsigned int\n"); }
> void f(long) { printf("signed long\n"); }
> void f(unsigned long) { printf("unsigned long\n"); }
> int main()
> {
>     f(0xffffffff);
> }
>
> With the LP64 data model and INCITS/ISO/IEC 14882-2003, I expect "signed
> int" to appear on the screen. On Sun Studio 11 however, "unsigned int"
> appears, leading me to the conclusion that that is a nonconforming compiler.

What is INT_MAX defined as, for that compiler?

---
[ 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                      ]

Alan M. Feldstein wrote:
> #include <cstdio>
> using std::printf;
> void f(int) { printf("signed int\n"); }
> void f(unsigned int) { printf("unsigned int\n"); }
> void f(long) { printf("signed long\n"); }
> void f(unsigned long) { printf("unsigned long\n"); }
> int main()
> {
>    f(0xffffffff);
> }
>
> With the LP64 data model and INCITS/ISO/IEC 14882-2003, I expect
> "signed int" to appear on the screen.

Should it be common knowledge what "LP64" is?  My inferiority complex
is kicking in...

> On Sun Studio 11 however,
> "unsigned int" appears, leading me to the conclusion that that is a
> nonconforming compiler.

What are the CHAR_BIT and sizeof(int) on that platform/compiler?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ 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 wrote:
> Alan M. Feldstein wrote:
>
>>#include <cstdio>
>>using std::printf;
>>void f(int) { printf("signed int\n"); }
>>void f(unsigned int) { printf("unsigned int\n"); }
>>void f(long) { printf("signed long\n"); }
>>void f(unsigned long) { printf("unsigned long\n"); }
>>int main()
>>{
>>    f(0xffffffff);
>>}
>>
>>With the LP64 data model and INCITS/ISO/IEC 14882-2003, I expect "signed
>>int" to appear on the screen. On Sun Studio 11 however, "unsigned int"
>>appears, leading me to the conclusion that that is a nonconforming compiler.
>
>
> What is INT_MAX defined as, for that compiler?

Type int has 32 bits, and INT_MAX is defined as 2147483647 (which would
be 0x7fffffff in hex).

If I may speak for Alan, his claim is that the hex literal 0xffffffff
(all bits set) can be represented as a signed int with the value -1.

---
Steve Clamage
Sun Microsystems, Inc

---
[ 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                      ]

INT_MIN is -2147483648
INT_MAX is 2147483647

This is as expected for the LP64 data model. My claim is that the literal
0xffffffff
is required by the C++ Standard to have type int in this data model.
Section 2.13.1 paragraph 2 states that "The type of an integer literal
depends on its form, value, and suffix ... If it is ... hexadecimal and
has no suffix, it has the first of these types in which its value can be
represented: int, unsigned int, long int, unsigned long int." The given
literal should have type int because its value can be represented in a
32-bit int (by interpreting it as -1). Therefore, I claim that its type
is int in a conforming compiler.
kuyper@wizard.net wrote:

>Alan M. Feldstein wrote:
>
>
>>#include <cstdio>
>>using std::printf;
>>void f(int) { printf("signed int\n"); }
>>void f(unsigned int) { printf("unsigned int\n"); }
>>void f(long) { printf("signed long\n"); }
>>void f(unsigned long) { printf("unsigned long\n"); }
>>int main()
>>{
>>    f(0xffffffff);
>>}
>>
>>With the LP64 data model and INCITS/ISO/IEC 14882-2003, I expect "signed
>>int" to appear on the screen. On Sun Studio 11 however, "unsigned int"
>>appears, leading me to the conclusion that that is a nonconforming compiler.
>>
>>
>
>What is INT_MAX defined as, for that compiler?
>
>---
>[ 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                      ]
>
>
>


--

Alan Feldstein

http://www.alanfeldstein.com/

---
[ 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                      ]

Victor Bazarov wrote:
> Alan M. Feldstein wrote:
>
>>#include <cstdio>
>>using std::printf;
>>void f(int) { printf("signed int\n"); }
>>void f(unsigned int) { printf("unsigned int\n"); }
>>void f(long) { printf("signed long\n"); }
>>void f(unsigned long) { printf("unsigned long\n"); }
>>int main()
>>{
>>   f(0xffffffff);
>>}
>>
>>With the LP64 data model and INCITS/ISO/IEC 14882-2003, I expect
>>"signed int" to appear on the screen.
>
>
> Should it be common knowledge what "LP64" is?  My inferiority complex
> is kicking in...

Some common notations for architecture choices:
ILP32 - int, long, and pointer each are 32 bits
LP64  - long and pointer are 64 bits. int is 32 bits
P64   - pointer is 64 bits. int and long are 32 bits


>
>
>>On Sun Studio 11 however,
>>"unsigned int" appears, leading me to the conclusion that that is a
>>nonconforming compiler.
>
>
> What are the CHAR_BIT and sizeof(int) on that platform/compiler?

CHAR_BIT    is 8
sizeof(int) is 4

---
Steve Clamage
Sun Microsystems

---
[ 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                      ]

Alan M. Feldstein wrote:
> My claim is that the literal 0xffffffff
> is required by the C++ Standard to have type int in this data model.
> Section 2.13.1 paragraph 2 states that "The type of an integer literal
> depends on its form, value, and suffix ... If it is ... hexadecimal and
> has no suffix, it has the first of these types in which its value can be
> represented: int, unsigned int, long int, unsigned long int." The given
> literal should have type int because its value can be represented in a
> 32-bit int (by interpreting it as -1). Therefore, I claim that its type
> is int in a conforming compiler.

Hexadecimal 0xffffffff is 4294967295, by the definition of what the
hexadecimal number is. And the literal is a number, not a specific
sequence of bits used to represent a number.

In particular, you cannot assume that the following assertions are
true:

  (~0 + 1) == 0
  (~1 + 1) == -1
  (~2 + 1) == -2
  (~3 + 1) == -3

because their result depends on bitwise representation of signed int.

--
Andrei Polushin

---
[ 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                      ]

"Alan M. Feldstein" wrote:
> INT_MIN is -2147483648
> INT_MAX is 2147483647
>
> This is as expected for the LP64 data model. My claim is that the literal
> 0xffffffff
> is required by the C++ Standard to have type int in this data model.
> Section 2.13.1 paragraph 2 states that "The type of an integer literal
> depends on its form, value, and suffix ... If it is ... hexadecimal and
> has no suffix, it has the first of these types in which its value can be
> represented: int, unsigned int, long int, unsigned long int." The given
> literal should have type int because its value can be represented in a
> 32-bit int (by interpreting it as -1).

That's where you go wrong. The standard does not justify interpreting
it as -1. On such an implementation, an unsigned int having the value
of 0xFFFFFFFF would have the same bit pattern as an int representing
-1, but that doesn't determine what value a hexidecimal literal of that
form represents. The hexidecimal literal 0xFFFFFFFF represents the same
number as the decimal literal 4294967295. Since 4294967295 is greater
than INT_MAX, so is 0xFFFFFFFF, and you have to move on to the next
type on the list, which is unsigned int.

---
[ 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                      ]

Andrei Polushin wrote:
> Hexadecimal 0xffffffff is 4294967295, by the definition of what the
> hexadecimal number is. And the literal is a number, not a specific
> sequence of bits used to represent a number.
>
> In particular, you cannot assume that the following assertions are
> true:
>
>   (~0 + 1) == 0
>   (~1 + 1) == -1
>   (~2 + 1) == -2
>   (~3 + 1) == -3
>
> because their result depends on bitwise representation of signed int.

Pardon, I'm wrong here, 5.3.1/7 says the assertions above are true.

But I feel my first statement is still correct: the literal is a
number, and its representation type should preserve its numeric value
as is. As soon as the literal is represented, you may apply bitwise
arithmetic to it.

--
Andrei Polushin

---
[ 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                      ]

Andrei Polushin wrote:

>Alan M. Feldstein wrote:
>
>
>>My claim is that the literal 0xffffffff
>>is required by the C++ Standard to have type int in this data model.
>>Section 2.13.1 paragraph 2 states that "The type of an integer literal
>>depends on its form, value, and suffix ... If it is ... hexadecimal and
>>has no suffix, it has the first of these types in which its value can be
>>represented: int, unsigned int, long int, unsigned long int." The given
>>literal should have type int because its value can be represented in a
>>32-bit int (by interpreting it as -1). Therefore, I claim that its type
>>is int in a conforming compiler.
>>
>>
>
>Hexadecimal 0xffffffff is 4294967295, by the definition of what the
>hexadecimal number is. And the literal is a number, not a specific
>sequence of bits used to represent a number.
>
>In particular, you cannot assume that the following assertions are
>true:
>
>  (~0 + 1) == 0
>  (~1 + 1) == -1
>  (~2 + 1) == -2
>  (~3 + 1) == -3
>
>because their result depends on bitwise representation of signed int.
>
>
>
if ( form == hexadecimal )
    type = ( first of ... in which its value can be represented )

I asked myself if the "value" can be represented in type int. To answer
this question, I need to know the value of literal
0xffffffff
/before/ I try to apply the rule in Section 2.13.1 paragraph 2, since
that paragraph only deals with determining the type.

Section 3.9 paragraph 4 says about value that it "is one discrete
element of an implementation-defined set of values." That phrase agrees
with both interpretations.

Furthermore, Section 3.9.1 paragraph 7 states that "the representations
of integral types shall define values by use of a pure binary numeration
system", deliberately not constraining an implementation to a particular
representation, such as two's complement.

Up to this point in my argument, we are still free to decide that the
value is -1, and conclude that the value /can/ be represented in type int.

However, Section 2.13.1 paragraph 1 describes a hexadecimal integer
literal using the pure base 16 mathematical interpretation. "The
lexically first digit of the sequence of digits is the most significant
. A hexadecimal integer literal (base sixteen) ... consists of a
sequence of hexadecimal digits, which include the decimal digits and the
letters a through f and A through F with decimal values ten through
fifteen." This is what constrains us to decide that the value is
4294967295, and conclude that the value /cannot/ be represented in type int.

I was wrong.
--

Alan Feldstein

http://www.alanfeldstein.com/

---
[ 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                      ]

"Alan M. Feldstein" wrote:
> INT_MIN is -2147483648
> INT_MAX is 2147483647
>
> This is as expected for the LP64 data model. My claim is that the literal
> 0xffffffff
> is required by the C++ Standard to have type int in this data model.
> Section 2.13.1 paragraph 2 states that "The type of an integer literal
> depends on its form, value, and suffix ... If it is ... hexadecimal and
> has no suffix, it has the first of these types in which its value can be
> represented: int, unsigned int, long int, unsigned long int." The given
> literal should have type int because its value can be represented in a
> 32-bit int (by interpreting it as -1). Therefore, I claim that its type
> is int in a conforming compiler.
> kuyper@wizard.net wrote:

The value of the C++ hexadecimal constant 0xffffffff is not open to
interpretation. It is precisely equal to the value 4294967295 in
decimal notation. The decimal value -1 written as a hexadecimal
constant would look like this:

    -0x1

Greg

---
[ 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                      ]

Greg Herlihy wrote:
> "Alan M. Feldstein" wrote:
> > INT_MIN is -2147483648
> > INT_MAX is 2147483647

> > This is as expected for the LP64 data model. My claim is
> > that the literal 0xffffffff is required by the C++ Standard
> > to have type int in this data model.  Section 2.13.1
> > paragraph 2 states that "The type of an integer literal
> > depends on its form, value, and suffix ... If it is ...
> > hexadecimal and has no suffix, it has the first of these
> > types in which its value can be represented: int, unsigned
> > int, long int, unsigned long int." The given literal should
> > have type int because its value can be represented in a
> > 32-bit int (by interpreting it as -1). Therefore, I claim
> > that its type is int in a conforming compiler.

> The value of the C++ hexadecimal constant 0xffffffff is not
> open to interpretation. It is precisely equal to the value
> 4294967295 in decimal notation. The decimal value -1 written
> as a hexadecimal constant would look like this:

>     -0x1

More or less.  More exactly, an integer literal can never be
negative: both -1 and -0x1 are expressions consisting of two
separate tokens.

This leads to another interesting bit of trivia: on a strictly
conforming implementation (no long long), you cannot write
LONG_MIN in the natural way (on a machine using twos
complement).  If long is 32 bits, for example, the expression
-2147483648 is ill-formed, since the integral literal cannot be
represented in any of the allowed types.  We have to write
something like (-2147483647-1).

--
James Kanze                                           GABI Software
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                      ]

Steve Clamage wrote:
> Victor Bazarov wrote:
> > Alan M. Feldstein wrote:

> >>#include <cstdio>
> >>using std::printf;
> >>void f(int) { printf("signed int\n"); }
> >>void f(unsigned int) { printf("unsigned int\n"); }
> >>void f(long) { printf("signed long\n"); }
> >>void f(unsigned long) { printf("unsigned long\n"); }
> >>int main()
> >>{
> >>   f(0xffffffff);
> >>}

> >>With the LP64 data model and INCITS/ISO/IEC 14882-2003, I
> >>expect "signed int" to appear on the screen.

> > Should it be common knowledge what "LP64" is?  My
> > inferiority complex is kicking in...

> Some common notations for architecture choices:
> ILP32 - int, long, and pointer each are 32 bits
> LP64  - long and pointer are 64 bits. int is 32 bits
> P64   - pointer is 64 bits. int and long are 32 bits

Hmmm.  I've always seen it expanded; i.e. ILP32, I32LP64, etc.

How common they are, of course, depends on where you are
situated.  They seem to be fairly common in environments which
have made, or are making, the transition from 32 bit to 64 bit
machines.  Until recently (and even today), however, I imagine
that most Windows programmers would never have heard of them.

> >>On Sun Studio 11 however, "unsigned int" appears, leading me
> >>to the conclusion that that is a nonconforming compiler.

> > What are the CHAR_BIT and sizeof(int) on that platform/compiler?

> CHAR_BIT    is 8
> sizeof(int) is 4

Which still doesn't tell us what we need to know.  He asked the
wrong question; it should have been "what are the values of
INT_MAX and INT_MIN?"  While not the case in Sun Studio 11 (or
any other modern implementation I know of), a conforming
implementation could have CHAR_BIT 8 and sizeof(int) 4, and
still have INT_MAX say 8388607 and UINT_MAX 16777215 -- in which
case, his code should output "signed long".

--
James Kanze                                           GABI Software
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                      ]

"Alan M. Feldstein" wrote:
> INT_MIN is -2147483648
> INT_MAX is 2147483647

> This is as expected for the LP64 data model. My claim is that
> the literal 0xffffffff is required by the C++ Standard to have
> type int in this data model.

How can it possibly have the type int?  According to the hex
calculator I have handy, 0xFFFFFFFF is 4294967295, which is
larger than 2147483647.  So it can't be represented in an int.

> Section 2.13.1 paragraph 2 states that "The type of an integer
> literal depends on its form, value, and suffix ... If it is
> ... hexadecimal and has no suffix, it has the first of these
> types in which its value can be represented: int, unsigned
> int, long int, unsigned long int."

So it must be an unsigned int.

> The given literal should have type int because its value can
> be represented in a 32-bit int (by interpreting it as -1).

Where do you get the -1 from?  The value of the literal is
0xFFFFFFFF: 4294967295 in decimal, 037777777777 in octal.  I
find it easier to think in decimal, unless I'm concerned with
bit patterns, but if you prefer hex, then INT_MAX, above, is
0x7FFFFFFF, and you come to the same conclusions.

And I'm still curious as to where you get that -1 from -- I
can't see a minus sign anywhere.

--
James Kanze                                           GABI Software
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                      ]

"Alan M. Feldstein" wrote:
> Andrei Polushin wrote:

> >Alan M. Feldstein wrote:

> >>My claim is that the literal 0xffffffff is required by the
> >>C++ Standard to have type int in this data model.  Section
> >>2.13.1 paragraph 2 states that "The type of an integer
> >>literal depends on its form, value, and suffix ... If it is
> >>... hexadecimal and has no suffix, it has the first of these
> >>types in which its value can be represented: int, unsigned
> >>int, long int, unsigned long int." The given literal should
> >>have type int because its value can be represented in a
> >>32-bit int (by interpreting it as -1). Therefore, I claim
> >>that its type is int in a conforming compiler.

> >Hexadecimal 0xffffffff is 4294967295, by the definition of
> >what the hexadecimal number is. And the literal is a number,
> >not a specific sequence of bits used to represent a number.

    [...]
> if ( form == hexadecimal )
>     type = ( first of ... in which its value can be represented )

> I asked myself if the "value" can be represented in type int.
> To answer this question, I need to know the value of literal
> 0xffffffff /before/ I try to apply the rule in Section 2.13.1
> paragraph 2, since that paragraph only deals with determining
> the type.

> Section 3.9 paragraph 4 says about value that it "is one
> discrete element of an implementation-defined set of values."
> That phrase agrees with both interpretations.

> Furthermore, Section 3.9.1 paragraph 7 states that "the
> representations of integral types shall define values by use
> of a pure binary numeration system", deliberately not
> constraining an implementation to a particular representation,
> such as two's complement.

> Up to this point in my argument, we are still free to decide
> that the value is -1, and conclude that the value /can/ be
> represented in type int.

I don't think so, and I think you clearly explained why in your
first paragraph: we have to know the value of the literal before
applying the rules, to determine the type.  Given this, it would
seem rather obvious that the value cannot depend on the type --
otherwise, we have a circular definition.  The only reasonable
interpretation is that the value here is the actual value, over
the set of integers, without any considerations of how any
specific type might be represented internally in the
implementation.

--
James Kanze                                           GABI Software
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                      ]