Re: [boost] Formal review request: Flyweight

From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-11-15 20:36:36

> Another possibility, and this might be more likeable to you, is to take advantage
> of the implicit conversion from flyweight<T> to const T&, and instead of
> having
>
> void foo( flyweight<std::string> const & s );
>
> write
>
> void foo( std::string const & s );

If you have two systems that internally use std::string to store
strings, they could conceivably communicate in terms of a char const *
interface; but the fact that you can strip the std::string semantics,
doesn't mean that you always want to.

Similarly, yes, you can pass a flyweight<std::string> as an immutable
std::string, but in doing so you're getting rid of the flyweight
semantics. Sometimes this is exactly what you want, and sometimes it
isn't. In the latter case you have the problem I outlined.

> > Also, shared_ptr needs proper factory support to compliment
> > serialization of shared_ptr objects, which is the same stuff needed to
> > implement flyweight.
>
> I don't understand this. What factory support for shared_ptr are you referring
> to?

The one that does not exist (yet) :)

Let's say you have two shared_ptr<foo> objects, pa and pb, that point
to different foo objects. How do you serialize them?

Consider that they may have been created by different factories and so
at write time you need to save that information so that at read time
you know which factory to use for pa and for pb. If I understand
correctly what flyweight factories are, and how flyweight is
serialized, it solves a very similar problem.

So what I mean is, perhaps this problem can be solved independently of
flyweight and applied to both flyweight and shared_ptr. Even better
(in my opinion), the problem can be solved for shared_ptr, and then
flyweight<T> could be implemented over shared_ptr<T>.

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode