The CAPI Manifesto

[Gor Gyolchanyan]

The CAPI repository could be replaced by a package in Phobos with
aforementioned tiny modules with a single cImport and some additions.
They would be very small and conveniently available from Phobos.

On Tue, Oct 25, 2011 at 12:26 PM, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> wrote:
> 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.gyolchanyan at 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.Leise at gmx.de> wrote:
>>> Am 21.10.2011, 10:32 Uhr, schrieb Gor Gyolchanyan
>>> <gor.f.gyolchanyan at 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?
>>>
>>
>