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

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-04-25 18:31:29

"Marcin Kalicinski" wrote:

>> * Optional MT safety may be added.
>
> I would rather leave it at std::container style - no built-in safety.
>

Having get/set protected by mutext doesn't guarantee
complete MT safety but it should be enough for
application where the configuration is
loaded, read (from one or more threads) and
at the end saved.

More complex scenarios would need user written wrapper.

>> * Preserving comments and whitespace in INI/JSON/INFO
>>   could be the /most/ important reason someone
>>   decides to use the library.
>
> The more I think about it, the simpler it seems, and originally I thought 
> it is a definite no-no, just look at my replies to Jeff Garland. Some 
> suggested adding extra fields to the node, but this is not acceptable for 
> me; if comments cannot be handled by the tree alone it's better if they 
> are not handled at all. The way to do it is to add metadata (like 
> <xmlattr> or "\values"), which describes comments and optionally location. 
> Of course this will slow some of the parsers very significantly, so it 
> should be optional. Metadata will be fully editable, but will not pollute 
> normal data. I hope this is doable.
>
I won't talk about XML (do not use, not that much
knowledge, doubts about its future).

It is implementable for INIs (I did it) - these metadata
would be loaded, hidden from user but saved.
For JSON and INFO this likely applies as well.

As comments and whitespace are metadata
the application should not have any access to them.
They should NOT be editable (by the application).

>> * Overloads for parsers to parse given memory block
>>  (e.g. mapped file, shared memory)
>
> Maybe. But how about doing another library that presents arbitrary memory 
> block in form of C++ stream? I think it would be usable in many other 
> contexts as well, and in one of my projects definitely. Stringstream is 
> flawed because it must copy the data first. Copying whole memory-mapped 
> file is really a rubbish idea :-)
>
Hmm, possibly. Having
   parse(condt void* data, unsigned size, ptree&);
is however the simples interface possible.

The string type may be custom one, pointing into
provided memory instead of using allocations
of its own. The result would be something able
to parse really large amount of data.

/Pavel