470,849 Members | 1,259 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

type casting

Hello, All!

Given the sample piece of code I have:

#include <stdio.h>
#include <string.h>

int main(void)
{
short int i, j;
int k;
i = j = 10;
k = i + j;

return 0;
}

So, here I expect that 'i' and 'j' will be type-casted to 'int' type, while
in debugger (exploring memory dump) I see these variables still occupy 2
bytes (i.e. 'short' type).

Is it normal behavior? I suppose, I just don't catch some point.

With best regards, Roman Mashak. E-mail: mr*@tusur.ru
Nov 15 '05 #1
9 3439
"Roman Mashak" <mr*@tusur.ru> wrote:
#include <stdio.h>
#include <string.h>
Two superfluous headers; you use nothing from either.
int main(void)
{
short int i, j;
int k;
i = j = 10;
k = i + j;

return 0;
}

So, here I expect that 'i' and 'j' will be type-casted to 'int' type,
Why on earth would you expect that? There is not a single cast in your
program.
Even supposing you mean converted rather than cast, yes, their values
will, but only temporarily during the assignments. This has no influence
on their actual sizes as objects.
while in debugger (exploring memory dump) I see these variables still
occupy 2 bytes (i.e. 'short' type).


Of course. You have explicitly asked for them to do so.

That _the values of_ these shorts will then be converted to int before
being added to one another and/or assigned to other objects (in the
first case, being converted back to short before the assignment),
doesn't change the size of the objects themselves.

Richard
Nov 15 '05 #2
Roman Mashak <mr*@tusur.ru> wrote:
Hello, All!

Given the sample piece of code I have:

#include <stdio.h>
#include <string.h>

int main(void)
{
short int i, j;
int k;
i = j = 10;
k = i + j;

return 0;
}

So, here I expect that 'i' and 'j' will be type-casted to 'int' type, while
in debugger (exploring memory dump) I see these variables still occupy 2
bytes (i.e. 'short' type).


Note that the term "type-cast" is used for explicit conversion of types
by usage of the so called cast operators. What you'ld expect was
probably a conversion.

It's not the variables themselve that would get converted, but the
operands of the operation. Here even the operands do not have to be
converted because i and j are of the same integer type and the
+ operator doesn't require any special conversion.

So if you do something along

i = 18888;
j = 22222;
k = i+j;

You may get undefined behavior (supposing that SHRT_MAX is 32767).
Even though k is capable of holding the result, the operation will not
be done in the type of k, but with the type of i and j.

Also note that explicit type casts do not change the size of a variable.
A type cast is an operator jsut like + or *, and has a result. The type
of the result is that specified by the cast operator.

--
Z (zo**********@web.de)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Nov 15 '05 #3
Hello, Richard!
You wrote on Tue, 23 Aug 2005 06:47:33 GMT:

RB> Why on earth would you expect that? There is not a single cast in your
RB> program.
RB> Even supposing you mean converted rather than cast, yes, their values
RB> will, but only temporarily during the assignments. This has no
RB> influence on their actual sizes as objects.
Oops, I missed the terms. Converting != casting.
??>> while in debugger (exploring memory dump) I see these variables still
??>> occupy 2 bytes (i.e. 'short' type).

RB> Of course. You have explicitly asked for them to do so.

RB> That _the values of_ these shorts will then be converted to int before
RB> being added to one another and/or assigned to other objects (in the
RB> first case, being converted back to short before the assignment),
RB> doesn't change the size of the objects themselves.
Ok, I understood. In case of implicit type-casting - will it keep the object
size in memory ?

With best regards, Roman Mashak. E-mail: mr*@tusur.ru
Nov 15 '05 #4
Roman Mashak wrote:
Hello, Richard!
You wrote on Tue, 23 Aug 2005 06:47:33 GMT:

RB> Why on earth would you expect that? There is not a single cast in your
RB> program.
RB> Even supposing you mean converted rather than cast, yes, their values
RB> will, but only temporarily during the assignments. This has no
RB> influence on their actual sizes as objects.
Oops, I missed the terms. Converting != casting.
??>> while in debugger (exploring memory dump) I see these variables still
??>> occupy 2 bytes (i.e. 'short' type).

RB> Of course. You have explicitly asked for them to do so.

RB> That _the values of_ these shorts will then be converted to int before
RB> being added to one another and/or assigned to other objects (in the
RB> first case, being converted back to short before the assignment),
RB> doesn't change the size of the objects themselves.
Ok, I understood. In case of implicit type-casting - will it keep the object
size in memory ?
There is no implicit typecasting. You either cast or you don't.
Conversions can happen implicitly (without you doing anything about it)
or explicitly (with you casting).
Reread Richard's answer.

-Michael
With best regards, Roman Mashak. E-mail: mr*@tusur.ru

--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 15 '05 #5
Zoran Cutura wrote:
It's not the variables themselve that would get converted, but the
operands of the operation. Here even the operands do not have to be
converted because i and j are of the same integer type and the
+ operator doesn't require any special conversion.


It does require the Usual Arithmetic Conversions, which include integer
promotion. So i and j _do_ get promoted to int before the addition takes
place.
Christian
Nov 15 '05 #6
Christian Kandeler <ch****************@hob.de_invalid> wrote:
Zoran Cutura wrote:
It's not the variables themselve that would get converted, but the
operands of the operation. Here even the operands do not have to be
converted because i and j are of the same integer type and the
+ operator doesn't require any special conversion.


It does require the Usual Arithmetic Conversions, which include integer
promotion. So i and j _do_ get promoted to int before the addition takes
place.

uuhuu ... I stand corrected. My brain seems to shrink an leave holes all
over.

Sorry for the incorrect explanation.

--
Z (zo**********@web.de)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Nov 15 '05 #7
Michael Mair wrote:

Roman Mashak wrote:

Ok, I understood. In case of implicit type-casting
- will it keep the object size in memory ?


There is no implicit typecasting. You either cast or you don't.


Typecasting is something that happens to thespians.

http://www.m-w.com/cgi-bin/dictionary?va=typecasting

In C, a cast, is just called a "cast"

--
pete
Nov 15 '05 #8
Zoran Cutura wrote:
Note that the term "type-cast"
is used for explicit conversion of types
No, it isn't.
A type cast is an operator jsut like + or *,
and has a result.


It's just a "cast", not a "type cast".

There is no other kind of cast in C, such that the word "cast"
needs an adjective in front of it to distinguish it.

--
pete
Nov 15 '05 #9
pete wrote:
Michael Mair wrote:
Roman Mashak wrote:


Ok, I understood. In case of implicit type-casting
- will it keep the object size in memory ?


There is no implicit typecasting. You either cast or you don't.

Typecasting is something that happens to thespians.

http://www.m-w.com/cgi-bin/dictionary?va=typecasting

In C, a cast, is just called a "cast"


Argh. I was not aware of this -- seemingly there are enough like
me out there:
http://en.wikipedia.org/wiki/Typecast
I don't know where I picked it up but I guess it was around here;
so I use "to cast" for the action and "typecasting" as noun.
However, thank you :-)

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 15 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Suzanne Vogel | last post: by
4 posts views Thread by Jacob Jensen | last post: by
3 posts views Thread by Steve Teeples | last post: by
23 posts views Thread by René Nordby | last post: by
10 posts views Thread by lovecreatesbeauty | last post: by
6 posts views Thread by crook | last post: by
15 posts views Thread by shuisheng | last post: by
11 posts views Thread by Frederic Rentsch | last post: by
8 posts views Thread by Smithers | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.