In the end, I'm sure, that manual intervention won't be necessary and
the CAPI repository will be replaced by std.c.translate or something
like that.
You'd just do this:
mixin cInclude("sqlite3.h");
and voila.
The mixin will print out all macros, which i couldn't translate and
had to evaluate in-line. If some of those macros are important to the
user, then translating a C header would consist of including the
header and adding the missing macros.
I think this is a much better idea, then manually translating
everything, because this is cheaper, covers more libraries.
On Tue, Oct 25, 2011 at 12:13 PM, Gor Gyolchanyan
<gor.f.gyolchan...@gmail.com> wrote:
> Sure. You're right. Weird macros are often used for handy shortcuts
> (like the aforementioned for loop header), which are not handy enough
> to invent a just-as-weird way of translating them. Everything else is
> either for compiler extensions (which either have built-in support in
> D or are simply nit translatable) or hacks for compile-time activity
> (can be replaced by more intuitive counterparts in D).
> Translating _any_ C code is impossible. The C preprocessor cannot be
> fully simulated in D. But translating _this_ C code is not as hard,
> because it's a bad practice to abuse macros in C and no good C library
> would do that.
> The translator should not be a "_any_ C code translator", it should be
> an "arbitrary _this_ C code translator", which makes a few assumptions
> and does not guarantee 100% convertibility of the code.
> The most important part of the translator should be the problem
> reporter, which should point you to all the suspicious and
> untranslated parts of the C code, so you can deal with them manually.
>
> On Tue, Oct 25, 2011 at 6:36 AM, Marco Leise <marco.le...@gmx.de> wrote:
>> Am 21.10.2011, 10:32 Uhr, schrieb Gor Gyolchanyan
>> <gor.f.gyolchan...@gmail.com>:
>>
>>> That's ALL you can do in C. fill structs and call functions
>>> (fundamental type manipulation doesn't count).
>>> My personal research shows the following use cases of C macros (sorted
>>> by popularity in descending order):
>>> 1. enum
>>> 2. alias (most notably, conditionally compiled ones)
>>> 3. CTFE function
>>> 4. mixin template
>>> 5. syntactic alias
>>> 6. syntactic mixin template
>>>
>>> only the last 2 out of 6 cannot be translated to D.
>>> An example of a syntactic alias is this very common piece of C code:
>>> #ifdef __VERY_VERY_OLD_C_COMPILER__
>>> #define CONST
>>> #else
>>> #define CONST const
>>> #endif
>>
>> Maybe these cases can often be solved when, as you say, they are for
>> compatibility with other compilers. The header converter would simply assume
>> to be the latest and greatest of the known compilers and evaluate the code
>> like this:
>> - there is an #ifdef
>> - if it a define from the list of "known C compilers with quirks"
>> - jump right to the else block
>> The #define obviously can become more than one thing in the .d file. But
>> that is determined by the instantiation site. The above CONST would probably
>> be ignored when it is used in a const parameter declaration, because of D's
>> transitivity and become 'immutable __gshared' when used on a global
>> variable. Do you get the idea?
>>
>
