Re: [boost] [test] BOOST_CHECK_NOT_EQUAL wanted

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-09-08 10:34:32

>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Gennadiy Rozental
>Sent: 30 August 2007 21:37
>To: boost_at_[hidden]
>Subject: Re: [boost][test] BOOST_CHECK_NOT_EQUAL wanted
>
>Kevin Sopp <baraclese <at> googlemail.com> writes:
>
>> 
>> On 8/30/07, Gennadiy Rozental <rogeeff <at> gmail.com> wrote:
>> > There are way to many predicates out there to introduce 
>direct library 
>support
>> > for each one. The recomendation is to use generic 
>predicate support 
>instead.
>> 
>> There are only 5 more comparison operators defined by the language:
>> less, less equal, greater, greater equal and not equal. Maybe it is
>> possible to make it easier to add these, I see there is some
>> complexity involved by looking at the code.
>
>There is not much complexity, but it's tedios from proper 
>error reporting 
>prospective.
> 
>> It makes a whole lot of sense to add the complementary
>> BOOST_CHECK_NOT_EQUAL - even if it's just for symmetric reasons.
>
>What's wrong with solutions I proposed?
>
>You can always do this in your code: 
>
>#define CHECK_NOT_EQ( a, b ) BOOST_CHECK_PREDICATE( _1 != _2, (a)(b))

Gennadiy is quite right to say that knowing the values that fail is *very* useful.

But I strongly disagree that there are 'way too many' possible.

Surely these can *all* be provided like

#define BOOST_CHECK_NOT_EQ( a, b ) BOOST_CHECK_PREDICATE( _1 != _2, (a)(b))

Together with any necessary #includes to make it work.

And save work for the users who are trying to concentrate on their testing, not re-writing macros.

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]