By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,389 Members | 1,844 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,389 IT Pros & Developers. It's quick & easy.

Usual arithmetic conversions + integral promotion for short?

P: n/a
Is it possible for a standard compliant C++ compiler to have
( sizeof(short) < sizeof(int) )
and
( sizeof(short) == sizeof((short)0 + (short)0) )
?

Regards,

Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Jul 22 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a

"Niels Dekker (no reply address)" <un*****@this.is.invalid> wrote in message
news:40***************@this.is.invalid...
Is it possible for a standard compliant C++ compiler to have
( sizeof(short) < sizeof(int) )
and
( sizeof(short) == sizeof((short)0 + (short)0) )
The second part of that question is *always* true! You're casting two int's
as shorts, and adding them together to create temporary value, which must
therefore also be a short. So, naturally it has the same size as a short,
because it *is* a short.

And since the first part is also true (or is allowed to be true, at least),
then...

Yes, it is possible. Even probable, I would venture to guess.

-Howard

?

Regards,

Niels Dekker
http://www.xs4all.nl/~nd/dekkerware

Jul 22 '05 #2

P: n/a
Niels Dekker (no reply address) wrote:
Is it possible for a standard compliant C++ compiler to have
( sizeof(short) < sizeof(int) )
and
( sizeof(short) == sizeof((short)0 + (short)0) )
?


The latter is mandatory, AFAICT. The former is definitely possible.

Victor
Jul 22 '05 #3

P: n/a
Howard wrote in
news:gP*******************@bgtnsc04-news.ops.worldnet.att.net in
comp.lang.c++:

"Niels Dekker (no reply address)" <un*****@this.is.invalid> wrote in
message news:40***************@this.is.invalid...
Is it possible for a standard compliant C++ compiler to have
( sizeof(short) < sizeof(int) )
and
( sizeof(short) == sizeof((short)0 + (short)0) )

For the OP:

The type of short + short is int (standard intergral promotion's),
So the answer is No.

The second part of that question is *always* true! You're casting two
int's as shorts, and adding them together to create temporary value,
which must therefore also be a short. So, naturally it has the same
size as a short, because it *is* a short.

#include <iostream>

void f( short )
{
std::cout << "short\n";
}

void f( int )
{
std::cout << "int\n";
}

int main()
{
short a = 1, b = 2;
f( a + b );
}

If you get "short" on your compiler ask for a refund.

[snip]

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #4

P: n/a
D'OH! :-)

Rob's right, of course. Adding two shorts results in an int, not a short.

It was probably designed that way originally to allow for possible overflow
without losing data (although technically it really only needs one extra
bit, but that's hard to accomplish in a C++ program...and I digress).

Testing this fact with the code Rob gave (and several variations of it),
demonstrated (at least in my compilers) that I was incorrect in my
assumption. (I don't have the standard here to look up the relevant
specification.)

So whenever a short is smaller than an int, then the second comparison
should be false. (That is, a short should *also* be smaller than the sum of
two shorts.) Which is, I'm guessng, what you thought in the first place,
right?

Sorry for the misinformation. (And, what compiler gives you those erroneous
results?)

-Howard

Jul 22 '05 #5

P: n/a
Niels Dekker (no reply address) wrote:
Is it possible for a standard compliant C++ compiler to have
( sizeof(short) < sizeof(int) )
and
( sizeof(short) == sizeof((short)0 + (short)0) )
?


No.

--
Best regards,
Andrey Tarasevich

Jul 22 '05 #6

P: n/a
Rob Williscroft wrote:

The type of short + short is int (standard intergral promotion's)


Are you sure that's mandatory?

The standard says about integral promotions:
"An rvalue of type [...] 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."
http://anubis.dkuug.dk/jtc1/sc22/ope...html#conv.prom

The words "can be" made me wonder: isn't it okay for a pair of short
operands to just remain short during the operation?

Thanks for all your replies so far,

Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Jul 22 '05 #7

P: n/a
* "Niels Dekker (no reply address)" <un*****@this.is.invalid> schriebt:
Rob Williscroft wrote:

The type of short + short is int (standard intergral promotion's)


Are you sure that's mandatory?

The standard says about integral promotions:
"An rvalue of type [...] 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."
http://anubis.dkuug.dk/jtc1/sc22/ope...html#conv.prom

The words "can be" made me wonder: isn't it okay for a pair of short
operands to just remain short during the operation?


Nope. What you're missing is 5/9 which defines the "usual arithmetic
conversions", and which for this case states that the integral promotions
_shall_ be applied. I read that as whatever is allowed as integral
promotion shall be applied, for otherwise the "shall" would be void of
meaning (personally I think the wording of 4.5 is YADITS).

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #8

P: n/a
Victor Bazarov wrote:
Niels Dekker (no reply address) wrote:
Is it possible for a standard compliant C++ compiler to have
( sizeof(short) < sizeof(int) )
and ( sizeof(short) == sizeof((short)0 + (short)0) )
?

The latter is mandatory, AFAICT.


Wrong on my part. Integral promotions are performed. The result should
be of type 'int', therefore you cannot simultaneously have sizeof(short)
different and equal sizeof(int).
The former is definitely possible.


Victor
Jul 22 '05 #9

P: n/a
Howard wrote:

Rob's right, of course. Adding two shorts results in an int, not a short. [...] So whenever a short is smaller than an int, then the second comparison
should be false. (That is, a short should *also* be smaller than the sum of
two shorts.) Which is, I'm guessng, what you thought in the first place,
right?

Sorry for the misinformation. (And, what compiler gives you those
erroneous results?)


No problem. To me it just means that my question wasn't that silly! :-)
I haven't found a C++ compiler yet that says "short + short = short"
But maybe a C compiler will do... Because the C Standard says: "If
both operands have the same type, then no further conversion is needed."
http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.pdf

Apparently C and C++ have different "usual arithmetic conversions", and in C
(sizeof(short) == sizeof((short)0+(short)0)) might as well be true, even
if sizeof(short) < sizeof(int).

Best regards,

Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Jul 22 '05 #10

P: n/a
Oops, I misinterpreted the C Standard:

I haven't found a C++ compiler yet that says "short + short = short"
But maybe a C compiler will do... Because the C Standard says: "If
both operands have the same type, then no further conversion is needed."
http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.pdf

Apparently C and C++ have different "usual arithmetic conversions", and in C
(sizeof(short) == sizeof((short)0+(short)0)) might as well be true, even
if sizeof(short) < sizeof(int).


No, no, I was wrong! The C Standard says:
"Otherwise, the integer promotions are performed on both operands. Then
the following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion is
needed."

So only _after_ these integer promotions, there might be no further
conversion. But because of these promotions, both short operands are
promoted to int already.

Best regards,

Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Jul 22 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.