www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Add modules to C with 10 lines of code

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/dlang/dmd/pull/13539

Yes, real, live modules!

(I can hardly believe this works!)
Jan 16 2022
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)


What's the intended use-case for this? If I'm using ImportC to 
import the header file for an existing C library, it's not going 
to contain a D-specific feature like this. If I'm writing a new 
library, and I want it to be usable from C, I can't use __import 
in the header file, because my C compiler won't recognize it. And 
if I only want my library to be usable from D, then I can just 
write a D module, and use a normal D import statement.

I guess it makes it possible to write code like this:

     /* example.h */
     #ifdef __IMPORTC__
     __import code.stdc.stdio;
     #else
     #include <stdio.h>
     #endif

     void example(void) { puts("example"); }

...but I'm struggling to see what advantages an example like the 
above has compared to the status quo. Slightly faster compile 
times, because __import is faster to process than #include? Less 
namespace pollution, because imported symbols aren't visible 
outside of the C header but #included symbols are?
Jan 16 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2022 6:55 AM, Paul Backus wrote:

 What's the intended use-case for this?


You no longer need dtoh if you're using ImportC.
Jan 16 2022
prev sibling next sibling parent Dave P. <dave287091 gmail.com> writes:
On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)


Next, add syntax for D slices to importC so we can cite the D 
compiler as prior art and finally get dynamic arrays that know 
their length into standard C. ;)
Jan 16 2022
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)


Would it be possible to have a block of ImportC code in D code? 
For instance for people gradually converting C code to D code.
Jan 16 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2022 2:31 PM, jmh530 wrote:

 Would it be possible to have a block of ImportC code in D code? For instance
for 
 people gradually converting C code to D code.


I had thought of that, as I've done gradual conversions myself. But using 
version's on the D side and #if on the C side works well enough, and I'd hate 
for it to be more than a temporary state of the code.
Jan 16 2022
prev sibling parent reply James Lu <jamtlu gmail.com> writes:
On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)


This dialect of C- what if it was called C+, and was a superset? 
C with some D features.

Just needs a preprocessor.
Jan 27 2022
parent forkit <forkit gmail.com> writes:
On Friday, 28 January 2022 at 02:56:02 UTC, James Lu wrote:

 This dialect of C- what if it was called C+, and was a 
 superset? C with some D features.

 Just needs a preprocessor.


just call it: DC
Jan 27 2022