Boost logo

Boost :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2008-01-28 17:21:23


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

> JOAQUIN LOPEZ MU?Z wrote
> >
> > 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.
>
[...]
> The problem with the set_factory for this class is that
> istring("hello") ==
> istring(HELLO) and istring("hello") < istring(HELLO).

Correct.

>[...] so why not rely on some traits class and let the user state
> what he/she prefers.
>
> // by default considered equal if they share their value
> template <typename T>
> struct flyweight_equals_if_shared_value : boost::mpl::true_{};
>
> // resort to the underlying values.
> template <>
> struct flyweight_equals_if_shared_value<istring> :
> boost::mpl::false_{};
> Can this be used to solve the equality semantic problems?

Yep, this is a variant of another reviewer's proposal of
having this bit of info as an extra template parameter. Either
way is realizable. What I'm not so sure, after discussing the
issue with you, is if we really should worry about this
rather pathological situation: after all, if a user ever
faces it, she just can override oeprator== with non-& semantics
and be done.

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


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