# Cpointer -\> flvector? **URL:** \ **Category:** Questions & Answers\ **Tags:** ffi\ **Created:** [November 22, 2024, 10:32am UTC](https://racket.discourse.group/t/cpointer-flvector/3348 "2024-11-22T10:32:13Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Laurent.O](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/laurent.o/32/18_2.png) [@Laurent.O](https://racket.discourse.group/u/Laurent.O)\ **Post date:** [November 22, 2024, 10:32am UTC](https://racket.discourse.group/t/cpointer-flvector/3348/1 "2024-11-22T10:32:13Z")
Once I have a pointer to a memory block from the ffi (allocated in a shared memory space), is there a way to turn it into a standard racket `flvector`? I see there's a `flvector->cpointer`, but not the converse. ---
**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\ **Post date:** [November 22, 2024, 11:39am UTC](https://racket.discourse.group/t/cpointer-flvector/3348/2 "2024-11-22T11:39:19Z")
Probably not, for the reasons discussed here: > > > Is there a way to mmap some memory (a file for example, I can do this simply via… the ffi) and use that memory without copying in a bytevector? Some sort of function that sets a bytevectors storage, and locks it, so the gc doesn't touch it? > > > Let say I have some block of memory suitably aligned (8 bytes on my x86\_64 machi…ne), of say 16 bytes, with the first 8 bytes being \`(8 \<\< 3) | 1\` (in a \`uint64\_t\` in native endianness), then create a properly tagged pointer to it with \`($address-\>object (- ptr 1) 0)\`, \`ptr\` being the pointer to said block of memory, then I just have successfully created a bytevector of size 8; all bytevector procedures work on this Scheme object that was \_materialized\_ outside the Scheme heap. > > My question is, (let's suppose the block of memory is \_never\_ freed and reused for the sake of simplicity), is this bytevector can confuse and/or harm the garbage collector? If not, is materializing string objects in a similar fashion the same result? And what about other non-immediate values (pairs, vectors, records etc.)? ---
**Author:** ![Laurent.O](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/laurent.o/32/18_2.png) [@Laurent.O](https://racket.discourse.group/u/Laurent.O)\ **Post date:** [November 22, 2024, 12:55pm UTC](https://racket.discourse.group/t/cpointer-flvector/3348/3 "2024-11-22T12:55:56Z")
Ouch, that's not very promising indeed 😕 Thanks! ---
**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\ **Post date:** [November 22, 2024, 3:31pm UTC](https://racket.discourse.group/t/cpointer-flvector/3348/4 "2024-11-22T15:31:53Z")
You might be able to use [`_f64vector`](https://docs.racket-lang.org/foreign/homogeneous-vectors.html#%28def._%28%28lib._ffi%2Fvector..rkt%29._make-f64vector%29%29) from `ffi/vector`, though! ---
**Author:** ![Laurent.O](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/laurent.o/32/18_2.png) [@Laurent.O](https://racket.discourse.group/u/Laurent.O)\ **Post date:** [November 22, 2024, 3:38pm UTC](https://racket.discourse.group/t/cpointer-flvector/3348/5 "2024-11-22T15:38:28Z")
True, but that won't help me much. The idea was to re-use all my functions defined for `flvector`s without having to duplicate the work and change all the `flvector-ref`, etc. while still making it work also for `flvector`s. Also, `_f64vector` uses `_double*`, which is slower than `_double` AFAIR. ---
**Author:** ![Laurent.O](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/laurent.o/32/18_2.png) [@Laurent.O](https://racket.discourse.group/u/Laurent.O)\ **Post date:** [November 23, 2024, 7:59am UTC](https://racket.discourse.group/t/cpointer-flvector/3348/6 "2024-11-23T07:59:12Z")
A possible solution: Instead of trying to make `my-shared-flvector` behave like `flvector`, I can do exactly the converse since I can obtain the cpointer from `flvector`. I still need to modify my functions to work with `my-shared-flvector`, but at least it will work seamlessly for standard `flvector`s too. Can this defeat some compiler optimizations though?