Thanks for the responses. As usual, I discover myself making assumptions that may not have been stated well.
1. I'll be reading small bits (32 bit ints, mostly) at fairly random addresses and was worried about the overhead of creating array views for such small objects. Perhaps they are optimized away. I should check :-) 2. I've been taught by other languages that touching raw pointers is dangerous without also holding some promise that they won't be relocated, e.g. by a copying collector, etc. I suppose if it's a memory mapped array, I can roughly cheat and know that the OS won't move it, so Julia can't either. But it worried me. *Sebastian Good* On Sun, Nov 9, 2014 at 11:36 PM, Jameson Nash <[email protected]> wrote: > It rather depends upon what you know about the data. If you want a > file-like abstraction, it may be possible to wrap it in an IOBuffer type > (if not, it should be parameterized to allow it). If you want an array-like > abstraction, then I think reinterpreting to different array types may be > the most direct approach. If the array is coming from C, then you can use > unsafe_load/unsafe_store directly. As Ivar points out, this is not more nor > less dangerous than the same operation in C. Although, if you wrap the data > buffer in a Julia object (or got it from a Julia call), you can gain some > element of protection against memory corruption bugs by minimizing the > amount of julia code that is directly interfacing with the raw memory > pointer. > > > On Sun Nov 09 2014 at 5:42:42 PM Ivar Nesje <[email protected]> wrote: > >> Is there any problem with reinterpreting the array and then use a >> SubArray or ArrayView to do the index transformation? >> >> Pointer arithmetic is not more or less dangerous in Julia, than what it >> is in C. The only thing you need to ensure is that the object you have a >> pointer to is referenced by something the GC traverses, and that it isn't >> moved in memory (Eg. vector resize). >> >
