Thread overview
Conditional compilation: Which version identifier for release code ? version(assert) ?
Aug 05, 2021
wjoe
Aug 05, 2021
Mike Parker
Aug 05, 2021
wjoe
Aug 05, 2021
Mike Parker
Aug 06, 2021
wjoe
Aug 05, 2021
Adam D Ruppe
Aug 06, 2021
wjoe
August 05, 2021

If it's to be determined whether or not the code is being compiled in debug or release mode, i.e. e.g. the dmd -release or -g options, which version identifier is supposed to be used ?

There's no release identifier and -debug switch and debug() condition are something else.

There's assert - Checks are being emitted for AssertExpressions. With the exception for assert(0), those checks are omitted in release mode so this could be used for that purpose, right?

August 05, 2021

On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:

>

If it's to be determined whether or not the code is being compiled in debug or release mode, i.e. e.g. the dmd -release or -g options, which version identifier is supposed to be used ?

There's no release identifier and -debug switch and debug() condition are something else.

There's assert - Checks are being emitted for AssertExpressions. With the exception for assert(0), those checks are omitted in release mode so this could be used for that purpose, right?

I don't think it would make much sense to have a version(release), as there's really no such thing as a "release mode", or a "debug mode" either. -release is just a shorthand to disable certain features that you can also disable individually, and -debug means whatever you want it to mean.

Given that we have version(assert) and version(D_NoBoundsChecks), it probably makes sense to also have equivalents to test if contracts are enabled, or if bounds checking is enabled only in safe code. Then you'd be able to cover all the bases that -release does. Sounds like a candidate for an enhancement request.

August 05, 2021

On Thursday, 5 August 2021 at 10:08:12 UTC, Mike Parker wrote:

>

On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
Given that we have version(assert) and version(D_NoBoundsChecks), it probably makes sense to also have equivalents to test if contracts are enabled, or if bounds checking is enabled only in safe code. Then you'd be able to cover all the bases that -release does. Sounds like a candidate for an enhancement request.

Thanks, that helps a lot.

I agree about release and debug modes. It got stuck in my mind when I used Visual Studio years ago which, at least at the time, created a Debug and Release configuration by default.

Could you elaborate on version(assert) a bit more, please ? Like I compiled with -release, -g and without the 2 options but the assert branch was always taken. Could it be that -unittest has something to do with it ?

August 05, 2021
On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
> If it's to be determined whether or not the code is being compiled in debug or release mode, i.e. e.g. the dmd ```-release```

You should never use the -release flag. It should be renamed to "-enable-security-holes" since that's what it actually does.

Instead you can disable specific things as-needed, but.... it is probably never needed. These are also never supposed to actually change the behavior of your program, but in reality, like I said they do tend to change it - by enabling security holes.
August 05, 2021

On Thursday, 5 August 2021 at 10:43:01 UTC, wjoe wrote:

>

Could you elaborate on version(assert) a bit more, please ? Like I compiled with -release, -g and without the 2 options but the assert branch was always taken. Could it be that -unittest has something to do with it ?

Yes, -unittest overrides -release and enables asserts. -check=assert=off overrides both.

I agree with Adam about avoiding -release. -debug is useful. -release, not so much since we have finer control over enabling/disabling checks these days.

August 06, 2021

On Thursday, 5 August 2021 at 11:01:56 UTC, Adam D Ruppe wrote:

>

On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:

>

If it's to be determined whether or not the code is being compiled in debug or release mode, i.e. e.g. the dmd -release

You should never use the -release flag. It should be renamed to "-enable-security-holes" since that's what it actually does.

This is good advice. Actually I had no intention to use the -release option.
My question was aimed at getting an understanding of the different version identifiers and how they are affected by the command line options in order to be able to pick one that reflects the users expectations.
My wording should have been better. Sorry for the confusion.

>

Instead you can disable specific things as-needed, but.... it is probably never needed. These are also never supposed to actually change the behavior of your program, but in reality, like I said they do tend to change it - by enabling security holes.

However isn't the point of using version identifiers and these options to actually change the behavior of the program ?
I mean if bounds checking is enabled I expect the program to behave differently, i.e. to abort if something is out of bounds.

August 06, 2021

On Thursday, 5 August 2021 at 11:54:38 UTC, Mike Parker wrote:

>

On Thursday, 5 August 2021 at 10:43:01 UTC, wjoe wrote:

>

Could you elaborate on version(assert) a bit more, please ? Like I compiled with -release, -g and without the 2 options but the assert branch was always taken. Could it be that -unittest has something to do with it ?

Yes, -unittest overrides -release and enables asserts. -check=assert=off overrides both.

It is sort of embarassing reading this after one night's sleep.
But the lesson learned was well worth it, thanks :)

So in light of all of this what I was looking for is D_NoBoundsChecks which you mentioned initially.