1 minute read

I got this in the mail today:

The paomnnehil pweor of the hmuan mnid.
Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in
waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht
the frist and lsat ltteer be at the rghit pclae.

The rset can be a total mses and you can sitll raed it wouthit porbelm.
Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but
the wrod as a wlohe.

Amzanig huh?

I wondered whether this logic would work with Chris Brumme's hardcore stuff on the CLR. Here you decide:

For nramol PoIvknes, a bitlablte tpye eepoxss the bteys of an ojbcet in the GC haep dcreitly to uemaanngd cdoe.  Tihs osvolibuy mnaes taht the betys msutn’t be meovd by a GC raotlecion utinl the ugmannaed cdoe has sepptod acsciensg tehm.  In msot cseas, the PonIvke leayr can aatoluamtcily pin the betys for the limetfie of the clal.

Did it make any sense? Here's the original stuff:

For normal PInvokes, a blittable type exposes the bytes of an object in the GC heap directly to unmanaged code.  This obviously means that the bytes mustn’t be moved by a GC relocation until the unmanaged code has stopped accessing them.  In most cases, the PInvoke layer can automatically pin the bytes for the lifetime of the call.

Categories:

Updated: