From: Alain F. <Ala...@in...> - 2005-03-05 23:36:20
|
Bardur Arantsson wrote: >> Also, I'm concerned with your Obj.magic to create dummy elements to >> fill the array. Are you sure it will work with vlists of floats ? > > > A test with three elements suggests, yes. :) Aren't floats heap-allocated? Floats in float arrays are inlined. It might be possible to work with arrays of heap-allocated floats with the kind of magic you use, but I would not recommend to do that. > I think it will work in general because a 'NULL' pointer made through > Obj.magic will be at least as large as any non-heap object (and heap > objects are of course pointed to, so that'll work too). The NULL pointer is really the 0 integer (represented by 1 in memory). >> Why don't you use the element you add (in ::) and an equivalent of >> Array.map (in map) ? (Array.map as it is would produce a different >> traversal order >> for the vlists) > > > I'm not sure I follow... Once you have a pointer into the list (ie. the > parameter you're calling VList.map with) everything back from that point > is read-only, so you don't to construct anything using (::)...?!? I mean, instead of putting a dummy value (__NULL__ ()) when you allocate in new block in (::), you could use the first argument of (::) as the initializer for the array. And it has the correct type, by definition. So if you create vlists of floats, the arrays will end up being real arrays of floats (with inlined floats), not arrays of boxed floats. > I'm also pretty sure the current VList.map does produce a result with > the correct ordering. I don't claim the opposite. I just wanted to say that you could use the same implementation technique as for Array.map to get rid of the __NULL__ in VList.map, but Array.map by itself would give a wrong traversal order. Really, there is no need to use unsafe features here. Be on the safe side ! (and it will be more efficient for float vlists) Cheers, Alain |