www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Mixin versus c++ preprocessor?

reply Yossarian <xtauer01 stud.fit.vutbr.cz> writes:
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/
Mar 21 2008
parent reply Tim Burrell <tim timburrell.net> writes:
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.
Mar 21 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Mar 21 2008
parent Tim Burrell <tim timburrell.net> writes:
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.
Mar 21 2008
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
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
Mar 21 2008
parent reply Tim Burrell <tim timburrell.net> writes:
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.
Mar 22 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Mar 22 2008