All types (immutable and mutable) have been c-compatible since v0.1. I rewrote the manual page on interacting with c and fortran last night in my jn/ccall3 branch PR. If anyone can review and comment on that text, it would be much appreciated. I'm not sure if readthedocs allows you to preview pull request changes. In a local git repo checkout, you can do 'cd doc && make html'
I've wanted to make something like Simons gist above what unsafe_store does, given a symbol, but hadn't gotten around to implementing it yet. On Mon, Feb 9, 2015 at 12:32 PM Kevin Squire <[email protected]> wrote: > 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 >>>> >>>> >>>
