From: markspace on
Donkey Hottie wrote:

>
> Is a cast somehow a runtime operation?

As other have pointed out, yes it is. However, in this particular case,
I checked the byte codes and it did appear that the compiler didn't
insert any runtime checks. In fact the "call" variable appeared to be
removed completely. There was just a push operation (to push the
parameter on the stack) and an invokeInterface opcode, to call the
sumbit() method.

> In C it used to be a compile time
> operation, and does not add any runtime penalty.


Your understanding jibes with mine. However, it seems it's machine
dependent. Ol' C itself is pretty machine dependent. I remember I used
to cast integers to pointers like so:

#define SPORT_1 (*(void*)0x10001234)

And there would be no runtime penalty, because the Motorola 68000's
representation of ints and pointers was exactly the same. For other
architectures (Intel with their segmented pointers) I can see how there
might be some runtime overhead to split up the integer value.

From: Arne Vajhøj on
On 16-12-2009 11:21, markspace wrote:
> Your understanding jibes with mine. However, it seems it's machine
> dependent. Ol' C itself is pretty machine dependent. I remember I used
> to cast integers to pointers like so:
>
> #define SPORT_1 (*(void*)0x10001234)
>
> And there would be no runtime penalty, because the Motorola 68000's
> representation of ints and pointers was exactly the same. For other
> architectures (Intel with their segmented pointers) I can see how there
> might be some runtime overhead to split up the integer value.

Not that it is significant for your point, but I assume the first
asterisk should not be there.

Arne
From: Mike Schilling on
Alessio Stalla wrote:

> In Java a cast is a runtime operation because it implies a runtime
> type check.

Surely

List list;
List<String> slist = (List<String>)list;

doesn't do a run-time type check. There's nothing checkable about it.


From: markspace on
Arne Vajh�j wrote:
> On 16-12-2009 11:21, markspace wrote:
>> Your understanding jibes with mine. However, it seems it's machine
>> dependent. Ol' C itself is pretty machine dependent. I remember I used
>> to cast integers to pointers like so:
>>
>> #define SPORT_1 (*(void*)0x10001234)
>>
>> And there would be no runtime penalty, because the Motorola 68000's
>> representation of ints and pointers was exactly the same. For other
>> architectures (Intel with their segmented pointers) I can see how there
>> might be some runtime overhead to split up the integer value.
>
> Not that it is significant for your point, but I assume the first
> asterisk should not be there.


I think it should, although I could be wrong. The idea is to read and
write SPORT_1 as if it were a variable, without having to apply further
modifiers.

int value = SPORT_1;
value &= 0xF;
SPORT_1 = value;

Although I admit I may have messed up the syntax in my previous post.

From: Lew on
Alessio Stalla wrote:
>> In Java a cast is a runtime operation because it implies a runtime
>> type check.

Mike Schilling wrote:
> Surely
>
> List list;
> List<String> slist = (List<String>)list;
>
> doesn't do a run-time type check. There's nothing checkable about it.

It doesn't do a cast, either. Well, it does, but it's the equivalent of

List slist = (List) list;

Come to think of it, that cast might involve a runtime type check.

--
Lew