Boost logo

Boost :

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-04-22 05:59:11


Gennadiy Rozental wrote:
> "Marcin Kalicinski" <kalita_at_[hidden]> wrote in message
> news:e2bn7h$s8v$1_at_sea.gmane.org...
>
>>>Make up you mind finally. What is your library?
>>>
>>>1. Runtime parameter facility
>>>2. Permanent storage facility
>>>3. XML parser
>>
>>I'm afraid it is all 3, plus some more. By "some more" I mean it has more
>>parsers than just XML, and it can also be used to manipulate hierarchical,
>>human readable data structures at runtime.
>
>
> And that's the main problem with this submission. Instead of clearly
> specified problem domain and design that address issue in this domain, you
> present some mixture of half-good components each with unclear advantages
> over existing dedicated solution in each respective area.
> I want faster
> search or no search at all - no can do.

There is the possibility to rewrite the internals of property_tree with
Boost.MultiIndex, and then it could use a hash-index instead internally.

Why is having no search so important. How does it hurt you that it is
there? (if the small overhead is not important anyway)

>I want different some versioning
> support for permanent storage - no can do.

What does this mean? versioning ala boost.serialization?

(aside: I think it would be reasonable for ptree to be serializable)

>I want some automatic validation
> and conflict resolution - no can do.

What does this mean?

> I understand it's good enough for you.
> But this is just the choices you made. Coupling solution for independent
> problems under the hood on one library is the source of inflexibility and
> unacceptable for boost IMO.

We can also keep adding customization to a component until it suddenly
collapses under its own weight.

Gennadiy, I hope we can avoid too much flame-wars. And I hope we can
to the buttom of the problems you mention s.t. you also would want to
use this library (unlike PO).

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk