$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-22 00:56:27
"Andy Little" <andy_at_[hidden]> wrote in message 
news:e2c9jq$c8g$1_at_sea.gmane.org...
>
> "Gennadiy Rozental" wrote
>>
>> "Andy Little" wrote
>>>
>>> "Andy Little" wrote
>>>>
>>>>Did you consider a generic tree design? If so
>>>> why did you reject it in favour of this one?
>>>
>>> Just to refresh... The above is the most interesting and yet unanswered
>>> question
>>> about property tree for me. Am I missing something? Is this a silly 
>>> question?
>>> Is
>>> it too trivial to answer?
>>
>> IMO the same result (as library presents) could be achieved just by using
>> multi_index.
>
> There is a concept of a Path in Property Tree  whereas multi_index has no 
> path
> concept but rather a unique key per
> element and concerns itself with returning a particular view on a flat set 
> of
> data. OTOH  the tree is a fixed hierarchical structure where the  position 
> of an
> element in the structure is relevent (two elements can have the same name 
> but
> can be distinguished by their positions), whereas multi_index presents a 
> subset
> of a flat (non hierarchical) collection of elements.  In the tree the 
> particular
> properties of the elements plays no part in their ordering, whereas in
> multi_index their ordering in a particular view is a direct function of 
> some
> particular properties of the elements.
>
>
> IOW there seems to me to be a great deal of difference between Tree and
> Multi-index.
I never said say are the same. I said "could be". It also "could be" 
achieved with use of some tree data structure. And in some cases just plain 
std::map will surface either.
Gennadiy