D - Idea: "include" as "import" with automatic "extern"
- Russell Lewis <spamhole-2001-07-16 deming-os.org> Sep 06 2002
- "Walter" <walter digitalmars.com> Sep 06 2002
- Pavel Minayev <evilone omen.ru> Sep 07 2002
- "Walter" <walter digitalmars.com> Sep 07 2002
- Pavel Minayev <evilone omen.ru> Sep 07 2002
- "Richard Krehbiel" <rich kastle.com> Sep 10 2002
- "Walter" <walter digitalmars.com> Sep 10 2002
- "Richard Krehbiel" <rich kastle.com> Sep 11 2002
- "Walter" <walter digitalmars.com> Sep 12 2002
- Pavel Minayev <evilone omen.ru> Sep 10 2002
- Russell Lewis <spamhole-2001-07-16 deming-os.org> Sep 09 2002
I have just downloaded Burt's Linux D port, and am starting on moving
one of my projects over from C/C++ to D. The new project will be mixing
C source (generated by Bison) with my D code. They communicate through
some interface functions I'll define. I will need to include a .h file
for the C code, and have a matching D module. But why not just include
the C file? If I keep it such that it doesn't include an C specifics
(like including other files, or using macros), then there's no reason
you couldn't do this (from the D code):
include (C) "c_to_d_interface.h";
which would be just like importing the .h file, except that all
definitions there are given "extern (C)".
Thoughts?
Sep 06 2002
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3D78DDAF.6090201 deming-os.org...I have just downloaded Burt's Linux D port, and am starting on moving one of my projects over from C/C++ to D. The new project will be mixing C source (generated by Bison) with my D code. They communicate through some interface functions I'll define. I will need to include a .h file for the C code, and have a matching D module. But why not just include the C file? If I keep it such that it doesn't include an C specifics (like including other files, or using macros), then there's no reason you couldn't do this (from the D code): include (C) "c_to_d_interface.h"; which would be just like importing the .h file, except that all definitions there are given "extern (C)". Thoughts?
It's a great idea, and one I originally intended to implement. The downside is that every D compiler needs to contain within it a pretty complete C front end! While that's easy for me, since I have a C front end laying around <g>, it could make it difficult for others to build independent D implementations. So, instead my idea is to write a "C to D header translator" program, which is simply taking the C front end and bashing it so it emits the equivalent D declaration for each C declaration. I haven't written that yet, otherwise windows.d would be complete <g>.
Sep 06 2002
Walter wrote:So, instead my idea is to write a "C to D header translator" program, which is simply taking the C front end and bashing it so it emits the equivalent D declaration for each C declaration. I haven't written that yet, otherwise windows.d would be complete <g>.
It's quite easy to parse functions, structs etc, but I really don't know what to do with #define. Is there any reliable way to tell if it is a conditional compilation flag, a macro, or just a constant?
Sep 07 2002
"Pavel Minayev" <evilone omen.ru> wrote in message news:ald4u4$1get$2 digitaldaemon.com...Walter wrote:So, instead my idea is to write a "C to D header translator" program,
is simply taking the C front end and bashing it so it emits the
declaration for each C declaration. I haven't written that yet,
windows.d would be complete <g>.
what to do with #define. Is there any reliable way to tell if it is a conditional compilation flag, a macro, or just a constant?
In general, it is not. However, most macros fall into predictable patterns like: #define ABC 3 and can be handled appropriately. Ones that don't would just be ignored. This means that the tool won't be perfect, but could handle 95% of the conversion chore.
Sep 07 2002
Pavel Minayev <evilone omen.ru> Walter wrote:In general, it is not. However, most macros fall into predictable patterns like: #define ABC 3 and can be handled appropriately. Ones that don't would just be ignored. This means that the tool won't be perfect, but could handle 95% of the conversion chore.
Problems start when it comes to things like this: #define FOO 666 #define BAR FOO // macro? constant? #define BAZ MACRO(BAR/FOO) // now what? I'd say that, unfortunately, WinAPI headers have quite a lot of such things. And one still have to distinguish between conditional compilation flags and macro...
Sep 07 2002
"Walter" <walter digitalmars.com> wrote in message news:aldb7u$1ueq$1 digitaldaemon.com..."Pavel Minayev" <evilone omen.ru> wrote in message news:ald4u4$1get$2 digitaldaemon.com...Walter wrote:So, instead my idea is to write a "C to D header translator" program,
is simply taking the C front end and bashing it so it emits the
declaration for each C declaration. I haven't written that yet,
windows.d would be complete <g>.
what to do with #define. Is there any reliable way to tell if it is a conditional compilation flag, a macro, or just a constant?
In general, it is not. However, most macros fall into predictable patterns like: #define ABC 3 and can be handled appropriately. Ones that don't would just be ignored. This means that the tool won't be perfect, but could handle 95% of the conversion chore.
Why not just run a CPP tool on the D source before compiling it with D? That'll take care of the #defined symbols (and, incidentally, the #includes) for you. -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Sep 10 2002
"Richard Krehbiel" <rich kastle.com> wrote in message news:alkre0$2fim$1 digitaldaemon.com...Why not just run a CPP tool on the D source before compiling it with D? That'll take care of the #defined symbols (and, incidentally, the
for you.
That is certainly possible, but I personally want to leave the preprocessor behind and not perpetuate it.
Sep 10 2002
"Walter" <walter digitalmars.com> wrote in message news:all4cc$2qfk$1 digitaldaemon.com..."Richard Krehbiel" <rich kastle.com> wrote in message news:alkre0$2fim$1 digitaldaemon.com...Why not just run a CPP tool on the D source before compiling it with D? That'll take care of the #defined symbols (and, incidentally, the
for you.
That is certainly possible, but I personally want to leave the
behind and not perpetuate it.
I've a ton of build scripts/makefiles with yacc, lex, awk, m4, esql, sqlj, and various custom source pre-processing steps. If you're dead set against a cpp phase, then I'd also like you to consider all those as well. Hmmm. That's what I thought. -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Sep 11 2002
"Richard Krehbiel" <rich kastle.com> wrote in message news:alnr7q$1iu$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:all4cc$2qfk$1 digitaldaemon.com..."Richard Krehbiel" <rich kastle.com> wrote in message news:alkre0$2fim$1 digitaldaemon.com...Why not just run a CPP tool on the D source before compiling it with
That'll take care of the #defined symbols (and, incidentally, the
for you.
That is certainly possible, but I personally want to leave the
behind and not perpetuate it.
I've a ton of build scripts/makefiles with yacc, lex, awk, m4, esql, sqlj, and various custom source pre-processing steps. If you're dead set
a cpp phase, then I'd also like you to consider all those as well. Hmmm. That's what I thought.
If you do want to preprocess D source, wouldn't one of those make a much better preprocessor than the C one? I am not so much against running D source through a preprocessor as I am opposed to making a particular preprocessor a defined part of the D language.
Sep 12 2002
Richard Krehbiel wrote:Why not just run a CPP tool on the D source before compiling it with D? That'll take care of the #defined symbols (and, incidentally, the #includes) for you.
The problem is, how do you convert #defines to consts? For example, all WM_* constants are #defined in winuser.h. Proper D version should use const. This means that translator has to look for #define, somehow figure out if it is a constant definition or a macro, and act appropriately.
Sep 10 2002
Walter wrote:"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3D78DDAF.6090201 deming-os.org...I have just downloaded Burt's Linux D port, and am starting on moving one of my projects over from C/C++ to D. The new project will be mixing C source (generated by Bison) with my D code. They communicate through some interface functions I'll define. I will need to include a .h file for the C code, and have a matching D module. But why not just include the C file? If I keep it such that it doesn't include an C specifics (like including other files, or using macros), then there's no reason you couldn't do this (from the D code): include (C) "c_to_d_interface.h"; which would be just like importing the .h file, except that all definitions there are given "extern (C)". Thoughts?
It's a great idea, and one I originally intended to implement. The downside is that every D compiler needs to contain within it a pretty complete C front end! While that's easy for me, since I have a C front end laying around <g>, it could make it difficult for others to build independent D implementations. So, instead my idea is to write a "C to D header translator" program, which is simply taking the C front end and bashing it so it emits the equivalent D declaration for each C declaration. I haven't written that yet, otherwise windows.d would be complete <g>.
No, that's not what I meant. What I meant is that the header would be a D source file, but only using the subset of features that C also supports. So you could get function definitions, structure declarations, etc. Most #defines can be replaced by const variables, anyhow.
Sep 09 2002