test for lib.alg.transform

[Anton Pevtsov <an...@moscow.vdiweb.com>]

The attached file contains my attempt to update lib.alg.transform tests
and port it to new test driver.

With best wishes,
Anton Pevtsov

Re: test for lib.alg.transform

[Martin Sebor <se...@roguewave.com>]

Anton Pevtsov wrote:
> The attached file contains my attempt to update lib.alg.transform tests
> and port it to new test driver.

I must admit I was a little bit confused by all the tags and the
recursion (it actually took me until today to figure out what the
test was doing! :) I decided to introduce a number of convenience
variables to make the test easier to read and finally got it! :)
There sure is a lot of "boilerplate" code just to set things up,
but I suppose it's necessary in order to exercise the algorithm
exhaustively.

I wasn't quite happy about the function objects providing dummy
operators just to be compatible with one another so I introduced
a template overload to get around this kludge and removed the dummy
operators. Btw., the ctors for the function objects need to take at
least 2 (dummy) arguments in order not to be default constructible
or constructible from an int.

Here's what I committed:
   http://svn.apache.org/viewcvs.cgi?rev=372585&view=rev

Btw., I think I should clarify one point I made recently about using
"advanced" C++ features such as member templates (for some reason I
thought they could have come in handy in this test). It's okay to use
member templates (and other handy C++ features) if it makes it easier
to exhaustively exercise the library as long as we also have a fallback
mechanism in place that doesn't depend on the feature. This fallback
solution need not be as robust as the main one (see, for example, what
I did in random_shuffle to exercise STDCXX-126). In summary, if it's
easy to avoid these features we should, but we shouldn't compromise
the strictness of our testsuite to accommodate old compilers.

Martin