Is it possible in D to do something like this (in C++):

struct Testor {
     int small_int: 5;
     int even_smaller_int: 3;
 };

this basically says make one integer of 5 bit size, and other of 3 bit size.. whole structure is 8bits long

"dominik" <aha@aha.com> wrote in message news:fdlnq6$f0i$1@digitalmars.com...
> Is it possible in D to do something like this (in C++):
>
> struct Testor {
>     int small_int: 5;
>     int even_smaller_int: 3;
> };
>
> this basically says make one integer of 5 bit size, and other of 3 bit size.. whole structure is 8bits long

or is it possible to do it with the class - since, as I understood, struct
is always by value in D - and class is by reference.
I have tried with C++ syntax, but it fails on : - so I presume there is
support for this, but I can't find correct syntax.

thanks

dominik schrieb:
> Is it possible in D to do something like this (in C++):
> 
> struct Testor {
>      int small_int: 5;
>      int even_smaller_int: 3;
>  };
> 
> this basically says make one integer of 5 bit size, and other of 3 bit size.. whole structure is 8bits long
> 
> 


D does not support bitfields. You can use property methods to get/set bits. They can later be inlined by the compiler.

struct Testor {
  int data;
  int  small_int(){ return data & 0x1f; }
  void small_int( int val ){ data = val | (data & ~0x1f); }
...
};

Tricks with templates and mixins are also possible.

dominik wrote:
> "dominik" <aha@aha.com> wrote in message news:fdlnq6$f0i$1@digitalmars.com...
>> Is it possible in D to do something like this (in C++):
>>
>> struct Testor {
>>     int small_int: 5;
>>     int even_smaller_int: 3;
>> };
>>
>> this basically says make one integer of 5 bit size, and other of 3 bit size.. whole structure is 8bits long
> 
> or is it possible to do it with the class - since, as I understood, struct
> is always by value in D - and class is by reference.
> I have tried with C++ syntax, but it fails on : - so I presume there is
> support for this, but I can't find correct syntax.
> 
> thanks

No, you cannot do this directly in D.  There was once support for a 'bit' type, but it was removed in favour of the 'bool' type; note that 'bool' variables take up a whole byte, not a single bit.

Your best bet might be to do something like this:

struct Tester
{
    private ubyte storage;

    ubyte small_int()
    {
        return storage & ((1<<5)-1));
    }
    ubyte small_int(ubyte v)
    {
        return (storage = (storage & ~((1<<5)-1)) | (v & ((1<<5)-1)));
    }
    // repeat for even_smaller_int :P
}

If you don't require those precise layout requirements, there's always std.bitarray.

	-- Daniel

"Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message news:fdloia$g9m$1@digitalmars.com...
> If you don't require those precise layout requirements, there's always std.bitarray.

Thanks guys, too bad bitfields are not supported - is there a special reason
why bitfields are not supported? I know there is a danger with them for
direct bitwise manipulation, but I find them very useful, and necessary -
since I'm doing alot of direct manipulation on arbitrary bitfield size types
(imaging and cryptography).
thanks again

dominik wrote:
> "Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message news:fdloia$g9m$1@digitalmars.com...
>> If you don't require those precise layout requirements, there's always std.bitarray.
> 
> Thanks guys, too bad bitfields are not supported - is there a special reason
> why bitfields are not supported? I know there is a danger with them for
> direct bitwise manipulation, but I find them very useful, and necessary -
> since I'm doing alot of direct manipulation on arbitrary bitfield size types
> (imaging and cryptography).
> thanks again

Basically, we used to have a 'bit' type which had two literals: true and false.  The problem was that bits were different from every other type in that you couldn't reliably take the address of one.  Things like a bit field's offsetof property wouldn't make sense at times.

Basically, people wanted a normal bool type more than they wanted a bit type, so bit got the toss.

Sadly, you can't be all things to all people.  :)

	-- Daniel

Daniel Keep wrote:

> dominik wrote:

>> Thanks guys, too bad bitfields are not supported - is there a special reason why bitfields are not supported? I know there is a danger with them for direct bitwise manipulation, but I find them very useful, and necessary - since I'm doing alot of direct manipulation on arbitrary bitfield size types (imaging and cryptography).

> Basically, we used to have a 'bit' type which had two literals: true and
> false.  The problem was that bits were different from every other type
> in that you couldn't reliably take the address of one.  Things like a
> bit field's offsetof property wouldn't make sense at times.

The bit type wasn't very usable for bitfields either, since it would
align to a 32-bit boundary and worked differently between platforms...
It also had some strange non-integer properties, so it was better
for everyone involved when it just assumed the bool type name again.

The D programming language overview instead had this to say:
   "Bit fields of arbitrary size.
    Bit fields are a complex, inefficient feature rarely used."
http://www.digitalmars.com/d/1.0/overview.html "Features To Drop"

So one needs to wrap the bitfields in bigger types and do the shifting
oneself, as was shown by previous posters. Tedious, but not very hard ?

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:fdnlrd$jci$1@digitalmars.com...
>
>     "Bit fields are a complex, inefficient feature rarely used."

that could be contested

> Tedious, but not very hard ?

not at all, but tedious as you say :)