On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:

> Maybe even turning some macros into functions?

DStep can do that today.

-- 
/Jacob Carlborg

On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
> On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
>
>> Maybe even turning some macros into functions?
>
> DStep can do that today.

That's cool!  How robust is in practice on typical header files (i.e zlib and similar)?

What were the objections to integration with DMD?

On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
> On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
>
>> Maybe even turning some macros into functions?
>
> DStep can do that today.

How difficult is it to turn C++ headers usable for D? Interfacing with D for giant libraries like Physx is what is holding me back utilizing D.

On 2017-05-30 17:15, Ola Fosheim Grostad wrote:

> That's cool!  How robust is in practice on typical header files (i.e
> zlib and similar)?

I would say ok. I did try to run DStep on zlib.h just now. It got quite confused when translating the comments. But disabling that it looked a lot better. For example, all #defines which are for constants are properly translated to enums (manifest constants). The following macros:

#define deflateInit(strm, level) \
        deflateInit_((strm), (level), ZLIB_VERSION, (int)sizeof(z_stream))
#define inflateInit(strm) \
        inflateInit_((strm), ZLIB_VERSION, (int)sizeof(z_stream))
#define deflateInit2(strm, level, method, windowBits, memLevel, strategy) \
        deflateInit2_((strm),(level),(method),(windowBits),(memLevel),\
                      (strategy), ZLIB_VERSION, (int)sizeof(z_stream))
#define inflateInit2(strm, windowBits) \
        inflateInit2_((strm), (windowBits), ZLIB_VERSION, \
                      (int)sizeof(z_stream))
#define inflateBackInit(strm, windowBits, window) \
        inflateBackInit_((strm), (windowBits), (window), \
                      ZLIB_VERSION, (int)sizeof(z_stream))

Are translate to:

extern (D) auto deflateInit(T0, T1)(auto ref T0 strm, auto ref T1 level)
{
    return deflateInit_(strm, level, ZLIB_VERSION, cast(int) z_stream.sizeof);
}

extern (D) auto inflateInit(T)(auto ref T strm)
{
    return inflateInit_(strm, ZLIB_VERSION, cast(int) z_stream.sizeof);
}

extern (D) auto deflateInit2(T0, T1, T2, T3, T4, T5)(auto ref T0 strm, auto ref T1 level, auto ref T2 method, auto ref T3 windowBits, auto ref T4 memLevel, auto ref T5 strategy)
{
    return deflateInit2_(strm, level, method, windowBits, memLevel, strategy, ZLIB_VERSION, cast(int) z_stream.sizeof);
}

extern (D) auto inflateInit2(T0, T1)(auto ref T0 strm, auto ref T1 windowBits)
{
    return inflateInit2_(strm, windowBits, ZLIB_VERSION, cast(int) z_stream.sizeof);
}

extern (D) auto inflateBackInit(T0, T1, T2)(auto ref T0 strm, auto ref T1 windowBits, auto ref T2 window)
{
    return inflateBackInit_(strm, windowBits, window, ZLIB_VERSION, cast(int) z_stream.sizeof);
}

Currently DStep cannot handle #if or #ifdef.

> What were the objections to integration with DMD?

I don't recall exactly, I recommend reading the post I linked to [1].

[1] http://forum.dlang.org/post/ks3kir$1ubq$1@digitalmars.com

-- 
/Jacob Carlborg

On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
> Currently DStep cannot handle #if or #ifdef.

Oh, that is often required…

>> What were the objections to integration with DMD?
>
> I don't recall exactly, I recommend reading the post I linked to [1].

My impression is that there is no consensus? So still a possibility then.

On Tuesday, 30 May 2017 at 15:50:01 UTC, Swoorup Joshi wrote:
> On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
>> On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
>>
>>> Maybe even turning some macros into functions?
>>
>> DStep can do that today.
>
> How difficult is it to turn C++ headers usable for D? Interfacing with D for giant libraries like Physx is what is holding me back utilizing D.

Ha ha. I wonder what the decision makers think when all of us are like: "this is what D needs", "this hold me back", "kill GC", "I can't live without in-built RAII", ...

On Monday, May 29, 2017 13:58:54 Brad Roberts via Digitalmars-d wrote:
> On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote:
> > On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
> >> IMO,  the most important thing is getting the job done.
> >
> > * getting the job done right.
> > Otherwise, you are just going to accumulate patchy code for which you
> > will pay down the line continuously.
>
> At least as important as getting the job done, is doing jobs.  As much fun as it is to debate and discuss what could or needs to be done to attract one group of developers or another, actually using and releasing systems built with D are going to contribute to accumulating to the total mass of code.  Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch.
>
> Eventually that mass might actually reach critical.   But even if it doesn't, things continue to get incrementally easier for those that already use D and it's ecosystem.

+1000

- Jonathan M Davis

On 2017-05-30 21:42, Ola Fosheim Grøstad wrote:
> On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
>> Currently DStep cannot handle #if or #ifdef.
>
> Oh, that is often required…

Yes, but it's very difficult to do.

Say there's some code looking like this:

#ifdef Windows
#include <windows.h>
DWORD foo();
#else
int foo();
#endif

Ideally that should be translated to:

version (Windows)
{
    import core.sys.windows.windows;
    DWORD foo();
}
else
{
    int foo();
}

But trying to compile the code in the "body" for Windows, on any other platform will fail because windows.h is not available.

> My impression is that there is no consensus? So still a possibility then.

Good look convincing Walter that DMD should depend on DStep and LLVM.

-- 
/Jacob Carlborg

On 2017-05-30 17:50, Swoorup Joshi wrote:

> How difficult is it to turn C++ headers usable for D?

Currently DStep doesn't support C++ headers at all. If think it's quite some work to support that. Of course it's possible to start simple, i.e. C++ free functions and continue from there.

-- 
/Jacob Carlborg

On Wednesday, 31 May 2017 at 06:52:00 UTC, Jacob Carlborg wrote:
>
> Yes, but it's very difficult to do.
>
> Say there's some code looking like this:
>
> [snip]

Some simpler #ifdefs might be easier to handle and add a lot of value. Then you can make a list of stuff that is not supported, like #ifdefs with #includes.