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.gyolchan...@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.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? >>> >> >