www.digitalmars.com         C & C++   DMDScript  

D - Idea: "include" as "import" with automatic "extern"

reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
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
parent reply "Walter" <walter digitalmars.com> writes:
"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
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
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
parent reply "Walter" <walter digitalmars.com> writes:
"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
next sibling parent Pavel Minayev <evilone omen.ru> writes:
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
prev sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"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
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"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
parent "Walter" <walter digitalmars.com> writes:
"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
prev sibling parent Pavel Minayev <evilone omen.ru> writes:
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
prev sibling parent Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
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