Ok, it's clear now. Thanks for the great support! -- Marcel
On Jun 15, 9:21 pm, Dino Viehland <[email protected]> wrote: > Marcel wrote: > > Thanks Dino, the ctypes.memmove does work! > > > I wasn't aware that ctypes could be used in IronPython. Do they > > marshal to unmanaged code under the hood? > > There's not really any unmanaged code on *our* side involved at all. It > all turns into .NET's support for interop. So we'll generate calli calls > w/ the correct signature. And then all the memory access we do is through > the Marshal APIs. I actually didn't even need to flip the /unsafe compiler > flag in order to implement it all :) > > > > > Let me know if you want me to file a bug against the Marshal.Copy > > overload behavior. > > I actually don't think this is a bug. The problem here is that you either > have a pointer (as an int but it could trivially be turned into an IntPtr) or > an IronPython array object and then an IntPtr. For the 2 IntPtr cases there's > no overloads on Marshal and I don't believe anywhere in .NET. For ctypes to > implement memmove we had to P/Invoke. And for the array case you don't have > a .NET array. > > If we exposed the underlying .NET array then you could use Marshal.Copy. But > I'm reluctant to do that because we might want to switch to allocating > unmanaged memory for the array in the future. That'll work better w/ ctypes > and calls to buffer_info() - currently need to pin the array for > an unknown amount of time. That's another reason to allocate the memory via > ctypes. > > _______________________________________________ > Users mailing list > [email protected]http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
