Back to Questions
982
views5
comments
AddressOf and pinning?
f#

I'm a bit curious as to what && is for. It gives me the address of the object. But, inspecting the IL, I don't see that the address is pinned. As I understand, the CLR will pin automatically if the local has the pinned constraint on it (section 7.1.2 of Partition II).

But when I use &&, say, on an array element (&&arr.[0]), the local in which it is stored doesn't have pinned.

I know I can use GCHandle (or via PinnedArray). I'm just wondering what the point of && on non-stack values is if it doesn't pin. Is this a problem like I think it is, or am I missing something that makes it safe to use (within the scope of the function of course)?

.

Using unmanaged pointers to heap-allocated objects that aren't pinned obviously isn't safe. This shouldn't be a problem though, since there are enough compiler warnings and you should only play with native pointers if you know what you're doing.

By on 6/22/2010 4:49 AM ()

So I guess my question is, why doesn't the F# compiler mark those locals as pinned, and save me the hassle of having to use GCHandle? And what's the use case for &&, outside of stack allocated values?

By on 6/22/2010 1:10 PM ()

This is speculation on my part, but perhaps the reason that locals aren't automatically pinned is that pinning impacts GC performance, so rather than pinning the local for the entire scope of the method, the language leaves it up to you to pin your objects for the duration that you require.

I'm not sure I understand your second question... && is just as useful for heap allocated values as for stack allocated values - it allows you to create a native pointer to fields of classes, array elements, etc.

By on 6/22/2010 2:43 PM ()

OK, thanks. I didn't mean to say && was useless for heap values, just that you have to make sure they're pinned already. Good point on the scoping and potential performance issue.

By on 6/25/2010 8:30 AM ()

To pin locals F# would need a language construct like the "fixed"-statement in C#. Designing such a feature and properly supporting it in the compiler takes some effort, so maybe the F# team just had other priorities. The && operator may be useful for heap-allocated arrays when you know the array is pinned and you want to access it in both managed and unmanaged (or unverifiable) code and you don't want to pass around an unmanaged pointer in addition to the managed one.

By on 6/22/2010 2:40 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper