View mode: basic / threaded / horizontal-split · Log in · Help
July 30, 2012
Re: Why must bitfields sum to a multiple of a byte?
On Monday, 30 July 2012 at 17:43:28 UTC, Ali Çehreli wrote:
> On 07/30/2012 10:15 AM, Andrej Mitrovic wrote:
>
> > import std.bitmanip;
> > struct Foo
> > {
> >      mixin(bitfields!(
> >          uint, "bits1", 32,
> >      ));
> > }
> >
> > D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\bitmanip.d(76):
> Error:
> > shift by 32 is outside the range 0..31
> >
> > Should I file this?
>
> Yes, it's a bug.

 And likely one I'll be working on fairly soon. I've been 
concentrating on the BitArray, but I'll get more of the bitfields 
very very soon.
July 30, 2012
Re: Why must bitfields sum to a multiple of a byte?
On 7/31/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>   And likely one I'll be working on fairly soon. I've been
> concentrating on the BitArray, but I'll get more of the bitfields
> very very soon.
>

Cool. What about the max limit of 64bits per bitfield instantiation? I
don't suppose this is common in C++ but I wouldn't know..
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On Monday, 30 July 2012 at 23:41:39 UTC, Andrej Mitrovic wrote:
> On 7/31/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>> And likely one I'll be working on fairly soon. I've been 
>> concentrating on the BitArray, but I'll get more of the 
>> bitfields very very soon.
>
> Cool. What about the Max limit of 64bits per bitfield 
> instantiation? I don't suppose this is common in C++ but I 
> wouldn't know..

 The limitation is based on what kind of types you can use. If 
you want a field 1000 bits long, i don't see why not; But 
obviously you can't treat it like an int or bool. (No cheap way 
to make a BigInt here :P), and packing say a struct, it would be 
slow since it has to copy each bit individually, or if it's byte 
aligned, by bytes.

 It assumes the largest type we can currently use which is ulong, 
if cent ever gets properly added, then 128bits will become 
available. If they want to go higher than likely type 'dime' or 
'nickel' or bicent (256bits? :P) can be used once the template is 
modified. Maybe tricent can be 384 and quadcent can be 512.... 
Mmmm :) or it could just be large256, ularge256.

 As for the 'why', is that all of the bitfields work by assuming 
bit-shifting and low level binary operators to do the job. So, 2 
for 4 ints would be

int value;
int a() @property {
  return value & 0x7;
}
void a(int v) @property {
  value &= ~0x7;
  value |= v & 0x7;
}

int b() @property {
  return (value>>4) & 0x7;
}
void a(int v) @property {
  value &= ~(0x7 << 4);
  value |= (v & 0x7) << 4;
}

 That may be flawed but it gives you a basic idea.
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On Tuesday, 31 July 2012 at 00:00:24 UTC, Era Scarecrow wrote:
Corrections:
 So, 2 variables using 4 bit ints would be

> void a(int v) @property {
>   value &= ~(0x7 << 4);
>   value |= (v & 0x7) << 4;
> }

the second setter should be
 void b(int v) @property {
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On 7/31/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>   It assumes the largest type we can currently use which is ulong

Ah yes, it makes sense now. Thanks for the brain cereal. :p
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On Tuesday, 31 July 2012 at 00:44:16 UTC, Andrej Mitrovic wrote:
> On 7/31/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>>   It assumes the largest type we can currently use which is 
>> ulong
>
> Ah yes, it makes sense now. Thanks for the brain cereal. :p

I saw your bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=8474

The bug is only when the field is EXACTLY 32 bits BTW. bitfields 
works quite nice with 33 or whatever. More details in the report.
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On 7/31/12, monarch_dodra <monarchdodra@gmail.com> wrote:
> The bug is only when the field is EXACTLY 32 bits BTW. bitfields
> works quite nice with 33 or whatever. More details in the report.

Yeah 32 or 64 bits, thanks for changing the title.
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
> On 7/31/12, monarch_dodra <monarchdodra@gmail.com> wrote:
>> The bug is only when the field is EXACTLY 32 bits BTW. 
>> bitfields works quite nice with 33 or whatever. More details 
>> in the report.
>
> Yeah 32 or 64 bits, thanks for changing the title.

 I wonder, is it really a bug? If you are going to have it fill a 
whole size it would fit anyways, why even put it in as a 
bitfield? You could just declare it separately.

 I get the feeling it's not so much a bug as a design feature. If 
you really needed a full size not aligned with whole bytes (or 
padded appropriately) then I could understand, but still...


 And I'm the one that changed the title name. Suddenly I'm 
reminded of south park (movie) and the buttfor.
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On 7/31/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>   I wonder, is it really a bug? If you are going to have it fill a
> whole size it would fit anyways, why even put it in as a
> bitfield? You could just declare it separately.

I don't really know, I'm looking at this from a point of wrapping C++.
I haven't used bitfields myself in my own code.
July 31, 2012
Re: Why must bitfields sum to a multiple of a byte?
On Tuesday, 31 July 2012 at 16:48:37 UTC, Andrej Mitrovic wrote:
> On 7/31/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>> I wonder, is it really a bug? If you are going to have it fill 
>> a whole size it would fit anyways, why even put it in as a 
>> bitfield? You could just declare it separately.
>
> I don't really know, I'm looking at this from a point of 
> wrapping C++. I haven't used bitfields myself in my own code.

 I'd say it's not a bug since C/C++ is free to reorder the fields 
you'd need to tinker with it anyways; HOWEVER if you still need 
to be able to have it then who's to stop you from doing it?

 I think more likely a flag/version or some indicator that you 
didn't make a mistake, such as making them depreciated so it 
complains to you. Kinda like how you can't make assignments in if 
statements or do useless compares, it's an error and helps 
prevent issues that are quite obviously mistakes.
1 2 3 4 5
Top | Discussion index | About this forum | D home