Boost logo

Boost :

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
+44 1539561830 & SMS, Mobile +44 7714 330204 & SMS
pbristow_at_[hidden]
 

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk