www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to make invariant switchable

reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Hi All,

"invariant" is a great language feature of D. But nice thing costs. 

Is it possible to make it compiler switchable? Like "dmd --ignore-invariant"
or "dmd --version=ignore-invariant" It think it will be quite helpful to
generate test version and release version of software.


Best regards
Qian Xu
Jun 18 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Qian Xu Wrote:


 Hi All,
 
 "invariant" is a great language feature of D. But nice thing costs. 
 
 Is it possible to make it compiler switchable? Like "dmd --ignore-invariant"
 or "dmd --version=ignore-invariant" It think it will be quite helpful to
 generate test version and release version of software.
 
 
 Best regards
 Qian Xu


"dmd -release" will ignore invariants. You can also wrap your invariants inside
of debug{} or similar.
Jun 18 2009
parent reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Jason House wrote:


 Qian Xu Wrote:
 

 Hi All,
 
 "invariant" is a great language feature of D. But nice thing costs.
 
 Is it possible to make it compiler switchable? Like "dmd
 --ignore-invariant" or "dmd --version=ignore-invariant" It think it will
 be quite helpful to generate test version and release version of
 software.
 
 
 Best regards
 Qian Xu


 
 "dmd -release" will ignore invariants. You can also wrap your invariants
 inside of debug{} or similar.


Thanks for the hint.

BTW: is assertion switchable as well? I put some assertions outside of
invariant-block, it will be executed, when my program is compiled in
release mode.
Jun 18 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 18 Jun 2009 16:57:47 +0400, Qian Xu <quian.xu stud.tu-ilmenau.de>  
wrote:


 Jason House wrote:


 Qian Xu Wrote:


 Hi All,

 "invariant" is a great language feature of D. But nice thing costs.

 Is it possible to make it compiler switchable? Like "dmd
 --ignore-invariant" or "dmd --version=ignore-invariant" It think it  
 will
 be quite helpful to generate test version and release version of
 software.


 Best regards
 Qian Xu


 "dmd -release" will ignore invariants. You can also wrap your invariants
 inside of debug{} or similar.


 Thanks for the hint.

 BTW: is assertion switchable as well? I put some assertions outside of
 invariant-block, it will be executed, when my program is compiled in
 release mode.


No, they wont.
Jun 18 2009
parent reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Denis Koroskin wrote:

 
 No, they wont.


Is there any reason for that?
Jun 18 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 18 Jun 2009 17:09:12 +0400, Qian Xu <quian.xu stud.tu-ilmenau.de>  
wrote:


 Denis Koroskin wrote:

 No, they wont.


 Is there any reason for that?


I dont know. I'd prefer to write


 debug assert(foo == bar, "foo must be equal to bar");


if I'd like to turn them off in release mode.
Jun 18 2009
parent reply Max Samukha <outer space.com> writes:
On Thu, 18 Jun 2009 17:12:25 +0400, "Denis Koroskin"
<2korden gmail.com> wrote:


On Thu, 18 Jun 2009 17:09:12 +0400, Qian Xu <quian.xu stud.tu-ilmenau.de>  
wrote:


 Denis Koroskin wrote:

 No, they wont.


 Is there any reason for that?


I dont know. I'd prefer to write


 debug assert(foo == bar, "foo must be equal to bar");


if I'd like to turn them off in release mode.


'debug' is not necessary in most cases because asserts are removed
from release builds unless the assert condition is known to be false
at compile time, in which case a hlt instruction is generated for the
assert in release mode.
Jun 18 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 18 Jun 2009 17:46:37 +0400, Max Samukha <outer space.com> wrote:


 On Thu, 18 Jun 2009 17:12:25 +0400, "Denis Koroskin"
 <2korden gmail.com> wrote:


 On Thu, 18 Jun 2009 17:09:12 +0400, Qian Xu  
 <quian.xu stud.tu-ilmenau.de>
 wrote:


 Denis Koroskin wrote:

 No, they wont.


 Is there any reason for that?


 I dont know. I'd prefer to write


 debug assert(foo == bar, "foo must be equal to bar");


 if I'd like to turn them off in release mode.


 'debug' is not necessary in most cases because asserts are removed
 from release builds unless the assert condition is known to be false
 at compile time, in which case a hlt instruction is generated for the
 assert in release mode.


You must have misunderstood my post.

I know that asserts are removed in release mode. Why question was, why  
they are removed?
I responded that I personally see no reason in removing them in release  
mode.
I wrote that if I were to remove my asserts in release, I would prepend  
them with "debug":

debug assert(condition, errorMessage);
Jun 18 2009
parent reply Max Samukha <outer space.com> writes:
On Thu, 18 Jun 2009 19:28:41 +0400, "Denis Koroskin"
<2korden gmail.com> wrote:


On Thu, 18 Jun 2009 17:46:37 +0400, Max Samukha <outer space.com> wrote:


 On Thu, 18 Jun 2009 17:12:25 +0400, "Denis Koroskin"
 <2korden gmail.com> wrote:


 On Thu, 18 Jun 2009 17:09:12 +0400, Qian Xu  
 <quian.xu stud.tu-ilmenau.de>
 wrote:


 Denis Koroskin wrote:

 No, they wont.


 Is there any reason for that?


 I dont know. I'd prefer to write


 debug assert(foo == bar, "foo must be equal to bar");


 if I'd like to turn them off in release mode.


 'debug' is not necessary in most cases because asserts are removed
 from release builds unless the assert condition is known to be false
 at compile time, in which case a hlt instruction is generated for the
 assert in release mode.


You must have misunderstood my post.


Sorry, I understand now.


I know that asserts are removed in release mode. Why question was, why  
they are removed?
I responded that I personally see no reason in removing them in release  
mode.
I wrote that if I were to remove my asserts in release, I would prepend  
them with "debug":

debug assert(condition, errorMessage);


Why would you want to leave asserts in a release build while they are
supposed to be used for debugging?
Jun 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Max Samukha:

 Why would you want to leave asserts in a release build while they are
 supposed to be used for debugging?


If you look around on internet you will find lot of people that like to keep
assertions in the final programs too.
Is DMD itself compiled with asserts left inside? When DMD doesn't work if often
spits out a file + line number that I think come from an assert.

Bye,
bearophile
Jun 18 2009
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
bearophile wrote:

 Max Samukha:

 Why would you want to leave asserts in a release build while they are
 supposed to be used for debugging?


 
 If you look around on internet you will find lot of people that like to keep
assertions in the final programs too.
 Is DMD itself compiled with asserts left inside? When DMD doesn't work if
often spits out a file + line number that I think come from an assert.
 
 Bye,
 bearophile



For assertions that are meant only for debugging, use assert (...). For 
assertions that should also be included in a release build, use 
enforce(...) from the std.contracts module.

-Lars
Jun 18 2009
prev sibling parent reply Max Samukha <outer space.com> writes:
On Thu, 18 Jun 2009 13:43:22 -0400, bearophile
<bearophileHUGS lycos.com> wrote:


Max Samukha:

 Why would you want to leave asserts in a release build while they are
 supposed to be used for debugging?


If you look around on internet you will find lot of people that like to keep
assertions in the final programs too.
Is DMD itself compiled with asserts left inside? When DMD doesn't work if often
spits out a file + line number that I think come from an assert.

Bye,
bearophile


You have a point. With current dmd, you can include unittests in the
release build. So why not asserts? But I don't think it's a good
solution to force people who don't want asserts in a final product to
prepend each and every assert with 'debug'. For assertions that should
stay in production, use 'if' conditions in D1 or std.contracts.enforce
in D2. Anyway, it would be nice to have a switch to retain debug
assertions in the release build.
Jun 19 2009
parent reply Christian Kamm <see-ldc-commits repository.com> writes:
Max Samukha Wrote:

 You have a point. With current dmd, you can include unittests in the
 release build. So why not asserts? But I don't think it's a good
 solution to force people who don't want asserts in a final product to
 prepend each and every assert with 'debug'. For assertions that should
 stay in production, use 'if' conditions in D1 or std.contracts.enforce
 in D2. Anyway, it would be nice to have a switch to retain debug
 assertions in the release build. 


LDC has the -enable-* and -disable-* command line options for asserts, array
bounds checking, invariants and contracts to allow fine grained control over
what is emitted and what isn't.
Jun 19 2009
next sibling parent Christian Kamm <see-ldc-commits repository.com> writes:
Christian Kamm Wrote:

 LDC has the -enable-* and -disable-* command line options for asserts, array
bounds 
 checking, invariants and contracts to allow fine grained control over what is
emitted and 
 what isn't.


Ah, Jarrett had already pointed that out. Anyway, what I meant to say was that
adding 
these switches was pretty easy: as far as I remember the frontend already has
individual 
options for switching the debugging aids on and off individually. So if you
want this in DMD, 
make an enhancement request and append a patch. 

Unless Walter has fundamental reservations, getting it into the reference
compiler (preferably
using the same flags LDC uses) would be nice.
Jun 19 2009
prev sibling parent Max Samukha <outer space.com> writes:
On Fri, 19 Jun 2009 05:31:14 -0400, Christian Kamm
<see-ldc-commits repository.com> wrote:


Max Samukha Wrote:

 You have a point. With current dmd, you can include unittests in the
 release build. So why not asserts? But I don't think it's a good
 solution to force people who don't want asserts in a final product to
 prepend each and every assert with 'debug'. For assertions that should
 stay in production, use 'if' conditions in D1 or std.contracts.enforce
 in D2. Anyway, it would be nice to have a switch to retain debug
 assertions in the release build. 


LDC has the -enable-* and -disable-* command line options for asserts, array
bounds checking, invariants and contracts to allow fine grained control over
what is emitted and what isn't.


Nice! No support for D2, sadly
Jun 19 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Jun 18, 2009 at 8:57 AM, Qian Xu<quian.xu stud.tu-ilmenau.de> wrote:

 Jason House wrote:


 Qian Xu Wrote:


 Hi All,

 "invariant" is a great language feature of D. But nice thing costs.

 Is it possible to make it compiler switchable? Like "dmd
 --ignore-invariant" or "dmd --version=ignore-invariant" It think it will
 be quite helpful to generate test version and release version of
 software.


 Best regards
 Qian Xu


 "dmd -release" will ignore invariants. You can also wrap your invariants
 inside of debug{} or similar.


 Thanks for the hint.

 BTW: is assertion switchable as well? I put some assertions outside of
 invariant-block, it will be executed, when my program is compiled in
 release mode.


All the debugging features are optional.  Using -release turns of not
only invariant{} but also in{} and out{} contracts, assert(), and
array bounds checking.  DMD doesn't provide any more fine-grained
support for these, but LDC allows you to turn each of them on or off
individually.
Jun 18 2009
prev sibling parent reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Release and Debug are two configuration sets. 

 FEATURE       | DEBUG | RELEASE
---------------+-------+---------
 assertion     |       |
---------------+-------+---------
 invariant     |       |
---------------+-------+---------
 debug symbols |       |
---------------+-------+---------
 optimization  |       |
---------------+-------+---------
 inline        |       |
---------------+-------+---------
 more...       |       |


It is also inconvient to switch "invariant" (or debug features) with a
universal "-release" flag.
Jun 18 2009
parent Jason House <jason.james.house gmail.com> writes:
Qian Xu Wrote:


 Release and Debug are two configuration sets. 
 
  FEATURE       | DEBUG | RELEASE
 ---------------+-------+---------
  assertion     |       |
 ---------------+-------+---------
  invariant     |       |
 ---------------+-------+---------
  debug symbols |       |
 ---------------+-------+---------
  optimization  |       |
 ---------------+-------+---------
  inline        |       |
 ---------------+-------+---------
  more...       |       |
 
 
 It is also inconvient to switch "invariant" (or debug features) with a
 universal "-release" flag. 


No.

They're not as universal as you think.
-release disables invariant, array bounds checking, etc...
-debug enables debug statements
-inline enables inlining
-O performs optimizations
-g enables debug symbols
-unittest enables unit tests

These posts should be on d.learn...
Jun 18 2009