void f() {
    // much code with many assert(0)
    assert(0, "where's my message, line and file?");
    // much code with many assert(0)
}

void main() {
    f();
}


object.Error: assert(0) or HLT instruction
----------------
assert_release.d(8): _Dmain
----------------

Is it possible to get file, line and message for assert(0)?

Works for me, 2.053 XP32:

core.exception.AssertError@testsassert.d(3): where's my message, line and file?

On 28.05.2011 17:56, Andrej Mitrovic wrote:
> Works for me, 2.053 XP32:
>
> core.exception.AssertError@testsassert.d(3): where's my message, line and file?

Compiling with -release?

On Sat, 28 May 2011 19:19:25 +0300, simendsjo <simen.endsjo@pandavre.com> wrote:

> On 28.05.2011 17:56, Andrej Mitrovic wrote:
>> Works for me, 2.053 XP32:
>>
>> core.exception.AssertError@testsassert.d(3): where's my message, line and file?
>
> Compiling with -release?

http://www.d-programming-language.org/expression.html#AssertExpression says:

The expression assert(0) is a special case; it signifies that it is unreachable code. Either AssertError is thrown at runtime if it is reachable, or the execution is halted (on the x86 processor, a HLT instruction can be used to halt execution). The optimization and code generation phases of compilation may assume that it is unreachable code.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

FTFY:

import std.exception;
void f() {
   // much code with many assert(0)
   enforce(0, "where's my message, line and file?");
   // much code with many assert(0)
}

void main() {
   f();
}

But the two are supposed to be used for different things.

On 28.05.2011 18:22, Vladimir Panteleev wrote:
> On Sat, 28 May 2011 19:19:25 +0300, simendsjo
> <simen.endsjo@pandavre.com> wrote:
>
>> On 28.05.2011 17:56, Andrej Mitrovic wrote:
>>> Works for me, 2.053 XP32:
>>>
>>> core.exception.AssertError@testsassert.d(3): where's my message, line
>>> and file?
>>
>> Compiling with -release?
>
> http://www.d-programming-language.org/expression.html#AssertExpression
> says:
>
> The expression assert(0) is a special case; it signifies that it is
> unreachable code. Either AssertError is thrown at runtime if it is
> reachable, or the execution is halted (on the x86 processor, a HLT
> instruction can be used to halt execution). The optimization and code
> generation phases of compilation may assume that it is unreachable code.
>

I don't think I understand the use case for assert(0) then.. I thought it was just a way getting assert in release mode.

On 2011-05-28 12:32:59 -0400, simendsjo <simen.endsjo@pandavre.com> said:

> I don't think I understand the use case for assert(0) then.. I thought it was just a way getting assert in release mode.

The use case for assert(0) is the same as any assert(whatever): checking for things that shouldn't happen. Normally compiling in release mode would strip all the asserts to make things slimmer and faster. But given there is no cost in checking for assert(0), those are not stripped, they are just replaced with a halt instruction. So the assert's still there, but you don't have a message for it nor the line number.

If you want to see where the assertion happens, you can either compile in non-release mode or you can hook a debugger to your release executable and wait for the assert to happen.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 28.05.2011 19:56, Michel Fortin wrote:
> On 2011-05-28 12:32:59 -0400, simendsjo <simen.endsjo@pandavre.com> said:
>
>> I don't think I understand the use case for assert(0) then.. I thought
>> it was just a way getting assert in release mode.
>
> The use case for assert(0) is the same as any assert(whatever): checking
> for things that shouldn't happen. Normally compiling in release mode
> would strip all the asserts to make things slimmer and faster. But given
> there is no cost in checking for assert(0), those are not stripped, they
> are just replaced with a halt instruction. So the assert's still there,
> but you don't have a message for it nor the line number.
>
> If you want to see where the assertion happens, you can either compile
> in non-release mode or you can hook a debugger to your release
> executable and wait for the assert to happen.
>

Thanks to both.

I got confused about by Vladimir's comment: "The optimization and code generation phases of compilation may assume that it is unreachable code."

I tested this now, and the compiler does indeed complain about unreachable code.

And the debugger also breaks, so it makes more sense now :)