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