[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ProgSoc] Programming! Code!
On Fri, 2006-10-20 at 04:08 +1000, John Elliot wrote:
> I noticed so many typographical errors and a few incorrect statements in
> my previous reply that I figure it would be worth revising it an
> resending.
OK. There will probably be some "messages passing in the night" here,
but we appear to be converging.
> The above paragraph is an oversimplification to the point of being
> incorrect.
"Or something like that" is adequate at this point.
> Earlier I said: "As an implementation detail the value of the pointer
> stored in o will be pointing at a." However, that is not correct. The
> first user defined field is sizeof(void*) beyond the where the object
> reference points (in CLR 1.1, I don't know if this changed for 2.0 but
> I doubt it).
>
> Earlier I said: "The object header is offset back from that by a few
> bytes (but that's just what I've heard, and is purely an implementation
> detail -- makes sense from a perf perspective though)." ...and that's
> kinda true, but I haven't used the right names, 'object header' isn't
> just 'one thing'.. it is comprised of a thing called the 'sync block'
> and another thing called the 'htype'. The value of the sync block
> occurs immediately before the htype, and the location of htype is that
> to which the values of object reference point.
Again "or something like that".
> class BoxedBoolean {
> public readonly Boolean Value;
> }
Oh! There are _another_ set of typenames. So BoxedBoolean in C# has an
analogous behaviour to Boolean in Java (and indeed, the same
relationship wrt autoboxing to bool/boolean). Thanks, this is the
problem that I was having.
This also explains what's going on in
Object a = false;
(Autoboxed to BoxedBoolean, then widened to Object.)
> > The other place that it's frequently useful in Java is to explicitly
> > represent intentional absence of a value, e.g. for a "don't know" or
> > "not specified" situation; a Boolean object reference can, by virtue
> > of being an object reference, be a null object reference (a explicit
> > reference to no object) and, therefore, explicitly represent the
> > absence of a value. "boolean" on the other hand is a primitive value
> > type (not a reference) and, therefore, cannot be "null" in either
> > sense.
>
> Your statements regarding what can and can not be done here are
> incorrect. (I'm happy to explain why as you get a better idea of what
> value types are, although tackling such issues as the above seems like
> it's going to require a lot of typing, and I'm light on free time at
> the moment).
OK, I'm now guessing that you missed the word "Java" in the first quoted
line above?
- Raz
-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.