www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Regarding: import "foo.h";

reply Walter Bright <newshound2 digitalmars.com> writes:
Over the years, I've given a fair amount of thought to, and talked about it
with 
various people:

    import "foo.h";

or something similar as a way to interface existing C (or even C++) code to D. 
On the plus side, I have a C/C++ front end which could be adapted to do this.
On 
the minus,

1. there may be various #define's necessary to compile it that would normally
be 
supplied on the command line to the C compiler

2. there are various behavior switches (see the PR for DMD that wants to set
the 
signed'ness of char types)

3. rather few .h files seem to be standard compliant C. They always rely on 
various compiler extensions

4. the license would be the same as for the back end

5. having a C/C++ front end as a "bag on the side" of a D compiler seems like a 
heavy burden to anyone wanting to write a D compiler, besides being a fairly 
massive maintenance effort as it would have to be kept up with the latest C/C++ 
standards and extensions

Essentially, I think it is impractical, and in the worst case scenario, could 
actually sink D because of the diversion of effort necessary. Instead, any such 
tool should be a separate tool, designed, built, and maintained separately. 
Perhaps DMD could call it like it calls the linker.
Jul 17 2013
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:

 Perhaps DMD could call it like it calls the linker.


But then DMD would have to act as the middle-man between the 3rd 
party tool and the header files (e.g. it would have to pass 
custom flags to the tool, there's no question how many flags 
could exist..). I don't see much benefit to it.

It also doesn't help that `import "foo.h"` does who-knows-what 
behind the scenes, for example there's the question of which 
generated D module is actually then imported, and what do the 
actual D declarations look like? The user has to know, otherwise 
he can't use the wrapper code just by looking at the foo.h header 
file.

On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:

 4. the license would be the same as for the back end


Why even bother starting this thread?
Jul 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2013 4:01 PM, Andrej Mitrovic wrote:

 Why even bother starting this thread?


Because the topic comes up now and then.
Jul 17 2013
parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Wednesday, 17 July 2013 at 23:10:36 UTC, Walter Bright wrote:

 On 7/17/2013 4:01 PM, Andrej Mitrovic wrote:

 Why even bother starting this thread?


 Because the topic comes up now and then.


I couldn't imagine anyone doing a significant amount of work only 
to have their work marked with a DigitalMars & Symantec stamp.
Jul 17 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2013 4:18 PM, Andrej Mitrovic wrote:

 On Wednesday, 17 July 2013 at 23:10:36 UTC, Walter Bright wrote:

 On 7/17/2013 4:01 PM, Andrej Mitrovic wrote:

 Why even bother starting this thread?


 Because the topic comes up now and then.


 I couldn't imagine anyone doing a significant amount of work only to have their
 work marked with a DigitalMars & Symantec stamp.


Symantec would not automatically own any derived work, they would only own the 
original.

As for DM, yes, it'd be necessary to assign copyright to DM. Otherwise, having 
source files with a dozen different copyrights on various lines of code in it
is 
completely impractical. Tango got into difficulty, for example, because various 
people owned various copyrights in it, meaning that the license could not be 
changed as it was hard to reach them all, let alone get any sort of consensus 
agreement.

These kinds of issues are, of course, why Phobos is Boost licensed.

And lastly, the use of github ensures that contributors get credit for their 
work regardless of license/copyright issues. It's just one of the things that 
makes github such a great collaborative tool for us.
Jul 17 2013
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/17/13 3:52 PM, Walter Bright wrote:

 Over the years, I've given a fair amount of thought to, and talked about it
with various people:

     import "foo.h";

 or something similar as a way to interface existing C (or even C++) code to D.
On the plus side, I
 have a C/C++ front end which could be adapted to do this. On the minus,

 1. there may be various #define's necessary to compile it that would normally
be supplied on the
 command line to the C compiler

 2. there are various behavior switches (see the PR for DMD that wants to set
the signed'ness of char
 types)

 3. rather few .h files seem to be standard compliant C. They always rely on
various compiler extensions

 4. the license would be the same as for the back end

 5. having a C/C++ front end as a "bag on the side" of a D compiler seems like
a heavy burden to
 anyone wanting to write a D compiler, besides being a fairly massive
maintenance effort as it would
 have to be kept up with the latest C/C++ standards and extensions

 Essentially, I think it is impractical, and in the worst case scenario, could
actually sink D
 because of the diversion of effort necessary. Instead, any such tool should be
a separate tool,
 designed, built, and maintained separately. Perhaps DMD could call it like it
calls the linker.


6. the time cost of parsing/semanticing c/c++ is significantly higher than D,
making .h importing 
dwarf the rest of the cost of the compilation process

7. .h files are roughly static so translating them on each compilation unit is
wasteful, generate 
once as part of the build process and update only as needed.  This is stuff
that build processes are 
good at.
Jul 17 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-07-18 01:53, Brad Roberts wrote:


 6. the time cost of parsing/semanticing c/c++ is significantly higher
 than D, making .h importing dwarf the rest of the cost of the
 compilation process

 7. .h files are roughly static so translating them on each compilation
 unit is wasteful, generate once as part of the build process and update
 only as needed.  This is stuff that build processes are good at.


Yeah, that's true. This year Clang has got support for modules. 
Basically a better and safe(er) version of percompiled headers.

-- 
/Jacob Carlborg
Jul 17 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 18 July 2013 at 06:35:21 UTC, Jacob Carlborg wrote:

 On 2013-07-18 01:53, Brad Roberts wrote:


 6. the time cost of parsing/semanticing c/c++ is significantly 
 higher
 than D, making .h importing dwarf the rest of the cost of the
 compilation process

 7. .h files are roughly static so translating them on each 
 compilation
 unit is wasteful, generate once as part of the build process 
 and update
 only as needed.  This is stuff that build processes are good 
 at.


 Yeah, that's true. This year Clang has got support for modules. 
 Basically a better and safe(er) version of percompiled headers.


They are not there yet.

I was really looking forward for it, mostly due to the C++17 
modules effort being done at Apple.

However, what was presented at WWDC 2013 was a half baked 
solution that only works in Objective-C for system headers.

--
Paulo
Jul 18 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-07-18 09:36, Paulo Pinto wrote:


 They are not there yet.

 I was really looking forward for it, mostly due to the C++17 modules
 effort being done at Apple.

 However, what was presented at WWDC 2013 was a half baked solution that
 only works in Objective-C for system headers.


If it works for Objective-C, I'm pretty sure it will work for C. In 
fact, the documentation contains a lot of examples with standard C headers.

http://clang.llvm.org/docs/Modules.html

Why would they work only for system headers?

-- 
/Jacob Carlborg
Jul 18 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 18 July 2013 at 08:23:42 UTC, Jacob Carlborg wrote:

 On 2013-07-18 09:36, Paulo Pinto wrote:


 They are not there yet.

 I was really looking forward for it, mostly due to the C++17 
 modules
 effort being done at Apple.

 However, what was presented at WWDC 2013 was a half baked 
 solution that
 only works in Objective-C for system headers.


 If it works for Objective-C, I'm pretty sure it will work for 
 C. In fact, the documentation contains a lot of examples with 
 standard C headers.

 http://clang.llvm.org/docs/Modules.html

 Why would they work only for system headers?


Because that is what Apple is supporting in XCode 5. If you have 
an Apple ID, have a look at,

Session "Advances in Objective-C"
https://developer.apple.com/wwdc/videos

Slides from page 9 up to 69. Slide 61 lists all current caveats.


--
Paulo
Jul 18 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
I think it would be really cool if D could compile in header 
files. But also agree the tradeoffs really suck. And if DMD does 
it as a compiler extension then it is as good as required. If it 
was done in LDC or GDC I wouldn't consider it a problem at all.

Ultimately an easy to install 3rd party program should be fine. I 
haven't needed to convert header files for a while so never 
attempted dstep yet.
Jul 17 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/18/2013 12:52 AM, Walter Bright wrote:

 4. the license would be the same as for the back end


I take it using a different C/C++ frontend (such as clang) is out, at least for
DMD ... ?


 Essentially, I think it is impractical, and in the worst case scenario, could
 actually sink D because of the diversion of effort necessary. Instead, any such
 tool should be a separate tool, designed, built, and maintained separately.
 Perhaps DMD could call it like it calls the linker. 


Personally I don't mind whether it's part of the compiler or a separate tool, as
long as there is a solution available that makes it easy to link to C/C++ code
without having to manually write bindings.  Though I imagine that for optimal
performance, some manual work will always be necessary.
Jul 17 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-07-18 07:54, Joseph Rushton Wakeling wrote:


 Though I imagine that for optimal performance, some manual work will always be
necessary.


Yes, it's always the preprocessor that's causing the problems, including 
#includes.

-- 
/Jacob Carlborg
Jul 17 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-07-18 00:52, Walter Bright wrote:


 4. the license would be the same as for the back end


The license of what?


 5. having a C/C++ front end as a "bag on the side" of a D compiler seems
 like a heavy burden to anyone wanting to write a D compiler, besides
 being a fairly massive maintenance effort as it would have to be kept up
 with the latest C/C++ standards and extensions


Yes, that's why a library like libclang should be used.

-- 
/Jacob Carlborg
Jul 17 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:

 1. there may be various #define's necessary to compile it that 
 would normally be supplied on the command line to the C compiler

 2. there are various behavior switches (see the PR for DMD that 
 wants to set the signed'ness of char types)


Those two plus the fact that h->d conversion is fairly static and 
should not be done at compilation stage is pretty much enough for 
me to oppose such misfeature.

Everything else is not that relevant. Even if the idea was 
considered good, pulling in more dmc legacy is the last thing I'd 
be glad to see done.
Jul 18 2013
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:

 Over the years, I've given a fair amount of thought to, and 
 talked about it with various people:

    import "foo.h";


Personally I'd rather see something like this as part of a more 
generic feature rather than built in to the compiler. If CTFE 
could call external libraries or programs, such as utilizing 
libclang for parsing (and ideally if it could perform caching of 
[pure?] mixins that took more than X to evaluate), it would be 
nicer than including a C parser inside a D compiler. Then it's 
the responsibility of the project / package manager to make sure 
that the dependency is present and also avoids certain licensing 
/ maintainability issues. Not sure how feasible having CTFE be 
able to call external libraries is though, or if it would be 
desired.
Jul 18 2013