Better assert's status? (Was: Proposal for std.path replacement)

Nick Sabalausky a at a.a
Tue Mar 8 00:25:03 PST 2011


"Nick Sabalausky" <a at a.a> wrote in message 
news:il3tra$3gg$1 at digitalmars.com...
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
> news:mailman.2328.1299539399.4748.digitalmars-d at puremagic.com...
>> On Monday, March 07, 2011 12:43:00 Nick Sabalausky wrote:
>>> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
>>> news:mailman.2297.1299478837.4748.digitalmars-d at puremagic.com...
>>>
>>> > On Sunday 06 March 2011 21:57:30 Nick Sabalausky wrote:
>>>
>>> Yea, that's what I figured, and that's why I was strongly in favor of
>>> assertPred despite the "promise" of assert improvements.
>>>
>>> You're the sole author of assertPred, right? Do you mind if I include it 
>>> in
>>> my zlib/libpng-licensed SemiTwist D Tools library (
>>> http://www.dsource.org/projects/semitwist ) ? I already have an
>>> assert-alternative in there, but assertPred is vastly superior. 
>>> (Although,
>>> my assert-alternative does save a list of failures instead of 
>>> immediately
>>> throwing, which I personally find to be essential for unittests, so I 
>>> would
>>> probably add the *optional* ability to have assertPred do the same.)
>>
>> Yes. I'm the sole author. Feel free to re-use it. It's under Boost, so 
>> you can
>> use it for whatever Boost lets you do with it, and even if what you're 
>> doing
>> isn't Boost compatible, it's fine with me if you use it anyway.
>>
>
> Thanks.
>

I've added it and made an optional 'autoThrow' flag that, if set to false, 
prevents a failure from immediately bailing out of the whole unittest (some 
people like that, like me, and others don't).

http://www.dsource.org/projects/semitwist/changeset?new=%2F%40196&old=%2F%40193





More information about the Digitalmars-d mailing list