On Wednesday, 17 July 2019 at 17:43:21 UTC, Manu wrote:
> On Wed, Jul 17, 2019 at 6:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> I want to give a heads-up to everyone for the following issue (this had me scratching my head for a couple of days unit I caught it):
>>
>> The current code doesn't take into account `enum BaseType`s, ex:
>> ```
>> enum TOK : ubyte { /* ... */ }
>>
>> class Expression
>> {
>>    TOK op;
>>    /* ... */
>> }
>> ```
>>
>> The `enum TOK` above gets generated as
>> ```
>> enum TOK { /* ... */ }
>> ```
>
> So... use:
>
> enum class TOK : unsigned char { /* */ };
>
> ??

That’s what I would like to use, but `enum class`es are starting with C++11

This will also lead to breaking code as the fields must now be accessed as `TOK::field`.

That being said, I think C++11 would be nice

On Wednesday, 17 July 2019 at 18:00:38 UTC, Manu wrote:
> On Wed, Jul 17, 2019 at 7:29 AM Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Wed, 17 Jul 2019 at 15:40, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >
>> >
>> > I have the following question: Can we use C++11 or would that break GDC / LDC? With C++11 we could use `enum class` which would solve this nicely. The issue with `enum class` is that it will break code since not the fields need to be prefixed with the enum name.
>> >
>> > But still, what do you think? What are the pros and cons of supporting/using C++11?
>> >
>>
>> No you cannot use C++11, yes it will break GDC bootstrap.
>
> This needs to be optional. I can't NOT use C++11 for instance... We could read the --extern-std flag to drive the output perhaps?

We could use `#if __cplusplus < 201103L` to emit for C++98 and C++11, but I was hoping we could avoid that.

I guess it will come to inserting a bunch of `#if`s

On Wednesday, 17 July 2019 at 13:38:44 UTC, Eduard Staniloiu wrote:
> I want to give a heads-up to everyone for the following issue (this had me scratching my head for a couple of days unit I caught it):
>
> [...]

it would be needed for pure C also. So would not work.

As for smaller sized enum part of a struct I sometime use

struct{
   enum TOK op:CHAR_BIT;
}

works in most cases except when you need to take its address or its offset.

On Wed, Jul 17, 2019 at 11:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 17 July 2019 at 17:41:23 UTC, Manu wrote:
> > On Wed, Jul 17, 2019 at 4:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> enum TestEnum
> >> {
> >>      TESTENUMaa = 0,
> >>      TESTENUMbb = 1
> >> };
> >
> > What in earth is that?
>
> This is the convention that is used in the manually written headers in order to avoid name clashing between fields of different enums in the C headers

Okay... but it's also the worst thing ever, and no real user would
want this code to be emit from the compiler ;)
Safe to say this is a strictly DMD-specific naming pattern, and I
don't think that should be our benchmark for a public-facing feature.

A better non-C++11 name might be `TestEnum_aa`?

On Wed, Jul 17, 2019 at 11:45 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 17 July 2019 at 17:43:21 UTC, Manu wrote:
> > On Wed, Jul 17, 2019 at 6:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> I want to give a heads-up to everyone for the following issue (this had me scratching my head for a couple of days unit I caught it):
> >>
> >> The current code doesn't take into account `enum BaseType`s,
> >> ex:
> >> ```
> >> enum TOK : ubyte { /* ... */ }
> >>
> >> class Expression
> >> {
> >>    TOK op;
> >>    /* ... */
> >> }
> >> ```
> >>
> >> The `enum TOK` above gets generated as
> >> ```
> >> enum TOK { /* ... */ }
> >> ```
> >
> > So... use:
> >
> > enum class TOK : unsigned char { /* */ };
> >
> > ??
>
> That’s what I would like to use, but `enum class`es are starting with C++11
>
> This will also lead to breaking code as the fields must now be accessed as `TOK::field`.
>
> That being said, I think C++11 would be nice

Breaking what? This feature doesn't exist yet! There's nobody with code written against these generated headers...

On Wed, Jul 17, 2019 at 11:55 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 17 July 2019 at 18:00:38 UTC, Manu wrote:
> > On Wed, Jul 17, 2019 at 7:29 AM Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Wed, 17 Jul 2019 at 15:40, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> >
> >> >
> >> > I have the following question: Can we use C++11 or would that break GDC / LDC? With C++11 we could use `enum class` which would solve this nicely. The issue with `enum class` is that it will break code since not the fields need to be prefixed with the enum name.
> >> >
> >> > But still, what do you think? What are the pros and cons of supporting/using C++11?
> >> >
> >>
> >> No you cannot use C++11, yes it will break GDC bootstrap.
> >
> > This needs to be optional. I can't NOT use C++11 for instance... We could read the --extern-std flag to drive the output perhaps?
>
> We could use `#if __cplusplus < 201103L` to emit for C++98 and C++11, but I was hoping we could avoid that.
>
> I guess it will come to inserting a bunch of `#if`s

No, that doesn't work, because then code written against the header
needs to be adapted according to the -std used to compile.
I think it would be fine to use the -extern-std supplied to DMD to
drive the output that way.

On Wed, 17 Jul 2019 at 20:01, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wed, Jul 17, 2019 at 7:29 AM Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On Wed, 17 Jul 2019 at 15:40, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > >
> > >
> > > I have the following question: Can we use C++11 or would that break GDC / LDC? With C++11 we could use `enum class` which would solve this nicely. The issue with `enum class` is that it will break code since not the fields need to be prefixed with the enum name.
> > >
> > > But still, what do you think? What are the pros and cons of supporting/using C++11?
> > >
> >
> > No you cannot use C++11, yes it will break GDC bootstrap.
>
> This needs to be optional. I can't NOT use C++11 for instance... We could read the --extern-std flag to drive the output perhaps?

I assumed the question was only about dmd headers, and not the tool itself.

Naturally, there should be a way to configure the style or language standards you want the code to be outputted in (and this is another reason why I think a standalone app is better).

-- 
Iain

On Wed, 17 Jul 2019 at 18:05, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 17 July 2019 at 14:28:34 UTC, Iain Buclaw wrote:
> > On Wed, 17 Jul 2019 at 15:40, Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >>
> >> I have the following question: Can we use C++11 or would that break GDC / LDC? With C++11 we could use `enum class` which would solve this nicely. The issue with `enum class` is that it will break code since not the fields need to be prefixed with the enum name.
> >>
> >> But still, what do you think? What are the pros and cons of supporting/using C++11?
> >>
> >
> > No you cannot use C++11, yes it will break GDC bootstrap.
>
> Can you elaborate a bit on this, please? I'm curious what are the reasons why we cannot use it.
>
> Not really pushing for C++11, but I'd like to understand what is/ which are the blocker/s.
>

The stage1 gcc bootstrap is built with -std=gnu++98, assumedly to be compatible with the widest range of platforms possible that gcc supports.  This is something controlled by the toplevel, and not in the per-language build config.

-- 
Iain

On Wed, 17 Jul 2019 at 22:59, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wed, Jul 17, 2019 at 11:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On Wednesday, 17 July 2019 at 17:41:23 UTC, Manu wrote:
> > > On Wed, Jul 17, 2019 at 4:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > >>
> > >> enum TestEnum
> > >> {
> > >>      TESTENUMaa = 0,
> > >>      TESTENUMbb = 1
> > >> };
> > >
> > > What in earth is that?
> >
> > This is the convention that is used in the manually written headers in order to avoid name clashing between fields of different enums in the C headers
>
> Okay... but it's also the worst thing ever, and no real user would
> want this code to be emit from the compiler ;)
> Safe to say this is a strictly DMD-specific naming pattern, and I
> don't think that should be our benchmark for a public-facing feature.
>
> A better non-C++11 name might be `TestEnum_aa`?


I guess the most typical C/C++98 style would be:

enum xml_status {
  XML_STATUS_ERROR = 0,
  XML_STATUS_OK = 1,
  XML_STATUS_SUSPENDED = 2
};

Some may want the enum to be called xml_status_flags, or some may want a different prefix for the enum members.

-- 
Iain

On Wed, 17 Jul 2019 at 23:00, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wed, Jul 17, 2019 at 11:45 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On Wednesday, 17 July 2019 at 17:43:21 UTC, Manu wrote:
> > > On Wed, Jul 17, 2019 at 6:40 AM Eduard Staniloiu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > >>
> > >> I want to give a heads-up to everyone for the following issue (this had me scratching my head for a couple of days unit I caught it):
> > >>
> > >> The current code doesn't take into account `enum BaseType`s,
> > >> ex:
> > >> ```
> > >> enum TOK : ubyte { /* ... */ }
> > >>
> > >> class Expression
> > >> {
> > >>    TOK op;
> > >>    /* ... */
> > >> }
> > >> ```
> > >>
> > >> The `enum TOK` above gets generated as
> > >> ```
> > >> enum TOK { /* ... */ }
> > >> ```
> > >
> > > So... use:
> > >
> > > enum class TOK : unsigned char { /* */ };
> > >
> > > ??
> >
> > That’s what I would like to use, but `enum class`es are starting with C++11
> >
> > This will also lead to breaking code as the fields must now be accessed as `TOK::field`.
> >
> > That being said, I think C++11 would be nice
>
> Breaking what? This feature doesn't exist yet! There's nobody with code written against these generated headers...
>

LDC and GDC builds will break as a result of switching to auto-generated headers, but that's expected when things switch to mechanical naming anyway...  we'll need to update our side of the compiler regardless.

-- 
Iain