From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-11-14 14:35:05
I just read a few pages of the documentation and I think I understand
the problem this library addresses.
Since the library is designed to be like a drop-in replacement for
immutable shared objects, there are similarities with shared_ptr:
flyweight<T> is designed to be a drop-in replacement for T const,
whereas shared_ptr<T> is a drop-in replacement for T *. Even issues
related to serialization and factories are similar between
shared_ptr<T> and flyweight<T>.
I am pointing out the similarities because the flyweight framework
lacks a very important property of shared_ptr, which I think is
directly applicable, and it has to do with the way flyweight<T> is
This is how two flyweight<string> objects can be configured to use
typedef flyweight<std::string,tag<name_tag1> > str1_t;
typedef flyweight<std::string,tag<name_tag2> > str2_t;
The problem is that now str1_t and str2_t are distinct types in the
type system, yet they are identical semantically. Suppose I have a
function that takes a flyweight string like this:
void foo( flyweight<std::string> const & s );
Even if implicit conversions between different configurations of
flyweight<std::string> exists, calling foo with str1_t or str2_t would
create unwanted temporary objects. Besides, such conversions will
create a default-configured flyweight<std::string>, which is not
desirable. The only option I would have is to make foo a template
which is unfortunate because it would increase physical coupling
Compare this with the way users supply custom allocators to shared_ptr:
Two shared_ptr<T> objects that use different allocators, once
initialized, are indistinguishable from each other because they are of
the same type, shared_ptr<T>.
I would like flyweight<T> configuration to work similarly.
-- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk