> > Ultimately, this seems like the right thing to do, for all functions > > that return pointers to underlying bits of data (I am slightly scared > > that there may be loads of these lurking around).
> For most purposes the (Ptr () -> IO b) approach is probably neater,
> though. After all if you do need direct access to a Ptr, it's probably
> because you're calling another FFI funciton on it (in my case,
> texImage2d), which will itself "take a copy" of the memory, and then
> it's safe to destroy.
Here's my implementation of it. Does it look sane to you? Any comments
from wxhaskell developers?
withImageData :: Image a -> (Ptr () -> IO b) -> IO b
withImageData image f = do
pixels <- imageGetData image
x <- f pixels
x `seq` image `seq` return x
The seqs are there out of pure superstition (i.e. Eric doesn't know how
Haskell works); basically, I want to make sure we're holding on to image
as long as we need to, so at least until we know what 'x' is.
If this is indeed sane, we could stick it in wxcore and put a big
warning on the Haddocks for imageGetData (without removing it just
yet).
--
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
pgp46mDOOCYfg.pgp
Description: PGP signature
------------------------------------------------------------------------- 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/
_______________________________________________ wxhaskell-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
