Re: [boost] [Boost Review] Property Tree Library

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-22 05:46:27

>> Plus XML, I believe, is meant to be very much hand-editable.
>
> It's matter of opinion how XML is meant to be edited. Why do you think
> there so many XML editors?
>
>> Otherwise what would be its advantage over any binary format?
>
> Almost none. I would use binary format. But XML has nice advantage that I
> could use any number of existing tools to display/process it.

But you just said you do not need to edit it. Why do these tools exist then?
I'm quite sure (and I see some other posters are as well) that editing of
XML is very important. This is basically its most important "selling point".

>> You could also rewrite all the world's software in asm, or implement your
>> own version of C++, but why would you do that if property_tree can do
>> what you need in several lines of code?
>
> property_tree could "rewrite all the world's software in asm, or implement
> your own version of C++" in several line of code ;))?
> Sorry I am missing your point here.

Sorry, I was unvoluntarily straying off the topic with my comments.

What I meant is: you keep saying that this library could be rather 
implemented using serialization / PO / multi_index / etc. I agree, but it 
was implemented differently. I think it is the interface that matters most, 
not the implementation. Why care if it uses other libs or not? It's even 
better if it does not, think about all these dependencies and compile times. 
Even boost guidelines are pretty clear on that, I should not use other libs 
unless they provide critical functionality. The current implementation is 
very well covered by tests (more than 1 line of tests for 1 line of code), 
and none of the posters so far had any problems compiling it. I used it with 
quite large data files, and I know there are no showstopping performance 
problems. Performance will definitely be improved once I implement some of 
the suggestions that were already posted (namely path objects). So, I do not 
see reason why I should rewrite it at as a layer on top of above mentioned 
libraries. Especially that it would detract from some of its legitimate 
uses.

Best regards,
Marcin