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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk