tests compilation time

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

Martin Sebor wrote:
> Incidentally, the test takes very long to compile
[...]
> One idea might be factor all the code that inevitably must be
iterator- and algorithm-specific to a small helper template derived from
an ordinary (non-template) base class, construct an object of > the
appropriate derived type in the function that sets up all the template
arguments (i.e., the types of the iterators and the algorithm to test),
and pass this object by reference to the base class > in the test
function.

I've tried this way in the lib.set.union test but had no luck: I faced
with the problem of the iterator type retrieving by the given constant
(It is possible to hardcode all 64 possible iterators permutations and
avoid the problem, but will this make sense?). So, I am not sure that I
cought your idea above (did you mean something like traits class?). 
Could you explain your approach or provide some example, please?

Anyway I'll continue my attempts to reduce the test compilation time.

Thanks,
Anton Pevtsov

Re: tests compilation time

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

Anton Pevtsov wrote:
[...]
> I've tried this way in the lib.set.union test but had no luck: I faced
> with the problem of the iterator type retrieving by the given constant
> (It is possible to hardcode all 64 possible iterators permutations and
> avoid the problem, but will this make sense?). So, I am not sure that I
> cought your idea above (did you mean something like traits class?). 
> Could you explain your approach or provide some example, please?

I committed the change below to the 25.merge.cpp test that shows what
I have in mind. As the ChangeLog mentions the results are quite good
which confirms that it's a good strategy going forward. I admit that
I spent way more time on it than I would have liked (about 4 hours)
which makes me question whether it's worth rewriting the tests you
have already ported.

   http://svn.apache.org/viewcvs.cgi?rev=377817&view=rev

Martin