ivr@nothis.emails.ru ("Ioannis Vranos") writes:

|>  ""MiniDisc_2k2"" <MattDelB@nospam.com> wrote in message
|>  news:3nmPa.50$zd4.42@lakeread02...

|>  > Well actually I was using chars only to save my mind from
|>  > calculating it all out. Let's try again.

|>  > I also intended this code to be used on a two's complement
|>  > machine.

Which doesn't change anything here.

|>  > Use this:

|>  > signed int a =3D 3;
|>  > unsigned int b =3D -1;    /* thus being the highest number represen=
ted by
|>  > unsigned int*/
|>  > if (b<a)

|>  > Now. If b were converted to a signed integer, b<a would be -1<3
|>  > =3D=3D true. If a were converted to an unsigned integer, we would
|>  > get 65535 < 3 =3D=3D false (in 16-bit environment). Which
|>  > representation does it follow. Does it proceed like the char
|>  > conversion, where it is converted to a signed int? Is this at
|>  > all standardized, or does the compiler get to pick?

|>  The C++ standard says:
|> =20
|>  [conv.prom] 4.5 Integral promotions

Wrong section.  There are no promotions here.

|>  1 An rvalue of type char, signed char, unsigned char, short int,
|>  or unsigned short int can be converted to an rvalue of type int if
|>  int can represent all the values of the source type; otherwise,
|>  the source rvalue can be converted to an rvalue of type unsigned
|>  int.

    [...]

|>  The (1) is your case.

Not at all.  That paragraph only applies if the type is char, signed
char, unsigned char, short int or unsigned short int.  There are none
of those here.

|>  The answer is that everything is promoted to unsigned int and you
|>  must get a compiler warning about comparing signed with unsigned
|>  values.

Right answer, wrong reason.  See 5/9 -- it gives the complete list of
conversions (call the usual arithmetic conversions) which apply to
binary operators.  In particular, the last point "Otherwise, if either
operand is unsigned, the other shall be converted to unsigned."

|>  Try to compile and see.

That's not always a valid solution.  If he were comparing a long and
an unsigned int, for example, the conversions used will depend on the
implementation.

--=20
James Kanze                             mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                 Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  +33 1 41 89 80 93

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

|>  In article <%jjPa.31$zd4.2@lakeread02>, MiniDisc_2k2
|>  <MattDelB@nospam.com> writes
|>  >Okay, here's a question about the standard. What does it say about
|>  >unsigned/signed mismatches in a comparison statement:

|>  >char a =3D 3;
|>  >unsigned char b =3D 255;
|>  >if (a<b)

|>  >Now what's the real answer here? If a is converted to unsigned,
|>  >then b>a.  But, if b is converted to signed,then a>b. What's the
|>  >correct coversion (what is the compiler supposed to do?)

|>  No, the normal integral promotions are applied first Which only
|>  becomes mildly interesting on systems where all integral types are
|>  the same size.

But on such systems, 255 is within the range of char, so the problem
isn't interesting either.  (For that matter, as formulated, it isn't
interesting on a system with 9 bit bytes either.)

--=20
James Kanze                             mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                 Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  +33 1 41 89 80 93

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3f0ef04e$0$242$4d4eb98e@read.news.gr.uu.net>,
 on Sat, 12 Jul 2003 00:16:53 +0000 (UTC),
 ivr@nothis.emails.ru ("Ioannis Vranos") wrote:

> "Andy Sawyer" <andys@despammed.com> wrote in message
> news:ptkiszvi.fsf@evo6.com...
> >
> > Remember that char, signed char and unsigned char are three disticnt
> > types.
>
> char is implemented either as signed char or as unsigned char.

Please cite your reference. I suggest you read 3.9.1p1, which says in part:

,----
| Plain char, signed char, and unsigned char are three distinct types.
`----

It's in the standard (almost word-for-word - I omitted "plain").

> > In fact, unsigned char may be promoted to unsigned int (depending on the
> > environment).
>
> If the involved values fit in int, they get promoted to int. It's in the
> standard.

Again, cite your reference. I suggest you read 4.5p1, which says:

,----
| An rvalue of type char, signed char, unsigned char, short int, or
| unsigned short int can be converted to an rvalue of type int if int can
| represent all the values of the source type; otherwise, the source
| rvalue can be converted to an rvalue of type unsigned int.
`----

It's in the standard.

Note the "if int can represent *ALL* values of the source type". (my
emphasis). I suspect you're thinking of integral _conversions_, which
(in this context) happen after promotions - see 5p9. It's in the standard.

> > > So in summary, a either signed char either unsigned gets converted to
> > > int.
> >
> > I had trouble parsing that - I assume you meant
> >
> >  "So in summary, either a signed char or unsigned char gets converted to
> >  int."
> > ?
>
>
> "So in summary the variable a, either it is signed char or unsigned char
> gets converted to int

Not necessarily - it's in the standard.

> (in real world scenarios where sizeof(int)>1)".

There are real world scenarios where sizeof(int)==sizeof(char). Neither
your being unfamilair with them, nor the fact that they are less common
than those where sizeof(int)>sizeof(char) does not in any way disprove
their existence.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""Ioannis Vranos"" <ivr@nothis.emails.ru> wrote in message news:3f0ef04e$0$242$4d4eb98e@read.news.gr.uu.net...
> "Andy Sawyer" <andys@despammed.com> wrote in message
> news:ptkiszvi.fsf@evo6.com...
> >
> > Remember that char, signed char and unsigned char are three disticnt
> > types.
>
> char is implemented either as signed char or as unsigned char.
>
>
It's still a distinct 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Ioannis Vranos" <ivr@nothis.emails.ru> wrote in message
news:3f0dd160$0$245$4d4eb98e@read.news.gr.uu.net...
> ""MiniDisc_2k2"" <MattDelB@nospam.com> wrote in message
> news:%jjPa.31$zd4.2@lakeread02...
> > Okay, here's a question about the standard. What does it say about
> > unsigned/signed mismatches in a comparison statement:
> >
> > char a = 3;
> > unsigned char b = 255;
> > if (a<b)
> >
> > Now what's the real answer here? If a is converted to unsigned, then
b>a.
> > But, if b is converted to signed,then a>b. What's the correct coversion
> > (what is the compiler supposed to do?)
>
>
> At first keep in mind that char (differently from other "plain" integer
> types) can be either signed or unsigned. If you want one of the two in
> specific, you have to declare it explicitly (e.g. signed char a=3).
>
>
> Assuming you wish your above code to be:
>
>
> signed char a = 3;
> unsigned char b = 255;
> if (a<b)
>
>
> Both unsigned char and signed char get converted to int during the
> expression evaluation.
>
>
> So in summary, a either signed char either unsigned gets converted to int.
>
>

Well actually I was using chars only to save my mind from calculating it all
out. Let's try again.

I also intended this code to be used on a two's complement machine.

Use this:

signed int a = 3;
unsigned int b = -1;    /* thus being the highest number represented by
unsigned int*/
if (b<a)

Now. If b were converted to a signed integer, b<a would be -1<3 == true. If
a were converted to an unsigned integer, we would get 65535 < 3 == false (in
16-bit environment). Which representation does it follow. Does it proceed
like the char conversion, where it is converted to a signed int? Is this at
all standardized, or does the compiler get to pick?

--
MiniDisc_2k2

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <%jjPa.31$zd4.2@lakeread02>,
 on Thu, 10 Jul 2003 20:34:29 +0000 (UTC),
 MattDelB@nospam.com ("MiniDisc_2k2") wrote:

> Okay, here's a question about the standard. What does it say about
> unsigned/signed mismatches in a comparison statement:
>
> char a = 3;
> unsigned char b = 255;
> if (a<b)
>
> Now what's the real answer here? If a is converted to unsigned, then b>a.
> But, if b is converted to signed,then a>b
>
> What's the correct coversion
> (what is the compiler supposed to do?)

5.9p2 tells us that the usual arithmetic conversions (5p9) are performed.

4.5p1 tells us that 'a' is promoted to signed int,

It also tells us that b is promoted to either signed int or unsigned
int, depending on the implementation, specifically:

,----
| An rvalue of type char, signed char, unsigned char, short int, or
| unsigned short int can be converted to an rvalue of type int if int
| can represent all the values of the source type; otherwise, the source
| rvalue can be converted to an rvalue of type unsigned int.
`----

 Either way, it will still have the value 255 (I assume from your magic
number of 255, you're thinking of a platform with 8-bit characters and
you're concerned about sign-extention? Not a problem here :)

If b has been promoted to signed int (such as in an 8-bit char
environment), then the comparison is performed with signed integers, so
(a<b) yields true.

If b has been promoted to unsigned int, a is then also converted to
unsigned int (5p9) and the comparison is performed using unsigned
integers, and again (a<b) yields true.

In this last case (b promoted to unsigned, a converted to unsigned),
then the result is highly dependant on the actual value of a, as 4.7p3
says:

,----
| If the destination type is signed, the value is unchanged if it can be
| represented in the destination type (and bitfield width); otherwise,
| the value is implementation-defined.
`----

Since, in your example, a == 3, then it can comfortable fit inside an
unsigned int and hence is unchanged.

At least, that's the way _I_ read the standard :)

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3nmPa.50$zd4.42@lakeread02>,
 on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),
 MattDelB@nospam.com ("MiniDisc_2k2") wrote:

> Well actually I was using chars only to save my mind from calculating it all
> out. Let's try again.
>
> I also intended this code to be used on a two's complement machine.
>
> Use this:
>
> signed int a = 3;
> unsigned int b = -1;    /* thus being the highest number represented by
> unsigned int*/

No, it's a signed integer converted to an unsigned integer. And it's a
value that the unsigned target cannot represent, so the value of b is
actually implementation-defined.
If you *actually* want the highest value represented by an unsigned
integer, then write::

unsinged int b = std::numeric_limits<unsigned int>::max();

> if (b<a)
>
> Now. If b were converted to a signed integer

Which it won't be.

>  b<a would be -1<3 == true. If
> a were converted to an unsigned integer

It will be.

> we would get 65535 < 3 == false (in
> 16-bit environment). Which representation does it follow. Does it proceed
> like the char conversion, where it is converted to a signed int? Is this at
> all standardized, or does the compiler get to pick?

It's standardized in detail, see:

 4.5 Integral Promotions
 4.7 Integral Conversions
 5p9 "the usual suspects^H^H^H^H^H^H^H^H arithmetic conversions":)

What the compiler *can* pick is the result of the conversion from signed
to unigned types if the value of the signed type cannot be represented
in the unsigned type (see 4.7p3)

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""MiniDisc_2k2"" <MattDelB@nospam.com> wrote in message
news:3nmPa.50$zd4.42@lakeread02...
>
>
> Well actually I was using chars only to save my mind from calculating it
all
> out. Let's try again.
>
> I also intended this code to be used on a two's complement machine.
>
> Use this:
>
> signed int a = 3;
> unsigned int b = -1;    /* thus being the highest number represented by
> unsigned int*/
> if (b<a)
>
> Now. If b were converted to a signed integer, b<a would be -1<3 == true.
If
> a were converted to an unsigned integer, we would get 65535 < 3 == false
(in
> 16-bit environment). Which representation does it follow. Does it proceed
> like the char conversion, where it is converted to a signed int? Is this
at
> all standardized, or does the compiler get to pick?


The C++ standard says:

[conv.prom] 4.5 Integral promotions
1 An rvalue of type char, signed char, unsigned char, short int, or unsigned
short
int can be converted to an rvalue of type int if int can represent all the
values of the source type; otherwise,
the source rvalue can be converted to an rvalue of type unsigned int.
2 An rvalue of type wchar_t (3.9.1) or an enumeration type (7.2) can be
converted to an rvalue of the first
of the following types that can represent all the values of its underlying
type: int, unsigned int,
long, or unsigned long.
3 An rvalue for an integral bitfield
(9.6) can be converted to an rvalue of type int if int can represent all
the values of the bitfield;
otherwise, it can be converted to unsigned int if unsigned int can represent
all the values of the bitfield.
If the bitfield
is larger yet, no integral promotion applies to it. If the
bitfield
has an enumerated type, it is treated as any other value of that type for
promotion purposes.
4 An rvalue of type bool can be converted to an rvalue of type int, with
false becoming zero and true
becoming one.
5 These conversions are called integral promotions.



The (1) is your case. The answer is that everything is promoted to unsigned
int and you must get a compiler warning about comparing signed with unsigned
values. Try to compile and see.






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3f0dd160$0$245$4d4eb98e@read.news.gr.uu.net>,
 on Thu, 10 Jul 2003 21:55:32 +0000 (UTC),
 ivr@nothis.emails.ru (Ioannis Vranos) wrote:

> ""MiniDisc_2k2"" <MattDelB@nospam.com> wrote in message
> news:%jjPa.31$zd4.2@lakeread02...
> > Okay, here's a question about the standard. What does it say about
> > unsigned/signed mismatches in a comparison statement:
> >
> > char a = 3;
> > unsigned char b = 255;
> > if (a<b)
> >
> > Now what's the real answer here? If a is converted to unsigned, then b>a.
> > But, if b is converted to signed,then a>b. What's the correct coversion
> > (what is the compiler supposed to do?)
>
>
> At first keep in mind that char (differently from other "plain" integer
> types) can be either signed or unsigned. If you want one of the two in
> specific, you have to declare it explicitly (e.g. signed char a=3).

Remember that char, signed char and unsigned char are three disticnt
types. FWIW, if I'm using the value in an arithmetic context, then I
always write either signed char or unsigned char. If I'm using it to
represent text elements, then I write char. And I probably wouldn't
write:

  char a = 3;

I'd write

  char a = '\003';

or, more likely - given my current project:

  char a = ASCII::ETX;

> Assuming you wish your above code to be:
>
> signed char a = 3;
> unsigned char b = 255;
> if (a<b)

I suspect if he'd wished that, he'd have written that.

> Both unsigned char and signed char get converted to int during the
> expression evaluation.

In fact, unsigned char may be promoted to unsigned int (depending on the
environment).

> So in summary, a either signed char either unsigned gets converted to
> int.

I had trouble parsing that - I assume you meant

 "So in summary, either a signed char or unsigned char gets converted to
 int."
?

If that is what you meant, then it isn't strictly true on all
platforms. Please see my other post for why :)

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 11 Jul 2003 01:39:53 +0000 (UTC), andys@despammed.com (Andy
Sawyer) wrote:

>In article <3nmPa.50$zd4.42@lakeread02>,
> on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),
> MattDelB@nospam.com ("MiniDisc_2k2") wrote:
>
>> Well actually I was using chars only to save my mind from calculating it all
>> out. Let's try again.
>>
>> I also intended this code to be used on a two's complement machine.
>>
>> Use this:
>>
>> signed int a = 3;
>> unsigned int b = -1;    /* thus being the highest number represented by
>> unsigned int*/
>
>No, it's a signed integer converted to an unsigned integer. And it's a
>value that the unsigned target cannot represent, so the value of b is
>actually implementation-defined.

No, when converting to an unsigned integer type, the value will be
brought into the range of values representable by that type during the
assignment. Nothing implementation-defined about it, it is quite
clearly defined in 4.7p2.

>What the compiler *can* pick is the result of the conversion from signed
>to unigned types if the value of the signed type cannot be represented
>in the unsigned type (see 4.7p3)

That paragraph regulates the conversion to a _signed_ type.

>
>Regards,
> Andy S

Bart v Ingen Schenau

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:llv6szff.fsf@evo6.com...
> In article <3nmPa.50$zd4.42@lakeread02>,
>  on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),
>  MattDelB@nospam.com ("MiniDisc_2k2") wrote:
>
> > signed int a = 3;
> > unsigned int b = -1;    /* thus being the highest number represented by
> > unsigned int*/
>
> No, it's a signed integer converted to an unsigned integer. And it's a
> value that the unsigned target cannot represent, so the value of b is
> actually implementation-defined.
...
> What the compiler *can* pick is the result of the conversion from signed
> to unigned types if the value of the signed type cannot be represented
> in the unsigned type (see 4.7p3)

Wrong paragraph.  4.7p3 deals with conversion to signed types
("if the destination type is signed..."), and the result is
implementation-defined, as you say.  The description of
conversion to an unsigned type is in 4.7p2, and the result is
defined by the Standard, not by the implementation:

    If the designation type is unsigned, the resulting value is
    the least unsigned integer congruent to the source integer
    (modulo 2**n where n is the number of bits used to represent
    the unsigned type).  [Note: In a two's complement
    representation, this conversion is conceptual and there is
    no change in the bit pattern (if there is no truncation). ]

-- William M. Miller


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""MiniDisc_2k2"" <MattDelB@nospam.com> wrote in message news:%jjPa.31$zd4.2@lakeread02...
> Okay, here's a question about the standard. What does it say about
> unsigned/signed mismatches in a comparison statement:
>
> char a = 3;
> unsigned char b = 255;
> if (a<b)
>
> Now what's the real answer here? If a is converted to unsigned, then b>a.
> But, if b is converted to signed,then a>b. What's the correct coversion
> (what is the compiler supposed to do?)
>

The usual aritmentic conersions are performd (5.1/9) which means the
integral promotions (4.5) are performed which means both a and b are
converted to int values of 3 and 255 respectively.   The value of a<b
therefore is true.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <llv6szff.fsf@evo6.com>, Andy Sawyer wrote:
> In article <3nmPa.50$zd4.42@lakeread02>,
>  on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),
>  MattDelB@nospam.com ("MiniDisc_2k2") wrote:
>
>> Well actually I was using chars only to save my mind from calculating it
>> all out. Let's try again.
>>
>> I also intended this code to be used on a two's complement machine.
>>
>> Use this:
>>
>> signed int a = 3;
>> unsigned int b = -1;    /* thus being the highest number represented by
>> unsigned int*/
>
> No, it's a signed integer converted to an unsigned integer. And it's a
> value that the unsigned target cannot represent, so the value of b is
> actually implementation-defined.
<snip>

No, this is well-defined (standard 4.7p2).  It's the reverse that is
implementation-defined.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:ptkiszvi.fsf@evo6.com...
>
> Remember that char, signed char and unsigned char are three disticnt
> types.



char is implemented either as signed char or as unsigned char.



FWIW, if I'm using the value in an arithmetic context, then I
> always write either signed char or unsigned char. If I'm using it to
> represent text elements, then I write char. And I probably wouldn't
> write:
>
>   char a = 3;
>
> I'd write
>
>   char a = '\003';


It's a personal issue. I am thinking in integral form, so i would write 3 if
i had not a specific character in mind.



> In fact, unsigned char may be promoted to unsigned int (depending on the
> environment).



If the involved values fit in int, they get promoted to int. It's in the
standard.



>
> > So in summary, a either signed char either unsigned gets converted to
> > int.
>
> I had trouble parsing that - I assume you meant
>
>  "So in summary, either a signed char or unsigned char gets converted to
>  int."
> ?


"So in summary the variable a, either it is signed char or unsigned char
gets converted to int (in real world scenarios where sizeof(int)>1)".






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.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.jamesd.demon.co.uk/csc/faq.html                       ]

Okay, here's a question about the standard. What does it say about
unsigned/signed mismatches in a comparison statement:

char a = 3;
unsigned char b = 255;
if (a<b)

Now what's the real answer here? If a is converted to unsigned, then b>a.
But, if b is converted to signed,then a>b. What's the correct coversion
(what is the compiler supposed to do?)

--
MiniDisc_2k2
To reply, replace nospam.com with cox dot 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.jamesd.demon.co.uk/csc/faq.html                       ]

""MiniDisc_2k2"" <MattDelB@nospam.com> wrote in message
news:%jjPa.31$zd4.2@lakeread02...
> Okay, here's a question about the standard. What does it say about
> unsigned/signed mismatches in a comparison statement:
>
> char a = 3;
> unsigned char b = 255;
> if (a<b)
>
> Now what's the real answer here? If a is converted to unsigned, then b>a.
> But, if b is converted to signed,then a>b. What's the correct coversion
> (what is the compiler supposed to do?)


At first keep in mind that char (differently from other "plain" integer
types) can be either signed or unsigned. If you want one of the two in
specific, you have to declare it explicitly (e.g. signed char a=3).


Assuming you wish your above code to be:


signed char a = 3;
unsigned char b = 255;
if (a<b)


Both unsigned char and signed char get converted to int during the
expression evaluation.


So in summary, a either signed char either unsigned gets converted to int.





--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <%jjPa.31$zd4.2@lakeread02>, MiniDisc_2k2
<MattDelB@nospam.com> writes
>Okay, here's a question about the standard. What does it say about
>unsigned/signed mismatches in a comparison statement:
>
>char a = 3;
>unsigned char b = 255;
>if (a<b)
>
>Now what's the real answer here? If a is converted to unsigned, then b>a.
>But, if b is converted to signed,then a>b. What's the correct coversion
>(what is the compiler supposed to do?)

No, the normal integral promotions are applied first Which only becomes
mildly interesting on systems where all integral types are the same
size.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]