Data.StorableVector.Base
Description
A module containing semi-public StorableVector internals. This exposes the StorableVector representation and low level construction functions. Modules which extend the StorableVector system will need to use this module while ideally most users will be able to make do with the public interface modules.
- data Vector a = SV !(ForeignPtr a) !Int !Int
- unsafeHead :: Storable a => Vector a -> a
- unsafeTail :: Storable a => Vector a -> Vector a
- unsafeLast :: Storable a => Vector a -> a
- unsafeInit :: Storable a => Vector a -> Vector a
- unsafeIndex :: Storable a => Vector a -> Int -> a
- unsafeTake :: Storable a => Int -> Vector a -> Vector a
- unsafeDrop :: Storable a => Int -> Vector a -> Vector a
- create :: Storable a => Int -> (Ptr a -> IO ()) -> IO (Vector a)
- createAndTrim :: Storable a => Int -> (Ptr a -> IO Int) -> IO (Vector a)
- createAndTrim' :: Storable a => Int -> (Ptr a -> IO (Int, Int, b)) -> IO (Vector a, b)
- unsafeCreate :: Storable a => Int -> (Ptr a -> IO ()) -> Vector a
- fromForeignPtr :: ForeignPtr a -> Int -> Vector a
- toForeignPtr :: Vector a -> (ForeignPtr a, Int, Int)
- withStartPtr :: Storable a => Vector a -> (Ptr a -> Int -> IO b) -> IO b
- incPtr :: Storable a => Ptr a -> Ptr a
- inlinePerformIO :: IO a -> a
The Vector type and representation
A space-efficient representation of a vector, supporting many efficient operations.
Instances of Eq, Ord, Read, Show, Data, Typeable
Constructors
| SV !(ForeignPtr a) !Int !Int |
Unchecked access
unsafeHead :: Storable a => Vector a -> aSource
A variety of head for non-empty Vectors. unsafeHead omits the
check for the empty case, so there is an obligation on the programmer
to provide a proof that the Vector is non-empty.
unsafeTail :: Storable a => Vector a -> Vector aSource
A variety of tail for non-empty Vectors. unsafeTail omits the
check for the empty case. As with unsafeHead, the programmer must
provide a separate proof that the Vector is non-empty.
unsafeLast :: Storable a => Vector a -> aSource
A variety of last for non-empty Vectors. unsafeLast omits the
check for the empty case, so there is an obligation on the programmer
to provide a proof that the Vector is non-empty.
unsafeInit :: Storable a => Vector a -> Vector aSource
A variety of init for non-empty Vectors. unsafeInit omits the
check for the empty case. As with unsafeLast, the programmer must
provide a separate proof that the Vector is non-empty.
unsafeIndex :: Storable a => Vector a -> Int -> aSource
Unsafe Vector index (subscript) operator, starting from 0, returning a
single element. This omits the bounds check, which means there is an
accompanying obligation on the programmer to ensure the bounds are checked in
some other way.
Low level introduction and elimination
create :: Storable a => Int -> (Ptr a -> IO ()) -> IO (Vector a)Source
Wrapper of mallocForeignPtrArray.
createAndTrim :: Storable a => Int -> (Ptr a -> IO Int) -> IO (Vector a)Source
Given the maximum size needed and a function to make the contents
of a Vector, createAndTrim makes the Vector. The generating
function is required to return the actual final size (<= the maximum
size), and the resulting byte array is realloced to this size.
createAndTrim is the main mechanism for creating custom, efficient Vector functions, using Haskell or C functions to fill the space.
unsafeCreate :: Storable a => Int -> (Ptr a -> IO ()) -> Vector aSource
A way of creating Vectors outside the IO monad. The Int
argument gives the final size of the Vector. Unlike
createAndTrim the Vector is not reallocated if the final size
is less than the estimated size.
fromForeignPtr :: ForeignPtr a -> Int -> Vector aSource
O(1) Build a Vector from a ForeignPtr
toForeignPtr :: Vector a -> (ForeignPtr a, Int, Int)Source
O(1) Deconstruct a ForeignPtr from a Vector
withStartPtr :: Storable a => Vector a -> (Ptr a -> Int -> IO b) -> IO bSource
Run an action that is initialized with a pointer to the first element to be used.
inlinePerformIO :: IO a -> aSource
Just like unsafePerformIO, but we inline it. Big performance gains as
it exposes lots of things to further inlining. Very unsafe. In
particular, you should do no memory allocation inside an
inlinePerformIO block. On Hugs this is just unsafePerformIO.