Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-03-29 15:47:23


On Thu, 29 Mar 2001, Ullrich Koethe wrote:

koethe> Basic Vector
koethe>
koethe> x[i] vector_traits<X>::reference
koethe>
koethe> The requirement that basic_vector::operator[] returns an lvalue has

The Basic Vector concept as written does not require an lvalue return
type.

x[i] vector_traits<X>::reference, which must be a type convertible
            to the value type.
x[i] = a undefined return type

because nowhere did I say that vector_traits<X>::reference must be an
lvalue. I just said it needed to be convertible to the value type. If I
had made it an lvalue, then I wouldn't have needed to require the second
expression "x[i] = a".

koethe> Strictly speaking, you need it to check the constraints (at least those
koethe> that are exact), so it belongs into the concepts. In practice, leaving
koethe> it out would mean to introduce new categories
koethe> SomeAlgebraicConceptAndEqualityComparable - this sounds confusing. Are
koethe> there really algorithms that can work on SomeAlgebraicConcept for which
koethe> EqualityComparable cannot be implemented?

You don't really need to create these concatenated concepts. The algorithm
can just list multiple requirements.

Actually, to check the constraints, operator== is probably the wrong
choice anyways. It would be better to use some function, say equivalent().
For example, the overload of equivalent() for float's would return true if
the two numbers are "close enough".

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame work phone: (219) 631-3906
----------------------------------------------------------------------


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk