Re: [boost] Formal review request: Flyweight

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-11-16 03:32:03

Emil Dotchevski ha escrito:

> > 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.

I understand your point and I think it's respectable, but in the end your
position is tantamount to banning policy-based classes, and with that
I obviously cannot agree. You seem to object to using templates for one
of the very purposes they were designed for: making the same code
work for different types.

> > > 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.

Well, I think flyweight<> does not do exactly what you think in this
respect: there's no need to *find out* which flyweight factory a given
flyweight object is associated to because any flyweight<...> type has
a unique factory of its own, identifiable at compile-time. So, the
info on what factory to use when (de)serializing a flyweight does not
travel across the archive.

> 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>.

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