[test] BOOST_CHECK_NOT_EQUAL wanted
Hello, I found this old thread http://lists.boost.org/boost-users/2006/06/20028.php where it said bring up the issue again after 1.34 is released. I intuitively expected a BOOST_CHECK_NOT_EQUAL to exist and typed it in, but it wasn't there! So, here's one more person requesting macros for all comparison operators for the test tools. regards, Kevin Sopp
Kevin Sopp <baraclese <at> googlemail.com> writes:
Hello, I found this old thread http://lists.boost.org/boost-users/2006/06/20028.php where it said bring up the issue again after 1.34 is released.
I intuitively expected a BOOST_CHECK_NOT_EQUAL to exist and typed it in, but it wasn't there! So, here's one more person requesting macros for all comparison operators for the test tools.
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. Not equal check can be done either using STL functors by BOOST_CHECK_PREDICATE( not(equal_to), (a)(b) ) or using lambdas by BOOST_CHECK_PREDICATE( _1 != _2, (a)(b) ); Gennadiy
On 8/30/07, Gennadiy Rozental <rogeeff@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. It makes a whole lot of sense to add the complementary BOOST_CHECK_NOT_EQUAL - even if it's just for symmetric reasons. Kevin
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
Hi! Gennadiy Rozental schrieb:
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))
Yes, you can always do this. But libraries are to make things convenient. For my part I don't see any point in the new macro. I propse the use of BOOST_CHECK/BOOST_CHECK_MESSAGE: BOOST_CHECK( a != b ); The standard "assert" doesn't provide more either. And there would be an exponential number of combinations of warning level, optional message, and various kinds of operators. Unless these can be automatically generated I would resort to simple things as the above. Frank
"Frank Birbacher" <bloodymir.crap@gmx.net> wrote in message news:fb7kpn$or8$1@sea.gmane.org...
Hi!
Gennadiy Rozental schrieb:
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))
Yes, you can always do this. But libraries are to make things convenient.
For my part I don't see any point in the new macro. I propse the use of BOOST_CHECK/BOOST_CHECK_MESSAGE:
BOOST_CHECK( a != b );
The standard "assert" doesn't provide more either. And there would be an exponential number of combinations of warning level, optional message, and various kinds of operators. Unless these can be automatically generated I would resort to simple things as the above.
Actually my solution is preferable, since you will be able to see matched values (though on the other hand failed x != 5 condition doesn't need additional clarifications, but this is not the case for other checks we are discussing) Gennadiy
Gennadiy Rozental skrev:
"Frank Birbacher" <bloodymir.crap@gmx.net> wrote in message news:fb7kpn$or8$1@sea.gmane.org...
Hi!
Gennadiy Rozental schrieb:
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)) Yes, you can always do this. But libraries are to make things convenient.
For my part I don't see any point in the new macro. I propse the use of BOOST_CHECK/BOOST_CHECK_MESSAGE:
BOOST_CHECK( a != b );
The standard "assert" doesn't provide more either. And there would be an exponential number of combinations of warning level, optional message, and various kinds of operators. Unless these can be automatically generated I would resort to simple things as the above.
Actually my solution is preferable, since you will be able to see matched values
And that is exactly why the library should provide those shortcuts by default. -Thorsten
Thorsten Ottosen wrote:
Gennadiy Rozental skrev:
"Frank Birbacher" <bloodymir.crap@gmx.net> wrote in message news:fb7kpn$or8$1@sea.gmane.org...
Hi!
Gennadiy Rozental schrieb:
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)) Yes, you can always do this. But libraries are to make things convenient.
For my part I don't see any point in the new macro. I propse the use of BOOST_CHECK/BOOST_CHECK_MESSAGE:
BOOST_CHECK( a != b );
The standard "assert" doesn't provide more either. And there would be an exponential number of combinations of warning level, optional message, and various kinds of operators. Unless these can be automatically generated I would resort to simple things as the above.
Actually my solution is preferable, since you will be able to see matched values
And that is exactly why the library should provide those shortcuts by default.
Yes, please. I've been missing them for quite some time now. / Johan
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: 30 August 2007 21:37 To: boost@lists.boost.org 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
for each one. The recomendation is to use generic
direct library support 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@hetp.u-net.com
participants (6)
-
Frank Birbacher -
Gennadiy Rozental -
Johan Nilsson -
Kevin Sopp -
Paul A Bristow -
Thorsten Ottosen