
Boost : 
From: Ed Brey (brey_at_[hidden])
Date: 19991117 09:30:02
Dave Abrahams wrote:
>
> > For the general definition of multipliable, what is the reason for the
> > default argument for U?
>
> It's there so that you don't have to supply 2 template arguments in order to
> use the specialization, which is the usual case.
I see. I have a bit of coming up to speed to do regarding partial
specialization, but things are getting clearer.
> > These same issues apply to all the commutitive operators, although
> > it's only necessary to document one.
> >
> > For the noncommutitive operators, such as subtractable, what is the
> > reason for the:
> > (1) default argument for U
> > (2) specialization
>
> I don't understand the question about the "noncommutative" operators[sic]
> (op< isn't really commutative, but I get your meaning). The usage is
> completely uniform for all operators.
>
> Maybe this helps: just because A  B makes sense doesn't mean that B  A
> makes sense. Imagine, for example that A is a set of X and B is an X.
Right. And because of that situation, the general definition of
subtractable only has one friend (since the operands cannot be
commuted). Since there is only one friend, there is no possibility of
ambiguity. Therefore, no specialization is needed to resolve it.
Here's a quick test I did to verify that subtractable can compile
without specialization:
template <class T, class U = T>
class subtractable {
friend T operator( T x, const U& y ) { return x = y; }
};
struct A : subtractable<A> {
A& operator=(const A&) {return *this;}
};
int main()
{
A a;
a  a;
}
I just noticed a couple new issues, this time regarding the operators
class. First, only the less_than_comparable base class is public, and
all other base classes are private. Since everything is done through
friends, and the base classes themselves have no public members, it's
probably just as well to make all the base classes private.
Second, since all the base classes have specialization where needed to
deal with identically typed parameters, the specialization for
operators doesn't seem to be needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk