|
Boost : |
From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2006-04-30 11:41:23
On 4/30/06, Marcin Kalicinski <kalita_at_[hidden]> wrote:
> I think both approaches have their merits. For example, the above would not
> permit storing paths in strings or files. I intend to allow both:
>
> // These will be equivalent
> file = pt.["config"]["filename"].get<std::string>(); // #1
> file = pt.["config.filename"].get<std::string>(); // #2
Marcin, correct me if i get you wrong...
Your brand new cleaner interface for ptree will be like the one above?
You will merge the path concept approach with the operator[] approach
in this fashion??
PTREE IEEE (Easy to use, Efficient and Extensible Interface )
(*) Only two function for path handling...
ptree & operator[](path p);
const ptree & operator[](cpath p) const;
(*) Four way of interact with data... (actions, see next point for get)
get
put
set
del
(*) And two ways of using the get function...
get<type>() --> throws
get<type>(default) --> gives a default value
and one specialized template for managing optionals...
get< optional<type> >()
If this is what you intend to do, i just have to congratulate you... i
like very much the way the framework looks... (and you managed to cut
functions and eliminate redundancy big time). Now it is very
extensible, through creation of new paths, and the learning curve is
almost zero. Give someone the the IEEE ten lines description that i
just wrote to a casual user and it has to be a three year boy to
misunderstand it. And give it to a experimented one and he really will
appreciate the efficiency of operator[] and the expanding capacity of
the path concept. IMO is a win win situation.
I can wait for Thorsten call tonight...
It is the first library review in with i participate, and i enjoyed it big time.
Thanks a lot to everyone for give me the chance to be in it. I really,
really learn a lot... :)
Marcin, whatever the decision is... congratulations for a great work!
Best regards
Matias Capeletto
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk