Hello,
I've got following problem :
I've used c++ preprocessor for function prototyping, eg.

#define DO_MY_FUNCTION(name, type) int name(type t, type t2)

DO_MY_FUNCTION(f1, int) {
}
..

if you ask why - i got simple interpreted language written, and these prototypes were used
as internal functions, and the order or types of parameters should vary between versions.

is there any chance to write code like this in D?

-- 
Tato zpráva byla vytvořena převratným poštovním klientem Opery: http://www.opera.com/mail/

Yossarian wrote:
> Hello,
> I've got following problem :
> I've used c++ preprocessor for function prototyping, eg.
> 
> #define DO_MY_FUNCTION(name, type) int name(type t, type t2)
> 
> DO_MY_FUNCTION(f1, int) {
> }
> ..
> 
> if you ask why - i got simple interpreted language written, and these  prototypes were used
> as internal functions, and the order or types of parameters should vary  between versions.
> 
> is there any chance to write code like this in D?
> 

You can using mixins, but it looks ugly, you end up with something like:

template DoMyFunction(char[] Name, char[] Type, char [] Body) {
    const char[] DoMyFunction = "int " ~ Name ~ "(" ~ Type ~ " " ~ Name ~ ", " ~ Type ~ " " ~ Name ~ ") {" ~ Body ~ "}";
}

mixin(DoMyFunction!("f1", "int", "
	// function body
"));

Mixins are great, but in no way a replacement for the C preprocessor.  I think it was a big mistake to not include preprocessing as well.

Tim Burrell:
> Mixins are great, but in no way a replacement for the C preprocessor.  I think it was a big mistake to not include preprocessing as well.

The C preprocessor is powerful, but it's a source of many problems too. I presume that D AST macros will solve most of those problems (and they will create other problems: macros are a Pandora's jar).

Bye,
bearophile

bearophile wrote:
> Tim Burrell:
>> Mixins are great, but in no way a replacement for the C preprocessor.  I think it was a big mistake to not include preprocessing as well.
> 
> The C preprocessor is powerful, but it's a source of many problems too. I presume that D AST macros will solve most of those problems (and they will create other problems: macros are a Pandora's jar).

It's true it can cause problems.  Still sometimes it'd just be really nice to be able to make some simple #define's -- even if just to help porting code.

At any rate, I think you're right, the AST macros look like they should do the trick for the most part.

Tim Burrell wrote:
> Mixins are great, but in no way a replacement for the C preprocessor.  I think it was a big mistake to not include preprocessing as well.

It's not like a preprocessor could not be used separately... It might not be standard, D-wise, but most non-trivial software has a complex build process.

Preprocessing a single specific file in a project is much lesser a sin than including a standard preprocessing stage in the compiler, IMHO.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Tom S wrote:
> Tim Burrell wrote:
>> Mixins are great, but in no way a replacement for the C preprocessor.  I think it was a big mistake to not include preprocessing as well.
> 
> It's not like a preprocessor could not be used separately... It might not be standard, D-wise, but most non-trivial software has a complex build process.
> 
> Preprocessing a single specific file in a project is much lesser a sin than including a standard preprocessing stage in the compiler, IMHO.

Yeah it's definitely true.  And I know this... it's just more work to set up a separate preprocessing tool, adds another project dependency, etc.  For the kind of things I'd want to use a preprocessor for (super quick and simple search and replace style defines) adding a whole preprocessor is way overkill.

The problem with the C preprocessor is it became too powerful, and can lead to some bad design choices -- stuff that's hard to maintain, port, comprehend, etc.  I can see why it was left out.

But, its original intent was sound, and I think it could be possible to include a preprocessing step that doesn't allow for easy obfuscation of code, or crazy code block bugs (anyone remember the while(0) hack?).  I don't think it would be a sin at all to include a safe and modified subset of a C style preprocessor to D.  Although I realize that's never going to happen, so it's probably pointless to bother thinking about :).

Either way, as bearophile suggested, I think the AST macros should do the trick (I wasn't ware of them when I made my initial reply), so no worries.

Tim Burrell wrote:
> Tom S wrote:

> But, its original intent was sound, and I think it could be possible to include a preprocessing step that doesn't allow for easy obfuscation of code, or crazy code block bugs (anyone remember the while(0) hack?).  I don't think it would be a sin at all to include a safe and modified subset of a C style preprocessor to D.  Although I realize that's never going to happen, so it's probably pointless to bother thinking about :).

That's pretty much exactly the idea behind AST macros.

> Either way, as bearophile suggested, I think the AST macros should do the trick (I wasn't ware of them when I made my initial reply), so no worries.

Yep.

--bb