Jan Langer wrote:
AFAIKT, this is quite close to what I wanted/had. And this is indeed differentPersonally, I did not really notice your announcements. Some time ago
I wanted a dynamic type-indexed container, in which you specify the
required type, and it's either returned, or created. After quite look
on some email of yours I decided it's something different and stopped reading.
i needed that (or maybe something similar) for the filesystem attributes in the sandbox. i tried to make it compatible to the property map concept. the output can be used as follows (taken from boost-sandbox/libs/filesystem/test/type_pm_test.cpp)
from associative_list-based solution, although subtly. Here, you can store
arbitrary number of types and those types are looked up at runtime. With
associative_list you'd store a number of pointers of predefined types and lookup is done at compile time.
Which one is best, depends on the problem domain. For example, you could allow
user to define custom filesystem attributes, provided that classes for that attributes can be constructed from boost::path. (I see that now attributes are constructed with cache& as parameter, but that allows for user-defined attributes as well). Consequently, you need dynamic behaviour. Looks like BGL
does not need it, and can use associative_list.
boost::filesystem::detail:: type_property_map <char> pm;put <int> (pm, 'i');
Well, this looks pretty confusing, I'd even say dangerous. If the property map holds chars, then putting int there is questionable.
it is implemented using Lokis TypeInfo and a std::map <TypeInfo, T> where T is the type to store. it is possible to add another layer which sets T to boost::any and converts everything in overloaded get/put functions. the current attribute cache is (nearly) an example for that.
Yea, that's very reasonable. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
