From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-04-24 02:41:11
Marcin Kalicinski wrote:
>> [...] 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.
>> [...] We do need good tree storage. We do need better runtime parameters
>> support library (IMO). We already have quite powerful solution for
>> permanent storage support, but we could use more archive formats for it.
>> What you propose is none of it.
> I'm sure you will agree that ptree is different from serialization. If you
> don't agree, read some of quite interesting posts by Ivan Vecerina. The
> main difference is that serialization lib is _only_ about translation of
> some C++ structures to/from a string of bytes. This is a huge and
> complicated task that it does very well. But you must have noticed that
> some people refrained from using it, because the files it produces are not
> "config files" in wide meaning of this word. The main issue with them is
> they are not hand editable. This cannot and should not be remedied by
> supplying another parser, just read Robert post outside this thread.
I doubt this statement. If you agree to serialize only "good" structures,
that require no object tracking, it will be possible to implement archive
class that will project no tracking information that upsets you.
> the other hand program options cannot handle hierarchical structures very
> well unless it is improved, and even then it will probably present more
> complicated interface than ptree.
This sounds like FUD. How can you make any statements about an
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk