On Wednesday, 15 October 2014 at 14:47:33 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 15 October 2014 at 14:25:43 UTC, Dicebot wrote:
>> How can one continue without recovering? This will result in any kind of environment not being cleaned and false failures of other tests that share it.
>
> fork()?

http://check.sourceforge.net/doc/check_html/check_2.html

"Writing a framework for C requires solving some special problems that frameworks for Smalltalk, Java or Python don’t have to face. In all of those language, the worst that a unit test can do is fail miserably, throwing an exception of some sort. In C, a unit test is just as likely to trash its address space as it is to fail to meet its test requirements, and if the test framework sits in the same address space, goodbye test framework.

To solve this problem, Check uses the fork() system call to create a new address space in which to run each unit test, and then uses message queues to send information on the testing process back to the test framework. That way, your unit test can do all sorts of nasty things with pointers, and throw a segmentation fault, and the test framework will happily note a unit test error, and chug along. "

On Wednesday, 15 October 2014 at 03:18:31 UTC, Walter Bright wrote:
>
> However, the compiler is still going to regard the assert() as nothrow, so the unwinding from an Exception won't happen until up stack a throwing function is encountered.

I hate to say it, but I'm inclined to treat nothrow the same as in C++, which is to basically pretend it's not a part of the language. The efficiency is nice, but not if it means that throwing an Error will cause the program to be invalid.  Please tell me there's no plan to change the unwinding behavior when Error is thrown in standard (ie not nothrow) code.

I touched on all this in my "on errors" thread that seems to have died. I suppose I could write a DIP but I was hoping for discussion.

Hi,every one!
How can I realize mathematical rounding (not banking) for Double in D
0.4 -> 0
0.5 -> 1
1.5 -> 2
2.5 -> 3
3.5 -> 4  ?

Thank you.

On 10/15/14, 8:11 PM, Elena wrote:
> Hi,every one!
> How can I realize mathematical rounding (not banking) for Double in D
> 0.4 -> 0
> 0.5 -> 1
> 1.5 -> 2
> 2.5 -> 3
> 3.5 -> 4  ?
>
> Thank you.

Add 0.5 and then cast to integral. -- Andrei

On Thursday, 16 October 2014 at 03:11:57 UTC, Elena wrote:
> Hi,every one!
> How can I realize mathematical rounding (not banking) for

Never used it, but:

http://dlang.org/library/std/math/FloatingPointControl.html

phobos/math.d lists the enums:

roundToNearest, roundDown, roundUp, roundToZero

On 2014-10-15 16:25, Dicebot wrote:

> How can one continue without recovering? This will result in any kind of
> environment not being cleaned and false failures of other tests that
> share it.

I will probably use something else than "assert" in my unit tests. Something like assertEq, assertNotEq and so on. It's more flexible, can give better error message and I can have it throw an exception instead of an error. But there's still the problem with asserts in contracts and other parts of the code.

-- 
/Jacob Carlborg

On Thursday, 16 October 2014 at 05:24:23 UTC, Andrei Alexandrescu wrote:
> On 10/15/14, 8:11 PM, Elena wrote:
>> Hi,every one!
>> How can I realize mathematical rounding (not banking) for Double in D
>> 0.4 -> 0
>> 0.5 -> 1
>> 1.5 -> 2
>> 2.5 -> 3
>> 3.5 -> 4  ?
>>
>> Thank you.
>
> Add 0.5 and then cast to integral. -- Andrei

This would be the "round half up" mode that produce 0 for -0.5:

floor(x+0.5)

Whereas "round nearest" should produce -1 for -0.5:

floor(abs(x)+0.5)*sgn(x)

On 10/15/2014 7:25 AM, Dicebot wrote:
> How can one continue without recovering? This will result in any kind of
> environment not being cleaned and false failures of other tests that share it.

Unittest asserts are top level - they shouldn't need recovering from (i.e. unwinding). Just continuing.

On 10/15/2014 7:35 AM, Dan Olson wrote:
> That is what I am looking for, just being able to continue from a failed
> assert in a unittest.

Just use enforce() or something similar instead of assert(). Nothing says you have to use assert() in a unittest.

On 10/15/2014 6:54 PM, Sean Kelly wrote:
> I hate to say it, but I'm inclined to treat nothrow the same as in C++, which is
> to basically pretend it's not a part of the language. The efficiency is nice,
> but not if it means that throwing an Error will cause the program to be
> invalid.  Please tell me there's no plan to change the unwinding behavior when
> Error is thrown in standard (ie not nothrow) code.

Don't throw Errors when you need to unwind. Throw Exceptions. I.e. use enforce() instead of assert().