Add ImportC compiler to dmd

Patrick Schluter Patrick.Schluter at bbox.fr
Mon May 10 06:21:19 UTC 2021


On Monday, 10 May 2021 at 03:13:51 UTC, Walter Bright wrote:
> On 5/9/2021 7:12 PM, Adam D. Ruppe wrote:
>> On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
>>> 11. C++ can compile C code, which is a ginormous advantage 
>>> for C++. Can we afford not to do that?
>> 
>> You want to fully compile the C code, not just extract 
>> bindings to link to it?
>
> Yes. Frankly, there's no reason not to once you've done nearly 
> all the work anyway. (For example, to evaluate static array 
> dimensions, an expression parser is needed.)
>
>
>> There's a lot of convenience to that - I've translated many 
>> lines of code from C to D by hand (a pretty easy process btw, 
>> just tedious, but if you sit down for a few hours and just do 
>> it, it is a result you can use for years to come) to take 
>> advantage of the convenience; being able to dmd -i is nice.
>
> Yeah, I did the backend conversion from C to D. It took a 
> couple hours per file, most of the tedium came from it being 
> terribly written code.
>
>
>> But I think the binding aspect is a lot more important and 
>> without the preprocessor part you just can't do that. It is an 
>> absolute must for this to be useful.
>
> I do have a forlorn hope that some C users will find it useful 
> to replace many of their macros with enum, const, and inline 
> function declarations.

As a C programmer I do use already a lot of enums and inlines, 
but the C semantic makes it quite tricky to use.
To use inlines in big C projects you have to guarantee that you 
emit the non inlined version of the function in exactly one 
module as some linkers do not like to have multiple object files 
with the same functions in them. You also want to have always at 
least one uninlined version of the fucnton so that it can
be linked with modules that were compiled with -O0 or 
-fno-inline. Not difficult, but requires some pre-processor 
acrobatics that can be problematic.

The issue I see is that the preprocessor is not bound by the 
language syntax and is sometimes used in things that cannot be 
translated easily to a D construct. I have, for example, a lot of 
functions that take a string and its length. For string literals 
it is annoying to count the number of characters so I have a 
macro to do it:

`#define SnL(array) (array),LENGTH(array)`

one will note that this fits two parameters

The LENGTH macro is also interesting it is define as

`#define LENGTH(arr)  (NUM_ELEMS(arr)-1)` ok, so far it's easy, 
but here comes
NUM_ELEMS, that I have lifted from the Linux kernel

     ```
     #ifdef __GNUC__
     /** Array size macro. Copied the Linux Kernel version which 
is not portable but
         which checks that it's a real array (not a pointer) and 
evaluates to a
         constant expression. This allows to use it to declare 
other array sizes. */
       #define NUM_ELEMS(arr) (sizeof(struct {int 
:-!!(__builtin_types_compatible_p(typeof (arr), typeof 
(&0[arr])));})+sizeof (arr)/sizeof 0[arr])
     #else
     /** A portable variant, but which doesn't check for array or 
pointer. */
       #define NUM_ELEMS(arr) (sizeof (arr)/sizeof 0[arr])
     #endif
     ```

This is the kind of macros that are all over the place in real C 
code.




More information about the Digitalmars-d mailing list