Prev: Why can nsmc, local classes or anonymous classes have static members ?
Next: Web Services Restful Services
From: markspace on 16 Dec 2009 11:21 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 16 Dec 2009 19:56 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 16 Dec 2009 20:12 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 16 Dec 2009 20:32 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 16 Dec 2009 22:42 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Why can nsmc, local classes or anonymous classes have static members ? Next: Web Services Restful Services |