This works just fine:

ubyte[] a=new ubyte[1];
a[0]=5;
bit[] b=cast(bit[])a;

But this doesn't:

ubyte a=5;
bit[] b=cast(bit[])a;

I would think that adding support of casting integral types to bit arrays would be a trivial task, as it would be just like casting a single-element array.

Then there's the inverse:

static bit[8] b=[1,0,1,0,0,0,0,0];
ubyte[] a=cast(ubyte[])b;
writefln(a);

I can see how casting from bit[] to an integral type would be a little more difficult, but really, all that'd have to be done would be to increase the length of the bit array to the size of the integer if it's too small.

How about it?

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:de4rek$27i9$1@digitaldaemon.com...
> This works just fine:
>
> ubyte[] a=new ubyte[1];
> a[0]=5;
> bit[] b=cast(bit[])a;
>
> But this doesn't:
>
> ubyte a=5;
> bit[] b=cast(bit[])a;
>
> I would think that adding support of casting integral types to bit arrays would be a trivial task, as it would be just like casting a single-element array.

What would cast(bit[])(1+2) do?

> Then there's the inverse:
>
> static bit[8] b=[1,0,1,0,0,0,0,0];
> ubyte[] a=cast(ubyte[])b;
> writefln(a);
>
> I can see how casting from bit[] to an integral type would be a little more difficult, but really, all that'd have to be done would be to increase the length of the bit array to the size of the integer if it's too small.
>
> How about it?
> 

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:de4usa$2bas$1@digitaldaemon.com...
> What would cast(bit[])(1+2) do?

Return a bit array 32 elements long with bits 0 and 1 set to 1?

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:de578c$2iq7$1@digitaldaemon.com...
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:de4usa$2bas$1@digitaldaemon.com...
>> What would cast(bit[])(1+2) do?
>
> Return a bit array 32 elements long with bits 0 and 1 set to 1?

But a dynamic array is a pointer and length so I don't know where it is getting the pointer from. I know bit[] is funny sometimes wrt array semantics but it needs a ptr.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:de58t4$2k80$1@digitaldaemon.com...
> But a dynamic array is a pointer and length so I don't know where it is getting the pointer from. I know bit[] is funny sometimes wrt array semantics but it needs a ptr.

..You know, that's a good point.  Then again, nothing says that the result of a cast has to point to the location of the expression that was casted, so a cast to a bit array could return a new bit array.  But if you really wanted the cast to point to the original number, the D compiler could force it to, doing something like:

bit[]* intToBit(int* x)
{
    struct arr
    {
        uint length;
        void* ptr;
    }

    arr* a=new arr;
    a.length=32;
    a.ptr=x;
    return cast(bit[]*)cast(void*)a;
}

void main()
{
    int x=5;
    bit[] b=*intToBit(&x);

    // Writes 00000000000000000000000000000101
    for(int i=31; i>=0; i--)
        writef(b[i] ? 1 : 0);
}

Of course, since the compiler has access to all the internals of the arrays, it wouldn't have to use a kludgy function like that.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:de5lla$2uci$1@digitaldaemon.com...
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:de58t4$2k80$1@digitaldaemon.com...
>> But a dynamic array is a pointer and length so I don't know where it is getting the pointer from. I know bit[] is funny sometimes wrt array semantics but it needs a ptr.
>
> ..You know, that's a good point.  Then again, nothing says that the result of a cast has to point to the location of the expression that was casted,

Not all expression evaluate to lvalues. For example there is no location of the result of the expression (1+2). You can't say &(1+2).

> so a cast to a bit array could return a new bit array.  But if you really wanted the cast to point to the original number, the D compiler could force it to, doing something like:
>
> bit[]* intToBit(int* x)
> {
>    struct arr
>    {
>        uint length;
>        void* ptr;
>    }
>
>    arr* a=new arr;
>    a.length=32;
>    a.ptr=x;
>    return cast(bit[]*)cast(void*)a;
> }

I'm not sure why you are allocating a new dynamic array reference from the GC. One can write intToBit as

bit[] toBits(void* x, int len) {
  return cast(bit[])x[0..len];
}

int main() {
  int x;
  bit[] b = toBits(&x,x.sizeof*8);
  b[3] = 1;
  printf("%d\n",x);
  return 0;
}

In any case one still has to supply a pointer to x. I think making more special cases for bit arrays is not worth it especially when a little helper like toBits can make the code more readable if that's the concern.

> void main()
> {
>    int x=5;
>    bit[] b=*intToBit(&x);
>
>    // Writes 00000000000000000000000000000101
>    for(int i=31; i>=0; i--)
>        writef(b[i] ? 1 : 0);
> }
>
> Of course, since the compiler has access to all the internals of the arrays, it wouldn't have to use a kludgy function like that.
> 

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:de5pf8$3168$1@digitaldaemon.com...
> Not all expression evaluate to lvalues. For example there is no location of the result of the expression (1+2). You can't say &(1+2).

You also can't say 5=x, but that didn't seem to be what you were getting at with your first reply.

> I'm not sure why you are allocating a new dynamic array reference from the GC. One can write intToBit as
>
> bit[] toBits(void* x, int len) {
>  return cast(bit[])x[0..len];
> }
>
> int main() {
>  int x;
>  bit[] b = toBits(&x,x.sizeof*8);
>  b[3] = 1;
>  printf("%d\n",x);
>  return 0;
> }

