Re: [boost] [review] Review of Flyweight library started January 21and still running!: equality semantic

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2008-01-27 18:04:15

----- Mensaje original -----
De: "vicente.botet" <vicente.botet_at_[hidden]>
Fecha: Domingo, Enero 27, 2008 10:17 pm
Asunto: Re: [boost] [review] Review of Flyweight library started 
January 21 and still running!: equality semantic
Para: boost_at_[hidden]

> Thanks Joaquin for your response.
> 
> JOAQUIN LOPEZ MUÑOZ wrote
> > 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?
> Regards

The situation would be one in which the equivalence criteria
used by the flyweight factory would not be the same as
induced by T::operator==, that is, if two flyweight objects fw1, fw2
are such that fw1!=fw2 yet fw1.get()==fw2.get() (the converse, i.e.
fw1==fw2 and fw1.get()!=fw2.get(), cannot happen). The following is
an admittedly artificial example:

  class istring:public std::string
  {
  public:
    istring(const char* p):std::string(p){}
    friend inline bool operator==(const istring& x,const istring& y)
    {
      return stricmp(x.c_str(),y.c_str())==0; // case insensitive
    }
  };

  typedef flyweight<istring,set_factory<> > fw_t;
    
  int main()
  {
    fw_t fw1("hello"),fw2("HELLO");
    assert(fw1!=fw2);
    assert(fw1.get()==fw2.get());
  }

Upon seeing this example, I'm growing more suspicuous that
maybe I'm being too precautious: situations like this are
extremely unlikely. Maybe the design is good as it is, and
equality of flyweights should just be based on &-equality.

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