My understanding is that normal (mutable) types should be C-layout compatible soon (and maybe already are in v0.4--I forget the status of that work).
Although, I'm less sure of the future of packed arrays of types. Cheers, Kevin On Monday, February 9, 2015, Michael Francis <[email protected]> wrote: > My 2c but is sounds like Julia needs a struct keyword which is C packed > but does not enforce immutability. Immutable should means just that and > allows the compiler more options for optimization. > > On Monday, February 9, 2015 at 10:22:49 AM UTC-5, Kevin Squire wrote: >> >> Hi Steve, >> >> I have a function in VideoIO.jl which does this: https://github.com/ >> kmsquire/VideoIO.jl/blob/master/src/util.jl#L6-L14 >> >> When wrapping libav/ffmpeg libraries, some of the structs have dozens of >> fields, yet I found that needed to declare them as immutable for C >> compatibility. At the same time, I needed to modify a few values >> occasionally. >> >> I have used it without consequences yet, but I don't know that there >> aren't any. I would reason that modifying a field of an immutable is >> equivalent to overwriting the whole thing with mostly the same values, but >> I'm pretty sure the compiler doesn't recognize that. >> >> Cheers, >> Kevin >> >> On Sun, Feb 8, 2015 at 12:35 PM, <[email protected]> wrote: >> >>> 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 >>> >>> >>
