On Tuesday, 17 June 2014 at 13:07:33 UTC, Marc Schütz wrote:
> On Monday, 16 June 2014 at 23:04:33 UTC, Rene Zwanenburg wrote:
>> This one depends on taste, but these helpers can be eliminated by changing the Header definition a little. It's the same union / anonymous struct trick from the previous post, only this time with bitfields:
>>
>> http://dpaste.dzfl.pl/13258b0ce0c4
>
> If you define nested structs/unions, it's better to make them static whenever possible, because non-static nested structs have an additional hidden field for the context.

Good call. In this case it doesn't add the hidden field, but for the sake of consistency I agree it's better to add static.

> Also, when you work with bit-(un)packing, you need to make sure it works on big- and little-endian CPUs.

Yeah. He's using a custom read function that takes endianness into account, so I didn't mention it.

On Wednesday, 18 June 2014 at 14:05:12 UTC, Rene Zwanenburg wrote:
> On Tuesday, 17 June 2014 at 13:07:33 UTC, Marc Schütz wrote:
>> On Monday, 16 June 2014 at 23:04:33 UTC, Rene Zwanenburg wrote:
>>> This one depends on taste, but these helpers can be eliminated by changing the Header definition a little. It's the same union / anonymous struct trick from the previous post, only this time with bitfields:
>>>
>>> http://dpaste.dzfl.pl/13258b0ce0c4
>>
>> If you define nested structs/unions, it's better to make them static whenever possible, because non-static nested structs have an additional hidden field for the context.
>
> Good call. In this case it doesn't add the hidden field, but for the sake of consistency I agree it's better to add static.

Interesting, I thought it's there for all nested structs. But I see it's only added if the struct has a method, but then it's always there, no matter whether the methods actually accesses the outer context. Probably for consistency reasons...

On Thursday, 19 June 2014 at 12:06:58 UTC, Marc Schütz wrote:
> On Wednesday, 18 June 2014 at 14:05:12 UTC, Rene Zwanenburg wrote:
>> On Tuesday, 17 June 2014 at 13:07:33 UTC, Marc Schütz wrote:
>>> On Monday, 16 June 2014 at 23:04:33 UTC, Rene Zwanenburg wrote:
>>>> This one depends on taste, but these helpers can be eliminated by changing the Header definition a little. It's the same union / anonymous struct trick from the previous post, only this time with bitfields:
>>>>
>>>> http://dpaste.dzfl.pl/13258b0ce0c4
>>>
>>> If you define nested structs/unions, it's better to make them static whenever possible, because non-static nested structs have an additional hidden field for the context.
>>
>> Good call. In this case it doesn't add the hidden field, but for the sake of consistency I agree it's better to add static.
>
> Interesting, I thought it's there for all nested structs. But I see it's only added if the struct has a method, but then it's always there, no matter whether the methods actually accesses the outer context. Probably for consistency reasons...

The absence of the hidden field without methods is probably to maintain C compitability; code that is both valid C and D must have the same semantics. I think that includes struct layout?

Once again thanks for the feedback. The RLE rewrite using std is impressive! I will use it today or tomorrow, great stuff.

Do you think it's ready for a v0.1 release? It be willing to add it to dub if it passes general D coding stardards.

Once again, thanks for feedback and vast improvements of the code.

Best,
Mike

On Friday, 20 June 2014 at 11:15:20 UTC, Mike wrote:
> Do you think it's ready for a v0.1 release? It be willing to add it to dub if it passes general D coding stardards.

Sure, go for it :). Dub package versioning should be done using SemVer so there are some restrictions on how to number a release.

http://semver.org/