www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Unconditional compilation?

reply John C <johnch_atms hotmail.com> writes:
Code in version blocks must be syntactically correct even if the 
condition is not met and the code isn't compiled - ie, the compiler 
still parses the code. But this makes writing libraries that compile 
with both D1 and D2 difficult - I want to add features for D2 users 
without having to distribute a separate version of the library.

version(D_Version2) {
   struct SomeStruct {

     // D2 copy ctor
     this(this) {}

   }
}

D1 chokes on that, which is expected behaviour according to the spec. 
But how do I get the same behaviour as #if and #else - ie, tell the 
compiler to completely ignore anything if some condition is not met?
Mar 09 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
John C wrote:

 Code in version blocks must be syntactically correct even if the 
 condition is not met and the code isn't compiled - ie, the compiler 
 still parses the code. But this makes writing libraries that compile 
 with both D1 and D2 difficult - I want to add features for D2 users 
 without having to distribute a separate version of the library.
 
 version(D_Version2) {
   struct SomeStruct {
 
     // D2 copy ctor
     this(this) {}
 
   }
 }
 
 D1 chokes on that, which is expected behaviour according to the spec. 
 But how do I get the same behaviour as #if and #else - ie, tell the 
 compiler to completely ignore anything if some condition is not met?


String mixin.  Not pretty, but it works.

--bb
Mar 09 2008
parent reply John C <johnch_atms hotmail.com> writes:
Bill Baxter wrote:

 John C wrote:

 Code in version blocks must be syntactically correct even if the 
 condition is not met and the code isn't compiled - ie, the compiler 
 still parses the code. But this makes writing libraries that compile 
 with both D1 and D2 difficult - I want to add features for D2 users 
 without having to distribute a separate version of the library.

 version(D_Version2) {
   struct SomeStruct {

     // D2 copy ctor
     this(this) {}

   }
 }

 D1 chokes on that, which is expected behaviour according to the spec. 
 But how do I get the same behaviour as #if and #else - ie, tell the 
 compiler to completely ignore anything if some condition is not met?


 
 String mixin.  Not pretty, but it works.
 
 --bb


Feared as much.

I'm wondering what the point is in having a version block's syntax 
checked when the code it contains isn't compiled.
Mar 09 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 09 Mar 2008 14:50:03 +0100, John C <johnch_atms hotmail.com> wro=
te:


 Bill Baxter wrote:

 John C wrote:

 Code in version blocks must be syntactically correct even if the  =







 condition is not met and the code isn't compiled - ie, the compiler =






 =


 still parses the code. But this makes writing libraries that compile=






  =


 with both D1 and D2 difficult - I want to add features for D2 users =






 =


 without having to distribute a separate version of the library.

 version(D_Version2) {
   struct SomeStruct {

     // D2 copy ctor
     this(this) {}

   }
 }

 D1 chokes on that, which is expected behaviour according to the spec=






.  =


 But how do I get the same behaviour as #if and #else - ie, tell the =






 =


 compiler to completely ignore anything if some condition is not met?=







  String mixin.  Not pretty, but it works.
  --bb


 Feared as much.

 I'm wondering what the point is in having a version block's syntax  =



 checked when the code it contains isn't compiled.


Simple answer to that is it might get compiled some other time, and  =

whoever uses your code at that time would probably not enjoy being bitte=
n  =

by such errors.
Say you change some version'd part of your code, and forget to check it =
 =

for bugs (you've compiled it, it works, life's great, but you forgot tha=
t  =

small version=3Dfoo flag).

-- Simen
Mar 09 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Simen Kjaeraas wrote:

 Simple answer to that is it might get compiled some other time, and 
 whoever uses your code at that time would probably not enjoy being 
 bitten by such errors.
 Say you change some version'd part of your code, and forget to check it 
 for bugs (you've compiled it, it works, life's great, but you forgot 
 that small version=foo flag).
 
 -- Simen


Continuous integration is great. I should see what's required to get 
CruiseControl working and happy with D. It should be relatively easy if 
you use DSSS, except if you have multiple targets or platforms. Multiple 
targets is doable, but requires parsing the dsss.conf file. Multiple 
platforms is doable, but you'd have to arrange for separate dmd/gcc 
installations and enumerate them somewhere. Maybe separate DSSS 
installations, since you can't (as far as I could tell after about five 
minutes of searching) specify which rebuild profile to use on the 
command line.
Mar 09 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Christopher Wright wrote:

 I should see what's required to get
 CruiseControl working and happy with D.


That would be much appreciated, I find CruiseControl very useful!
Mar 09 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
John C wrote:

 I'm wondering what the point is in having a version block's syntax 
 checked when the code it contains isn't compiled.


Unambiguous parsing. One of the main goals of the D language AFAIK is to 
make  the syntactic analysis independent of the semantic analysis (one 
of the things that makes C++ so hard to compile). Thus, the syntax tree 
for the code must be able to built without knowing which version 
identifiers are active.
Mar 09 2008
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 09 Mar 2008 11:22:29 +0000, John C wrote:


 Code in version blocks must be syntactically correct even if the 
 condition is not met and the code isn't compiled - ie, the compiler 
 still parses the code. But this makes writing libraries that compile 
 with both D1 and D2 difficult - I want to add features for D2 users 
 without having to distribute a separate version of the library.
 
 version(D_Version2) {
    struct SomeStruct {
 
      // D2 copy ctor
      this(this) {}
 
    }
 }
 
 D1 chokes on that, which is expected behaviour according to the spec. 
 But how do I get the same behaviour as #if and #else - ie, tell the 
 compiler to completely ignore anything if some condition is not met?


You need to use string mixins.

For example ...

 version(D_Version2) {
    mixin(
    `struct SomeStruct {`
      // D2 copy ctor
    `  this(this) {}`
    `}`
    );
 }

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Mar 09 2008