English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
Bigarrays and temporar C pointers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-01-16 (12:32)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: [Caml-list] Bigarrays and temporar C pointers

Le 16 janv. 05, ŕ 03:28, John Prevost a écrit :

> Well, assuming you really need to work in this strange way,
Yes, some part of opengl work like this, vertex buffer objects [1]. In  
fact there a lot more things that are not allowed to do while a buffer  
is mapped and it is not possible to enforce every constraints (however  
most, if not all, of these errors just lead to gl errors, not to core  

Anyway, thanks for you time and code. Especially for the handling of  
exceptions occuring in the callback which I completely forgot.

In fact I didn't consider, as you suggest, to make the type

> type ('a, 'b) data = ('a, 'b, c_layout) Array1.t

abstract and replicate Array1.t's "allowed" functionnality in the  
module --- I hope that it won't prevent the optimisations present in  
the compiler for bigarrays.

> set = Array1.set
> get = Array1.get
> ...

The only problem I see is that the user loses the ability to use  
existing bigarray code and the lighter syntax to access/write the  
array. On the other hand I can prevent the user from extracting  
subarrays and I'm on the safe side again.

There's a tradeoff and I cannot make up my mind right now.