You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Anton Pevtsov <an...@moscow.vdiweb.com> on 2006/01/26 17:30:24 UTC

test for lib.alg.unique

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

I noticed that the complexity for unique_copy is (last - first) - 1
applications of the predicate, but according to the standard it should
be exactly (last - first).
In other hand the complexity of the unique according to the standard
should be exactly (last - first) - 1. 

And I have a question: is the complexity (last  - first) - 1 correct 
for the unique_copy algorithm?

The current test vesrion suppose that (last  - first) - 1 is correct.


With best wishes,
Anton Pevtsov 


Re: test for lib.alg.unique

Posted by Martin Sebor <se...@roguewave.com>.
Anton Pevtsov wrote:
> The attached file contains my attempt to update lib.alg.unique tests and
> port them to new test driver.

I forgot to answer your question below:

> 
> I noticed that the complexity for unique_copy is (last - first) - 1
> applications of the predicate, but according to the standard it should
> be exactly (last - first).

Generally speaking, the complexity requirements are upper bounds and
implementations are allowed and encouraged to do better (see 17.3.1.3,
p5). That said, the use of the word "exactly" here does suggest that
the standard requires exactly that many applications of the predicate
and not less. Unless it's actually a bug in our implementation of the
algorithm (if it is, we should be able to produce a test case showing
that our unique() fails under some conditions), the word ought to be
be stricken from the standard.

> In other hand the complexity of the unique according to the standard
> should be exactly (last - first) - 1.
> And I have a question: is the complexity (last  - first) - 1 correct for 
> the unique_copy algorithm?

Unless you can come up with a situation where our unique fails to
satisfy any of the the other requirements it's correct. (I encourage
you to try! :) Btw., what do other implementations (gcc or MSVC) do?

Martin

Re: test for lib.alg.unique

Posted by Martin Sebor <se...@roguewave.com>.
Anton Pevtsov wrote:
> The attached file contains my attempt to update lib.alg.unique tests and
> port them to new test driver.

Looks good, thanks! I committed it with just a few minor modifications
mostly to improve the readability of the code with this change:
http://svn.apache.org/viewcvs.cgi?rev=372633&view=rev

A few points on the changes I madet to your version:

*  It helps to separate function arguments one per line whenever there
    are more than two or three of them; it also help to line up their
    names.

*  It helps to line up like local variables and their initializers,
    such as the iterators, to immediately see the differences between
    them.

*  It's not necessary to cast the arguments to the iterator ctors
    to the target type since the type is explicitly provided in the
    name of the iterator (e.g., InputIter<X> iter (0, 0, 0) is good
    enough).

*  It's important to end every statement with a semicolon on the
    same line. Specifically, a macro definition should not end with
    a semicolon so that the the semicolon can and must be supplied
    when invoking the macro. (Otherwise Emacs formatting gets messed
    up.)

*  It helps to introduce helper variables for complicated-looking
    repeatedly used expressions (such as InputIter<T>(0, 0, 0)).

*  Please avoid gratuitous spaces in expressions such as (T*)0.
    I.e., do not write "(T*) 0."

Thanks again!
Martin