Hello, I've seen that many D enum are still typed as int because of the c++ headers but c++11 allow things like

enum Stuff: unsigned char { ... }

Is is ok to use this in the headers ?

-------- Original Message --------
On Nov 22, 2019, 8:55 AM, S.G via D.gnu < d.gnu@puremagic.com> wrote:
Hello, I've seen that many D enum are still typed as int because
of the c++ headers but c++11 allow things like
enum Stuff: unsigned char { ... }
Is is ok to use this in the headers ?

The baseline bootstrapping compiler is C++98.

You don't have to type D enums as int, but the base type must be used explicitly if you want to use them as parameters or fields, which defeats some purposes of having the enum in the first place.

Work on autogenerating C++ headers should render this mostly redundant (people want freedom to pick their std version), apart from the not being able to use these enums as parameters due to ABI/mangling incompatibilities.

--
Iain

On Friday, 22 November 2019 at 08:29:07 UTC, Iain Buclaw wrote:
> -------- Original Message --------
> On Nov 22, 2019, 8:55 AM, S.G via D.gnu < d.gnu@puremagic.com> wrote:
> Hello, I've seen that many D enum are still typed as int because
> of the c++ headers but c++11 allow things like
> enum Stuff: unsigned char { ... }
> Is is ok to use this in the headers ?
>
> The baseline bootstrapping compiler is C++98.
>
> You don't have to type D enums as int, but the base type must be used explicitly if you want to use them as parameters or fields, which defeats some purposes of having the enum in the first place.
>
> Work on autogenerating C++ headers should render this mostly redundant (people want freedom to pick their std version), apart from the not being able to use these enums as parameters due to ABI/mangling incompatibilities.
>
> --
> Iain

Thanks for the quick replying, even if a bit disapointing.

The reason why I asked is because I'd like to avoid cases where the enum type is used directly and that creates an alignment issue that implies memory overhead, i.e

enum SomeEnumeratedType // could be `ubyte` or `unsigned char`
{
   member1, member2, member3
}

class Stuff
{
   ubyte[7] allTheOtherMembers; //let's say
   SomeEnumeratedType someEnumeratedType // now a Stuff instance takes 16 bytes
                                         // because SomeEnumeratedType takes 4 bytes...
}

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 23 November 2019 13:54, S.G via D.gnu <d.gnu@puremagic.com> wrote:
> Thanks for the quick replying, even if a bit disapointing.
>
> The reason why I asked is because I'd like to avoid cases where the enum type is used directly and that creates an alignment issue that implies memory overhead, i.e
>
> enum SomeEnumeratedType // could be `ubyte` or `unsigned char`
> {
> member1, member2, member3
> }
>
> class Stuff
> {
> ubyte[7] allTheOtherMembers; //let's say
> SomeEnumeratedType someEnumeratedType // now a Stuff instance
> takes 16 bytes
> // because
> SomeEnumeratedType takes 4 bytes...
> }

Understood, however for AST data structures in the D language frontend, I don't think such field packing would really make any valuable difference on memory.  If the fields are arranged to not have a needless amount of alignment holes in the middle, such as:

class Expression
{
    ubyte op;
    // <-- up to 7 bytes padding inserted here.
    Type* type;
    ubyte size;
    ubyte parens;
    // <-- up to 6 bytes padding inserted here.
    Loc loc;
}

Then the best improvements one can make would be in relation to memory consumption is either better GC management or add more scope destruction (in my opinion).

--
Iain