stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: test for lib.alg.fill
Date Tue, 29 Nov 2005 22:30:26 GMT
Anton Pevtsov wrote:
> The attached file contains my attempt to update the lib.alg.fill test.

Excellent, thanks! I've committed it with a few minor changes here:

> I have a question about fill_n test: is it necessary to implement a 
> separate test for the fill_n algorithm
> with our custom Size class?
> If so, this test may be updated - currently it just uses size_t.

You are right, that would be a useful enhancement. Size need only be
convertible to int, it need not actually support all the same operations
(such as postincrement). Let me open an issue to keep track of this
enhancement to the test.

In addition, let me clarify/correct what I said about removing the
explicit specializations in the post below. I'm afraid I missed one
important feature the explicit instantiations exercise that is not
also exercised by the test functions: the ability of the algorithms
to handle value types that strictly conform to the requirements in
the standard (i.e., that do not go beyond).

Specifically, the value type class X used in all these tests meets
all of the requirements of DefaultConstructible, CopyConstructible,
Assignable, EqualityComparable, and LessThanComparable, which is
more than is required by any one of the algorithms. Each test should
also verify that the tested algorithm doesn't make assumptions about
the value type beyond those imposed by the standard. This can only
be done reliably at compile time since simply checking the number
of invocations of the other member functions at runtime might miss
unwarranted assumptions made in code that doesn't actually get
evaluated by the algorithm. So unless class X is enhanced somehow
to allow us express this compile time constraint (the runtime
checking is there) we'll have to go back to the original explicit


View raw message