
Boost : 
From: Jeremy Siek (jsiek_at_[hidden])
Date: 20010329 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) 6313906

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