On 4/9/2018 4:03 AM, Atila Neves wrote:
> Here's my blog post about my project that allows directly #including C headers in D*

Very nice work, and great article!

On Monday, 9 April 2018 at 20:19:35 UTC, Seb wrote:
> On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote:
>> On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote:
>>> [...]
>>
>> This whole idea came about because a couple of years ago I was in a team that was responsible for legacy code written in C which had no tests. To write tests, we needed both to write the tests themselves and some fakes/mocks/doubles for the code that we depended on - essentially a whole operating system. I wasn't going to write that in C, since life is too short for that.
>>
>> [...]
>
> Speaking of dstep - it has greatly improved over the last years.
> I'm interested what stop you from using it or improving it (instead of rolling your own tool)?

I tried using dstep as the translation engine to avoid reinventing the wheel. I'm lazy, I don't want to write code that doesn't neeed to be written!

Unfortunately, dstep makes assumptions that are valid for it's trying to do that aren't for what I am, and ultimately made it very hard. The refactoring that would be needed would have been more work than doing it from scratch, so I sighed, cracked my knuckles, and wrote a bunch of code I didn't really want to.

I did copy the part of its test suite that was applicable though.

On Tuesday, 10 April 2018 at 08:45:06 UTC, Walter Bright wrote:
> On 4/9/2018 4:03 AM, Atila Neves wrote:
>> Here's my blog post about my project that allows directly #including C headers in D*
>
> Very nice work, and great article!

Thanks!

On Tuesday, 10 April 2018 at 09:36:39 UTC, Atila Neves wrote:
> On Monday, 9 April 2018 at 20:19:35 UTC, Seb wrote:
>> On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote:
>>> On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote:
>>>> [...]
>>>
>>> This whole idea came about because a couple of years ago I was in a team that was responsible for legacy code written in C which had no tests. To write tests, we needed both to write the tests themselves and some fakes/mocks/doubles for the code that we depended on - essentially a whole operating system. I wasn't going to write that in C, since life is too short for that.
>>>
>>> [...]
>>
>> Speaking of dstep - it has greatly improved over the last years.
>> I'm interested what stop you from using it or improving it (instead of rolling your own tool)?
>
> I tried using dstep as the translation engine to avoid reinventing the wheel. I'm lazy, I don't want to write code that doesn't neeed to be written!

Nice work. I prefer the DStep approach of translating the headers to D, but obviously it's not going to be as easy for the user as this, so this approach has its uses too.

Regarding "reinventing the wheel," I liked this recent blog post giving reasons why it can be a viable approach:

https://blog.cerebralab.com/#!/blog/11

On 4/9/18 7:03 AM, Atila Neves wrote:
> Here's my blog post about my project that allows directly #including C headers in D*
> 
> https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ 
> 
> 
> The summary is that, modulo bugs, things like this work:
> 
>      #include <stdio.h>
>      void main() { printf("Hello world\n".ptr); }
> 
> So far it's successfully compiled whilst #including pthread, libcurl, openssl and others. The blog and the github README have more information, and feel free to reply to this with questions.
> 
> dub: http://code.dlang.org/packages/dpp
> reddit: https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/ 
> 
> hacker news: It's in there somewhere, search around.
> 
> Atila
> 
> * Technically, "D + #include directives + C macros"

Awesome. Can't say I will use it, as I don't use C much, but I understand how difficult a task this is.

If you get to the point where you can #include <vector>, it will be doubly impressive!

-Steve

On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote:
> On 4/9/18 7:03 AM, Atila Neves wrote:
>> [...]
>
> Awesome. Can't say I will use it, as I don't use C much, but I understand how difficult a task this is.

Thanks!

> If you get to the point where you can #include <vector>, it will be doubly impressive!

Not *if*, *when*. ;)

Atila

On 4/10/18 12:51 PM, Atila Neves wrote:
> On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote:

>> If you get to the point where you can #include <vector>, it will be doubly impressive!
> 
> Not *if*, *when*. ;)

I hope you are right, but I remain skeptical :)

If I may throw a curveball back at you, I recall a question at last year's dconf during the talk about interfacing with C++ STL about using emplace_back instead of push_back. And the questioner who happened to be sitting next to me said "meh, push_back isn't very useful, nobody uses push_back any more" :P

-Steve

On Tuesday, 10 April 2018 at 18:01:37 UTC, Steven Schveighoffer wrote:
> On 4/10/18 12:51 PM, Atila Neves wrote:
>> On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote:
>
>>> If you get to the point where you can #include <vector>, it will be doubly impressive!
>> 
>> Not *if*, *when*. ;)
>
> I hope you are right, but I remain skeptical :)
>
> If I may throw a curveball back at you, I recall a question at last year's dconf during the talk about interfacing with C++ STL about using emplace_back instead of push_back. And the questioner who happened to be sitting next to me said "meh, push_back isn't very useful, nobody uses push_back any more" :P
>
> -Steve

Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P

Atila

On 4/10/18 2:36 PM, Atila Neves wrote:

> 
> Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P
> 

I think we all agree you aren't going to instantiate C++ templates in D (and who would want to).

But since you are using a wrapper to call the compiler, and invoking clang anyway, generating a file to compile which calls the template to generate the object file for the method, and then using the symbol generated to bind to the method might be possible. Of course, you first have to compile your D code to see what templates to generate! So this is another extra step.

It could be as easy as generating a mock C++ template for vector, that then has a symbol that d++ recognizes and both replaces with a real call AND helps you figure out what C++ template to generate. -vcg-ast may help here.

Whatever this is going to be, it ain't going to be fast...

-Steve

On Tuesday, 10 April 2018 at 19:28:09 UTC, Steven Schveighoffer wrote:
> On 4/10/18 2:36 PM, Atila Neves wrote:
>
>> 
>> Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P
>> 
>
> I think we all agree you aren't going to instantiate C++ templates in D (and who would want to).

Do we? Do I? :P

(I've actually seriously considered it)

> But since you are using a wrapper to call the compiler, and invoking clang anyway, generating a file to compile which calls the template to generate the object file for the method, and then using the symbol generated to bind to the method might be possible. Of course, you first have to compile your D code to see what templates to generate! So this is another extra step.

That's one of my ideas.

> It could be as easy as generating a mock C++ template for vector, that then has a symbol that d++ recognizes and both replaces with a real call AND helps you figure out what C++ template to generate. -vcg-ast may help here.

The details elude me right now, but that seems to make sense.

> Whatever this is going to be, it ain't going to be fast...

Compiling C++ isn't known to be fast. ;)

It might be possible to limit the damage by confining the C++ #includes to one D package or module so it doesn't get rebuilt every time.

Atila