Re: [boost] [flyweight] Review period extended to February 3

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2008-02-04 06:54:24

Hi Markus, thank you for submitting your review.

Markus Werle ha escrito:

> My remarks to the current discusion:
>
> Equality semantics:
> This is where I'd like to see the library changed.
> I did not think about this in depth, but it let me feel
> uncomfortable immediately after reading that passage in the docs.
>
> Flyweight is advertized as "drop-in replacement for const T."
> and can be used everywhere a "T const &" is expected
> and as such it should behave also for operator==.
> I found it odd, that something that is "not a pointer" must
> be dereferenced to be compared.

Sorry, I'm not getting this. Where is dereferencing needed?

> This breaks too much code for a true drop-in replacement.
> Also I think that intuitive behaviour is a GoodThing(TM) for a C++
> library. We get so used to all these little oddities that make
> you look into the book even after years in C++, but I think
> it's complicated enough now.
>
> The constant time comparison is nice, but it is due to the
> IMHO counter-intuitive basic interface (though I can see its advantages).
> In any case I'd prefer comparison of the underlying values,
> even for flyweights from different factories (!), just in order
> to keep the "drop-in replacement for const T." semantics everywhere
> and in any case.

For flyweights of different types comparison resorts to the underlying values.
The optimization is only introduced when the flyweight types compared are the
same. This is explained in detail at
http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/
doc/reference/flyweight.html#comparison

> If I need a safe access that ensures both fws come from the
> same factory, and const compare times, etc, I'd prefer a special free
> function compare(...) which then has all the semantics
> operator== has now.

I tended to think that way before the review, but I'm not so sure now: the cases
where having &-based equality semantics could deviate from the underlying
semantics are truly pathological (see for instance
http://lists.boost.org/Archives/boost/2008/01/132710.php ). The main
advantage of &-based equality is its nice interaction with composite patterns:
having a separate compare function would not play so nicely.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo