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.

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..

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.

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 {

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

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.

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.

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.

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.

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.