Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-03 03:24:04

Jan Langer wrote:

>> Personally, 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)

AFAIKT, this is quite close to what I wanted/had. And this is indeed different
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at