Re: [boost] [Property_tree review] Summary of enhancements proposed so far

----- Mensaje original ----- De: Marcin Kalicinski <kalita@poczta.onet.pl> Fecha: Sábado, Abril 22, 2006 2:48 pm Asunto: [boost] [Property_tree review] Summary of enhancements proposed so far
I created a brief summary of enhancements/changes to property_tree which were proposed so far.
1. Make path a class in its own right and overload / (division) operator to concatenate path objects efficiently. This removes need for ugly default separator, and half of the get/put overloads. It also boosts performance (no more string operations on path), and IMHO will generally improve interface of the library. Most importantly, it largely does maintain compatibility with existing interface.
Although a proper path class seems so much neater, I think you should still keep some API to specify a path as a single string, maybe something like: boost::property_path::path p("Dante/Divina Commedia/Inferno"); Why? Because this way you retain the ability to store a path as a program resource outside the code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

Although a proper path class seems so much neater, I think you should still keep some API to specify a path as a single string, maybe something like:
boost::property_path::path p("Dante/Divina Commedia/Inferno");
Why? Because this way you retain the ability to store a path as a program resource outside the code.
Yes, obviously. Path class will still support dot (or slash) separated strings. It will have non-explicit conversion constructor from such string. Best regards, Marcin

"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:38fab838b552.38b55238fab8@tid.es... ----- Mensaje original ----- De: Marcin Kalicinski <kalita@poczta.onet.pl> Fecha: Sábado, Abril 22, 2006 2:48 pm Asunto: [boost] [Property_tree review] Summary of enhancements proposed so far
I created a brief summary of enhancements/changes to property_tree which were proposed so far.
1. Make path a class in its own right and overload / (division) operator to concatenate path objects efficiently. This removes need for ugly default separator, and half of the get/put overloads. It also boosts performance (no more string operations on path), and IMHO will generally improve interface of the library. Most importantly, it largely does maintain compatibility with existing interface.
Although a proper path class seems so much neater, I think you should still keep some API to specify a path as a single string, maybe something like: boost::property_path::path p("Dante/Divina Commedia/Inferno"); Why? Because this way you retain the ability to store a path as a program resource outside the code. If you do this, perhaps you can add a second optional parameter for separator character: boost::property_path registryEntry ("foo.bar.glarch", '.');

I do not want to polute the list by resending old messages, but as the path class mini thread is lost in the middle of the pt/po/s11n disscusion, i have extract it and attached it here. I think that will clarify point 1 in the "summary of enchacements" list. Regards
participants (4)
-
JOAQUIN LOPEZ MU?Z
-
Joe Gottman
-
Marcin Kalicinski
-
Matias Capeletto