[GSoC] Header Generation for C/C++
turkeyman at gmail.com
Tue Jul 30 18:02:55 UTC 2019
On Tue, Jul 30, 2019 at 9:20 AM Seb via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 30 July 2019 at 14:43:01 UTC, Eduard Staniloiu wrote:
> > On Monday, 29 July 2019 at 01:19:36 UTC, Manu wrote:
> >> On Sun, Jul 28, 2019 at 5:20 PM Gregor Mückl via Digitalmars-d
> >> <digitalmars-d at puremagic.com> wrote:
> >>> On Monday, 22 July 2019 at 18:12:01 UTC, Manu wrote:
> >>> > [...]
> >>> That's a pretty neat hack!
> >>> I'm just worried about two things:
> >>> - it makes the generated code harder to read (not that big of
> >>> a
> >>> deal)
> >> Barely... and a generated header is not really for human
> >> consumption either way.
> >>> - if you happen to include headers with conflicting D_ENUM*
> >>> defines (e.g. a potential 3rd party D wrapper), you might get
> >>> some nasty surprises :/
> >> C/C++ programmers now how to do macros and what to expect.
> > So should we go ahead with generating code based on the
> > `-extern-std` value or by using defines?
> > After sleeping a bit on this, I prefer `-extern-std`.
> Advantage of using defines is that you can use one header to rule
> them all.
> I.e. you generate it once and then make it available to your
> => it's immediately ready to be distributed
> With -extern-std, you have to generate n-interfaces and
> distribute them to your clients + probably add a few defines
> A comprise could be that by default you emit all combinations and
> only if -extern-std is defined you emit the headers for that
Nar.. just emit the defines, and let the `-extern-std` drive the most
likely desired default for when the macros are not defined by the
More information about the Digitalmars-d