New functionalities can be included into future releases of Boost.Flyweight to meet the demands of users and to leverage upcoming C++ features and new Boost libraries. The following is a list of candidate additions.
Currently there is no way to access the internal components of a
flyweight
instantiation (factory, holder, etc.) or even
to know the types of these components. With such an API it would be
possible to instrument and monitor the usage of Boost.Flyweight like in
the following example:
typedef flyweight<std::string> fw_type; ... std::cout<<"factory used: "<<typeid(fw_type::factory_type).name()<<std::endl; std::cout<<"values stored: "<<fw_type::factory().size()<<std::endl;
The nature of the flyweight pattern implies that most accesses
to the internal flyweight factory do not cause new insertions and can
thus be considered read-only. This hints at the convenience of using
a locking policy based on read/write locks such as those provided by
Boost.Thread.
Implementing a locking policy will also require extending the
Factory
concept
to allow for pure lookup operations. Tim Blechmann has provided a
preliminary implementation
of this idea. Before committing to this library extension it is
necessary to do a profiling study to determine whether read/write
locking actually improves performance.
Recently accepted Boost libraries like Boost.Functional/Forward and Boost.Functional/Factory might be used in the future to replace some internal machinery of Boost.Flyweight.
Revised April 24th 2019
© Copyright 2006-2019 Joaquín M López Muñoz. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)