I wasn't aware that you could cast void[] to bit[], as I had tried casting void* to bit[] and it didn't seem to work; hence the bit[]* thing in mine.

> In any case one still has to supply a pointer to x. I think making more special cases for bit arrays is not worth it especially when a little helper like toBits can make the code more readable if that's the concern.

Oh, have it your way then ;)  I just always thought that it was odd that D supported arrays of consecutive bits, while it had no support for converting integers, which are consecutive arrays of bits, to bit arrays.

I've often thought that the ability to slice any basic type would be quite nice, eg.

ubyte b;
uint i;
long l;

b[0] = 1;
i[5] = 0;
l[16..32] = 1;

in other words slicing a basic type gives a bit[] or bit.

Of course the big problem that rears it's head is how does this work:

bit[] b;
uint i;

b = i[5..15];

A slice on non-byte boundaries... It seems it can't without copying or great internal hoop jumping. So, I would limit the feature to lvalue assignments instead, i.e.

bit[10] b;
uint i;

i[5..15] = b[]; //would be fine, but
b = i[5..15]; //would not

perhaps, if we desire, we can allow:

b[] = i[5..15];

or

b = i[5..15].dup;

i.e. a copy would be easier to implement.

The reason I like this is that code that would read something like:

variable |= 1<<16;

or

variable &= ~(1<<16)

or whatever can now read:

variable[16] = 1;

or

variable[16] = 0;

(note I have not paid strict attention to the code above, it's probably wrong, but you should get the picture)

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsvr9dkx523k2f5@nrage.netwin.co.nz...
> I've often thought that the ability to slice any basic type would be quite nice, eg.
>
> ubyte b;
> uint i;
> long l;
>
> b[0] = 1;
> i[5] = 0;
> l[16..32] = 1;
>
> in other words slicing a basic type gives a bit[] or bit.
>
> Of course the big problem that rears it's head is how does this work:
>
> bit[] b;
> uint i;
>
> b = i[5..15];
>
> A slice on non-byte boundaries... It seems it can't without copying or great internal hoop jumping. So, I would limit the feature to lvalue assignments instead, i.e.
>
> bit[10] b;
> uint i;
>
> i[5..15] = b[]; //would be fine, but
> b = i[5..15]; //would not
>
> perhaps, if we desire, we can allow:
>
> b[] = i[5..15];
>
> or
>
> b = i[5..15].dup;
>
> i.e. a copy would be easier to implement.
>
> The reason I like this is that code that would read something like:
>
> variable |= 1<<16;
>
> or
>
> variable &= ~(1<<16)
>
> or whatever can now read:
>
> variable[16] = 1;
>
> or
>
> variable[16] = 0;
>
> (note I have not paid strict attention to the code above, it's probably wrong, but you should get the picture)
>
> Regan

Right, that's kind of what I would like this for, twiddling bits in numbers. I was thinking about something to replace bitfields as well, as shifting and masking is just so much fun, but it'd be nice to do something like a[0..4]=6.  Then again, for bitfields, you could use a union between a bit[32] and a uint.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:de7c77$17at$1@digitaldaemon.com...
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsvr9dkx523k2f5@nrage.netwin.co.nz...
>> I've often thought that the ability to slice any basic type would be quite nice, eg.
>>
>> ubyte b;
>> uint i;
>> long l;
>>
>> b[0] = 1;
>> i[5] = 0;
>> l[16..32] = 1;
>>
>> in other words slicing a basic type gives a bit[] or bit.
>>
>> Of course the big problem that rears it's head is how does this work:
>>
>> bit[] b;
>> uint i;
>>
>> b = i[5..15];
>>
>> A slice on non-byte boundaries... It seems it can't without copying or great internal hoop jumping. So, I would limit the feature to lvalue assignments instead, i.e.
>>
>> bit[10] b;
>> uint i;
>>
>> i[5..15] = b[]; //would be fine, but
>> b = i[5..15]; //would not
>>
>> perhaps, if we desire, we can allow:
>>
>> b[] = i[5..15];
>>
>> or
>>
>> b = i[5..15].dup;
>>
>> i.e. a copy would be easier to implement.
>>
>> The reason I like this is that code that would read something like:
>>
>> variable |= 1<<16;
>>
>> or
>>
>> variable &= ~(1<<16)
>>
>> or whatever can now read:
>>
>> variable[16] = 1;
>>
>> or
>>
>> variable[16] = 0;
>>
>> (note I have not paid strict attention to the code above, it's probably wrong, but you should get the picture)
>>
>> Regan
>
> Right, that's kind of what I would like this for, twiddling bits in numbers. I was thinking about something to replace bitfields as well, as shifting and masking is just so much fun, but it'd be nice to do something like a[0..4]=6.  Then again, for bitfields, you could use a union between a bit[32] and a uint.
>

The thing about a bit array is that it doesn't know about big-endian or little-endian and the exact packing of the bit array into memory is compiler-dependent (see for example http://www.digitalmars.com/d/arrays.html#bitarrays). With shifting the compiler knows the size of the data being shifted and so you the coder don't have to worry about all the memory layout details.