Thanks for the pointers! BTW, is there anything to make C/C++ bitfields easy to deal with in Julia? I haven't found anything yet :-(
On Monday, June 1, 2015 at 3:18:59 PM UTC+2, Isaiah wrote: > > Alignment (or at least, rounding up the size of a structure to a multiple >> of the requested alignment) > > > See discussion here: https://github.com/JuliaLang/julia/issues/2555 > > I got a 404 error for that... can you please update the link? > > > https://github.com/JuliaLang/julia/pull/7906 > > On Mon, Jun 1, 2015 at 2:00 AM, Scott Jones <[email protected] > <javascript:>> wrote: > >> Alignment (or at least, rounding up the size of a structure to a multiple >> of the requested alignment) I think is also needed... it's been around for >> ages, and is now part of the C11 standard. >> Being able to set such attributes would be very useful for C/C++ >> interfaces. >> >> On Tuesday, February 10, 2015 at 3:32:27 AM UTC+1, Jameson wrote: >>> >>> That's a pretty reasonable idea. There's even a few more attributes >>> (coming from llvm and the platform ABI), that I would add to the list (such >>> as float-compatible, complex-compatible, unsigned/signed). >>> >>> However, it's unlikely to happen because it's also a lot more work on >>> everyone. The more types of types that get introduced, the more >>> interactions they start to have and it can get a bit hard to manage for >>> both code authors and compiler writers. Supporting all the same set of >>> operations as C is a partial goal, but supporting them with exactly the >>> same semantics is not. >>> >>> I expect at some future point, immutable will become synonymous with >>> inline and `const` annotations will be allowed on individual fields of >>> mutable types. This is similar to what you are suggestion, although it >>> comes at it from a slightly different angle. >>> >>> (packed is usually something else – however, the ability to specify >>> arbitrary offsets for fields in a type is also something that will likely >>> be implemented in the future) >>> >>> > As an aside, the standard lib breaks immutability with char arrays >>> for fast ASCII string joins, though that usage should be safe as it is in >>> the scope of the allocating method. >>> >>> I've occasionally tried to convert such code when I come across it to >>> create an array first, then to turn that into a String. That has the same >>> allocation semantics, but doesn't ignore the the intended immutability of >>> strings. Although, as you pointed out, in practice, it doesn't matter here. >>> >>> On Mon Feb 09 2015 at 9:14:18 PM Michael Francis <[email protected]> >>> wrote: >>> >>>> It does sound like immutable has been conflated with packed data >>>> structures. That seems unfortunate. It would be nice if the properties of >>>> a >>>> type could be selected at create time rather than with specific reserved >>>> words. Something like the following. >>>> >>>> type Buffer <: Immutable,Packed >>>> a::Int64 >>>> end >>>> >>>> Though my preference would be to remove the reserved keywords all >>>> together. >>>> >>>> Buffer = type( >>>> a::Int64 >>>> ; flags = immutable | packed >>>> ) >>>> >>>> Which is just a function which happens to register a type and has a few >>>> named args. >>>> >>>> As an aside, the standard lib breaks immutability with char arrays for >>>> fast ASCII string joins, though that usage should be safe as it is in the >>>> scope of the allocating method. >>> >>> >
