Just because their layout is the same doesn't mean you can use the wrong one when declaring a data-structure. They still have a very nearly 1-to-1 correspondence with C in that respect too. On Mon, Feb 9, 2015 at 2:37 PM Kevin Squire <[email protected]> wrote:
> I haven't had the chance to check recently (and am not sure when I will be > able to), but when wrapping libav/ffmpeg, I found that passing mutable > objects (of types) to C-code produced a segmentation fault, but that > passing immutables worked (with no other changes). I believe that was > after Jameson's changes, and had just assumed that the layout wasn't > compatible still. > > Anyway, when I get the chance, I'll try again, and create an issue if it > still has problems. > > Kevin > > > On Mon, Feb 9, 2015 at 10:53 AM, Tobias Knopp <[email protected] > > wrote: > >> No I think its still only pointers to the type objects that are stored in >> the array. But note that what Jameson wrote still holds. In ccall you can >> assume that the type has C struct layout. No need to go for an immutable >> there. >> >> Tobi >> >> Am Montag, 9. Februar 2015 19:00:15 UTC+1 schrieb Simon Danisch: >> >>> But arrays of* type* are still not densely packed, right? >>> I tried it with the newest master and it doesn't look like it. >>> >>> >>> Am Sonntag, 8. Februar 2015 21:35:20 UTC+1 schrieb [email protected]: >>>> >>>> I would like to request the following language feature: a function or >>>> macro to modify a field of an immutable inside a container. Consider: >>>> >>>> immutable T >>>> fielda::Int >>>> fieldb::Int >>>> fieldc::Int >>>> end >>>> >>>> function modify_fieldc!(x::Array{T,1}, sub::Int, newc::Int) >>>> x[sub] = T(x[sub].fielda, x[sub].fieldb, newc) >>>> end >>>> >>>> This function modifies one field of an immutable object that sits >>>> inside a container. The above construct, namely: >>>> x[sub] = T(x[sub].field1, x[sub].field2, ... , newval, ... >>>> x[sub].fieldn) >>>> occurs rather frequently in my code. It is not very readable and is >>>> also fragile in the case that I modify my code and put more fields in T >>>> later. It would be much nicer if there were a universal function like this: >>>> modifyField!(x, sub, fieldc, newc) >>>> >>>> Note that I declared T to be 'immutable' rather than 'type' for >>>> performance reasons-- I prefer the data in the array x to be packed in >>>> memory rather than accessed with pointers. If T were a 'type' then >>>> obviously the problem would go away. >>>> >>>> Maybe it is already possible to write a function or macro for this >>>> purpose in the existing language? >>>> >>>> Thanks, >>>> Steve Vavasis >>>> >>>> >
