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?

"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>.

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?

"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.

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...

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.

"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)

"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.

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.

"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)