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