CLR Type System notes

Joel Pobar s CLR weblog CLR Type System notes | alternative dating

Joel Pobar s CLR weblog CLR Type System notes | alternative dating — Wed, 17 Jun 2009 10:46:44 GMT

PingBack from http://topalternativedating.info/story.php?id=4281

Famous Quotes » Joel Pobar’s CLR weblog : CLR Type System notes

Famous Quotes » Joel Pobar’s CLR weblog : CLR Type System notes — Sat, 05 Jan 2008 07:22:48 GMT

PingBack from http://famousquotes.247blogging.info/?p=450

Boxing » Blog Archive » Joel Pobar’s CLR weblog : CLR Type System notes

Boxing » Blog Archive » Joel Pobar’s CLR weblog : CLR Type System notes — Sat, 05 Jan 2008 05:12:01 GMT

PingBack from http://boxing.247blogging.info/?p=56

CLR Dynamic languages under the hood (Part 1 of many)

Joel Pobar's CLR weblog — Fri, 01 Jul 2005 21:48:09 GMT

There seems to be a fair amount of recent press and blog action surrounding the dynamic or “scripting”...

CLR Dynamic languages under the hood (Part 1 of many)

Joel Pobar's CLR weblog — Fri, 01 Jul 2005 21:44:05 GMT

There seems to be a fair amount of recent press and blog action surrounding the dynamic or “scripting”...

re: CLR Type System notes

Adrian Florea — Sat, 07 Aug 2004 11:35:00 GMT

Another "property": The null type is in a subtype relationship (standard implicit conversion) with any reference type

re: CLR Type System notes

Adrian Florea — Sat, 31 Jul 2004 15:43:00 GMT

Thanks Dominic for the comments.

ldnull just push null object reference (nullref) on the stack. But nullref I think has an encoding! There is a record of the Constant metadata table for nullref with this info:
Type: ELEMENT_TYPE_CLASS (0x12 unsigned 1-byte integer)
Parent: a reference to the owner of the constant
Value: a bit pattern of all bits zero (4-byte)
But this is not followed by a type token (means type-agnostic null?)

Joel, correct us if we're wrong? :-)

re: CLR Type System notes

Dominic Cooney — Thu, 29 Jul 2004 16:29:00 GMT

Re: Adrian Florea's comments [1] on the 'null' type,

As I understand it, the 'null' type doesn't exist outside verification. So, for example, if you're doing verification and a control flow path that does ldnull merges with one that does ldstr, the verification algorithm merges the null type and string and comes up with string. This is why you can't just ascribe object as the type of slot ldnull produces (because in the example above object + string => object, which is unnecessarily general.)

So AFAIK the null type doesn't need an encoding like other types. If you look at the verifier in Rotor you should see where the null type comes in to play.

Joel, correct me if I'm wrong?

[1] http://blogs.msdn.com/joelpob/archive/2004/07/19/187709.aspx#187830

re: CLR Type System notes

Dmitriy Zaslavskiy — Tue, 20 Jul 2004 14:18:00 GMT

Wesner Moise (IMO)
Boxing Joel is talking about is box instruction which will create an object on heap. That object's MT will point to generic pointer type and 32/64 bits that follow will not have an identity. CLR will no longer be able to track the type of the pointer.

As you can see Pointer.Box requires you to pass the type.

re: CLR Type System notes

Wesner Moise — Mon, 19 Jul 2004 21:29:00 GMT

I thought that Reflection does support Pointers; hence, the availability of System.Reflection.Pointer.

You can box a pointer by calling Pointer.Box(ptr, type) and unbox with
Pointer.Unbox(object).