Darx Kies wrote: > Bruce Markham wrote: > >> [...] >> > They are pretty much the same. IntPtr is actually just a struct with a > void* field. > void* might be faster when AOTing but with IntPtr/UIntPtr you have all > the methods and properties you might need. > Both can be boxed and so on. > > Chriss. > I suppose the point of an IntPtr is that it should be resilient in the face of GC actions? Correct? Or do you need to pin them as well?
You could always add an [AOTInline] attribute to its methods/properties couldn't you (to remove a bit of the overhead). Remember, working with an IntPtr is regarded as safe because you can not change its location: that is, the following code won't even compile: IntPtr foo = (IntPtr)100; // Compiler will laugh at you. foo ++; // Once again, go fish. So we could be limiting ourselves... Chriss, any ideas? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
