Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-01-27 16:16:58

Thanks Joaquin for your response.

> Umm, this approach is interesting! Better yet, instead of relying on an
> explicit are_equals function, we can just require that
> Factory::handle_type is EqualityComparable and use that:
> friend bool operator==(const flyweight& x,const flyweight& y)
> {
> return x.h==y.h;
> }
> As a matter of fact, all the current factories have EqualityComparable
> handles that precisely implement reference equality semantics, so
> it looks all very natural. This approach would solve the second
> problem of the list I presented at the review notes:
> * The resulting equality semantics might not coincide with that of
> the underlying T; the possibility of this hapenning and making a
> real difference is probably small, though.
> * The assumption that equal flyweight objects always share their value
> interfere with potential extensions to the library, like the
> no-factory proposal by Throsten Ottosen.

This seams OK to me, finally it will be the responsability of the factory
to define the equality operator
for its handle_type.

> but would not address the first point.

I think that I don't really understant the first problem:
if we have T t1, t2 such t1==T2 it may happens that
handle_type of t1 != handle_type of t2

Please could you give us un example on which the first problem is present?


Vicente Juan Botet Escriba

Boost list run by bdawes at, gregod at, cpdaniel at, john at