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
next sibling 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
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 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 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 "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
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