Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-06-29 10:02:19

Hello Benoît,

Benoit ha escrito:

> I hope i am not being too naive, but what differences are there
> between your proposal and shared_ptr ? I can definitely see the object
> vs pointer access difference ; are there others ?

The main difference is that flyweight<T> enforces that *every*
flyweight object with the same value will have a pointer to the
same internal representation. shared_ptr does not provide any means
to automatically get this behavior. For instance, you are free to do this:

shared_ptr<string> p1(new string("hello"));
shared_ptr<string> p2(p1); // p1 and p2 share rep
shared_ptr<string> p3(new string("hello"));

where p1 and p2 share their representation while p3 holds a string
objects of its own. By contrast if you do:

flyweight<string> f1("hello");
flyweight<string> f2(f1);
flyweight<string> f3("hello");

the result is that f1,f2 and f3 internally point to the same "hello"
string. This "coalescing" work is what flyweight gets you in comparison
with shared_ptr. Of course, shared_ptr has a (wide) application
domain of its own where such coallescing is neither needed nor
acceptable. We are talking about different beasts.

> I am asking you this because, for the purpose you describe, i am
> currently using shared_ptr objects... Is it extremely wrong to do so ?

It all depends on your particular usage scenario. If your app semantics
guarantee that you cannot come up with a situation like the one described
above, then flyweight buys you nothing with respect to shared_ptr.
Otherwise, either you're having redundant copies around or else you
have implemented a mechanism for duplicate checking --which is
what flyweight internally does, of course.

I hope I've made myself clear, please come back if I haven't.

> Regards,
> Benoît

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

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