Re: [boost] Formal review request: Flyweight

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

This is how two flyweight<string> objects can be configured to use
different pools:

struct name_tag1{};
typedef flyweight<std::string,tag<name_tag1> > str1_t;

struct name_tag2{};
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
unnecessarily.

Compare this with the way users supply custom allocators to shared_ptr:

http://www.boost.org/libs/smart_ptr/shared_ptr.htm#allocator_constructor

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