• S.G (4/4) Nov 21 2019 Hello, I've seen that many D enum are still typed as int because
• Iain Buclaw (14/14) Nov 22 2019 LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQpPbiBOb3YgMjIsIDIwMTksIDg6...
• S.G (17/35) Nov 23 2019 Thanks for the quick replying, even if a bit disapointing.
• Iain Buclaw (16/32) Nov 23 2019 Understood, however for AST data structures in the D language frontend, ...

S.G <sg.j gmx.com> writes:

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 ?

Iain Buclaw <ibuclaw gdcproject.org> writes:

LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQpPbiBOb3YgMjIsIDIwMTksIDg6NTUg
QU0sIFMuRyB2aWEgRC5nbnUgPCBkLmdudUBwdXJlbWFnaWMuY29tPiB3cm90ZToKSGVsbG8sIEkn
dmUgc2VlbiB0aGF0IG1hbnkgRCBlbnVtIGFyZSBzdGlsbCB0eXBlZCBhcyBpbnQgYmVjYXVzZQpv
ZiB0aGUgYysrIGhlYWRlcnMgYnV0IGMrKzExIGFsbG93IHRoaW5ncyBsaWtlCmVudW0gU3R1ZmY6
IHVuc2lnbmVkIGNoYXIgeyAuLi4gfQpJcyBpcyBvayB0byB1c2UgdGhpcyBpbiB0aGUgaGVhZGVy
cyA/CgpUaGUgYmFzZWxpbmUgYm9vdHN0cmFwcGluZyBjb21waWxlciBpcyBDKys5OC4KCllvdSBk
b24ndCBoYXZlIHRvIHR5cGUgRCBlbnVtcyBhcyBpbnQsIGJ1dCB0aGUgYmFzZSB0eXBlIG11c3Qg
YmUgdXNlZCBleHBsaWNpdGx5IGlmIHlvdSB3YW50IHRvIHVzZSB0aGVtIGFzIHBhcmFtZXRlcnMg
b3IgZmllbGRzLCB3aGljaCBkZWZlYXRzIHNvbWUgcHVycG9zZXMgb2YgaGF2aW5nIHRoZSBlbnVt
IGluIHRoZSBmaXJzdCBwbGFjZS4KCldvcmsgb24gYXV0b2dlbmVyYXRpbmcgQysrIGhlYWRlcnMg
c2hvdWxkIHJlbmRlciB0aGlzIG1vc3RseSByZWR1bmRhbnQgKHBlb3BsZSB3YW50IGZyZWVkb20g
dG8gcGljayB0aGVpciBzdGQgdmVyc2lvbiksIGFwYXJ0IGZyb20gdGhlIG5vdCBiZWluZyBhYmxl
IHRvIHVzZSB0aGVzZSBlbnVtcyBhcyBwYXJhbWV0ZXJzIGR1ZSB0byBBQkkvbWFuZ2xpbmcgaW5j
b21wYXRpYmlsaXRpZXMuCgotLQpJYWlu

S.G <SG somewhere.sg> writes:

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

Iain Buclaw <ibuclaw gdcproject.org> writes:

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