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,




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?


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,




 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?


 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


#includes)

 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


 #includes)

 for you.


 That is certainly possible, but I personally want to leave the


preprocessor

 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






D?

 That'll take care of the #defined symbols (and, incidentally, the


 #includes)

 for you.


 That is certainly possible, but I personally want to leave the


 preprocessor

 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.


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