On Thursday, 12 May 2022 at 03:43:50 UTC, Walter Bright wrote:
> On 5/11/2022 5:12 PM, Adam D Ruppe wrote:
>
> C interoperability is a major barrier to using D. ImportC is probably the best leverage for D among existing initiatives.

Personally I think importC will be useful, will be able to leverage many C libraries that are available but too long to port: lua, codecs, all stb_thing.h... the list is really quite long. Why not steal C++ and Zig biggest appeal.

On Thursday, 12 May 2022 at 14:02:51 UTC, Guillaume Piolat wrote:
> will be able to leverage many C libraries that are available but too long to port: lua, codecs, all stb_thing.h... the list is really quite long.

You know most those things already work.

On Thursday, 12 May 2022 at 15:12:53 UTC, Adam D Ruppe wrote:
> On Thursday, 12 May 2022 at 14:02:51 UTC, Guillaume Piolat wrote:
>> will be able to leverage many C libraries that are available but too long to port: lua, codecs, all stb_thing.h... the list is really quite long.
>
> You know most those things already work.

I think you are coming at this as someone who knows a lot about C and D already (not that Guillaume doesn't). The relevant question to me is how much work is it for someone relatively new to D to figure out how to call C code. If it importC reduces the barrier, then I see it as a positive, even if there are other tools that work better for you or others.

On Thursday, 12 May 2022 at 15:58:03 UTC, jmh530 wrote:
> If it importC reduces the barrier, then I see it as a positive
> even if there are other tools that work better for you or others.

Well, like I said, importC does have potential to exceed dstep. Maybe it will next year, but it isn't there yet.

So we shouldn't undersell the significant success that D and dstep have already had.

On Thursday, 12 May 2022 at 16:38:21 UTC, Adam D Ruppe wrote:
> On Thursday, 12 May 2022 at 15:58:03 UTC, jmh530 wrote:
>> If it importC reduces the barrier, then I see it as a positive
>> even if there are other tools that work better for you or others.
>
> Well, like I said, importC does have potential to exceed dstep. Maybe it will next year, but it isn't there yet.
>
> So we shouldn't undersell the significant success that D and dstep have already had.

The real advantage of importc I've found is that I was able to mix the whole c code inside my project, not only the headers. And it avoids me to compile and link an external library (if license allows it).

It's difficult to make it works with GCC or clang. But it's really easy using tcc.

Andrea

On Thu, May 12, 2022 at 04:38:21PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Thursday, 12 May 2022 at 15:58:03 UTC, jmh530 wrote:
> > If it importC reduces the barrier, then I see it as a positive even if there are other tools that work better for you or others.
> 
> Well, like I said, importC does have potential to exceed dstep. Maybe it will next year, but it isn't there yet.
> 
> So we shouldn't undersell the significant success that D and dstep have already had.

Yeah, current D (without ImportC) + dstep (or just manual translation, really) is already very nice to work with, in terms of interfacing with C libraries. I've done a fair bit of work using this method, interfacing with libraries like libxcb, xlib, MPFR, freetype, sqlite, EGL, GLES2, etc., just to name a few.

What will make ImportC stand out above the current situation is integrated preprocessor support, which apparently Walter already submitted a PR for.  Once that's done and we can import C headers without creating a separate input file (either a .di or .d with dstep or manual preprocessing), *then* ImportC would have better value than what we currently have.


T

-- 
Fact is stranger than fiction.

On Wed, May 11, 2022 at 07:22:53PM +0000, Don Allen via Digitalmars-d wrote: [...]
> I think the criticisms that have been directed at D about lacking vision, blah, blah, have been from those who have not used it to produce working software that does what it is supposed to do with good performance. In other words, usable in practice (recall that Einstein said "In theory, there's no difference between theory and practice"). That is the ultimate test and at least for me, D has passed that test.
[...]

Possibly this is true, I don't know.  But personally, I have not found a better language than D, among those I have tried out when I first got deeply dissatisfied with C++ and started looking for alternatives.  It's not without its own flaws, granted, but for what I need to do, it's ideal.


T

-- 
There is no gravity. The earth sucks.

On Thursday, 12 May 2022 at 15:12:53 UTC, Adam D Ruppe wrote:
>
> You know most those things already work.

But until now it was worth it to translate 5000loc by hand just to simplify the build.

On Thursday, 12 May 2022 at 17:04:27 UTC, H. S. Teoh wrote:
> On Thu, May 12, 2022 at 04:38:21PM +0000, Adam D Ruppe via Digitalmars-d wrote:
>> [...]
>
> Yeah, current D (without ImportC) + dstep (or just manual translation, really) is already very nice to work with, in terms of interfacing with C libraries. I've done a fair bit of work using this method, interfacing with libraries like libxcb, xlib, MPFR, freetype, sqlite, EGL, GLES2, etc., just to name a few.
>
> What will make ImportC stand out above the current situation is integrated preprocessor support, which apparently Walter already submitted a PR for.  Once that's done and we can import C headers without creating a separate input file (either a .di or .d with dstep or manual preprocessing), *then* ImportC would have better value than what we currently have.
>
>
> T

Preprocessor support takes more than just preprocessing the C source.

You need to be able to use the macros or it's useless. That's the main thing dstep is able to do.

On 5/12/2022 10:25 AM, max haughton wrote:
> Preprocessor support takes more than just preprocessing the C source.

I know.

> You need to be able to use the macros or it's useless. That's the main thing dstep is able to do.

I understand that access to the manifest constant #define's is important. But it's not useless to not have them. We're making progress on it.