April 2006 - Boost - lists.preview.boost.org

[ANN] New documentation style sheet
by Eric Niebler 24 Apr '06

24 Apr '06

The good folks at boost-docs have been working on improving the look-and-feel of Boost's documentation. This work is based largely on Rene Rivera's website redesign. The change went in to both HEAD and the release branch a few days ago. The biggest change is a smaller font. We've also improved readability by eliminating colored backgrounds, and improved the presentation of many elements of the Doxygen-generated reference sections. Please take a moment to have a look at the new docs: http://tinyurl.com/4b9gc. Compare to the style of the 1.33.1 docs here: http://tinyurl.com/rujfh. (I notice that there is some strangeness at the bottom of the libraries.html file the above link takes you to. There should be an alphabetized lists of libraries, and instead there is a fragment of the Boost.Concept_check documentation. That's clearly a bug, but it's not related to the style change.) Report any problems with the new style to boost-docs(a)lists.sourceforge.net. Thanks, -- Eric Niebler Boost Consulting www.boost-consulting.com

17 41

Re: [boost] boost::bimap [was Re: Do really property_tree andprogram_options overlap? ]
by JOAQUIN LOPEZ MU?Z 24 Apr '06

24 Apr '06

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Abril 23, 2006 4:16 pm Asunto: Re: [boost] boost::bimap [was Re: Do really property_tree andprogram_options overlap? ] > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> writes: > > > I'm afraid I don't have the time to pursue this, as the > > current roadmap for core features of B.MI is taking > > all the spare time I can dedicate to the library. For this > > reason, I would love to see some volunteer jumping in > > who can develop this and other singular containers using > > B.MI (a cache container comes to mind) and then propose > > the results here either as a stand alone library of as > > part of B.MI --I'd prefer the former so as to keep the size > > of B.MI bounded. > > > > If there's such a volunteer I can provide her with some > > help/mentoring. I also wonder whether this is a task > > suitable to be proposed for Google Summer of Code. > > Great! Do you have time to add it to the Wiki page? ;-) I've just done so, please take a look at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2006 (bottom of the page) and please comment on whether you find it informative/appealing enough. I've only included those ideas related to B.MI (Thorsten has proposed additional items in other post) because it is the only task I feel confident enough to mentor. Who's the spokesperson for Boost at SOC? You, Dave? Have we already applied for mentorship? Also, I'm a little dissapointed by the low number of proposals gathered so far. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Re: [boost] [Boost Review] Property Tree Library
by Ames Andreas 24 Apr '06

24 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Jorge Lodos > Sent: Friday, April 21, 2006 2:55 PM > Subject: Re: [boost] [Boost Review] Property Tree Library > > What I think PT must have that serialization library is not > meant to is: > > 1. The ability to load/save properties independently, not as a whole. > 2. A documented (for library extensibility) parser interface > allowing parser > developers to accomplish (1). > > At least 3 storages requiring (1) come to mind: windows > registry, ISA Server > storage and IIS metabase. > I would put these requisites as conditions for acceptance. And 3. The ondisk representation should be manually editable (i.e. by human beings) Given some posts I've seen, this seems not necessarily to be a primary goal of serialization while I'd count that a must-have for some config formats (e.g. XML representation should have a DTD, schema or something etc.). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com

4 3

Re: [boost] [Boost Review] Property Tree Library
by Tom Brinkman 24 Apr '06

24 Apr '06

I took another look at the library this morning and I agree with Jeff Garland that this library has potential. Howewver, it is hard to get my head around this library becouse it contains two very different things: 1) a recursive property-tree container and 2) six parsers to populate this container. I'm not a low-level container author so I cant speak to the merits pro/con of this implementation of a recursive property-tree. Nevertheless, I would like the review to focus on this, without regard to the parser grammers. I think that my objections could be resolved by removing the six-parsers from the review. Assuming the "property-tree" container is approved, lets schedule another review for these six-parsers. Either all of them at once, or one at a time. If the library author would be willing to delay the review the parser grammers until later this year, I might be persuaded to give this library another review.

6 7

[Boost Review] Property Tree Library
by Tom Brinkman 24 Apr '06

24 Apr '06

I'm voting NO on "property tree". I'm not persuaded that this library should be added to boost. Here is my review: * What is your evaluation of the design? Interesting. The "Property Tree" library attempts to meet a real need that I have had. The design appears to be appears to be adequate at first, but the more time I spent with working through the examples, the less I liked it. * What is your evaluation of the implementation? I think the implementation is pretty good. Overall, the author(s) have utilized modern c++ and established boost's "best-practices", including using boost::spirit for the "xml" parser. I'm not sure why he didn't use boost::spirit or boost::xpressive for the other parsers though. * What is your evaluation of the documentation? Inadequate, at least compared to the better documented boost libraries. More work is need here. * What is your evaluation of the potential usefulness of the library? Each individual part of the library is very useful. * Did you try to use the library? With what compiler? Did you have any problems? gcc. No problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I studied documentation and the source code for a couple of hours. There is variety of interesting stuff hidden in this library. I ran the examples and created a couple of my own. * Are you knowledgeable about the problem domain? Yes * Do you think the library should be accepted as a Boost library? No I'm voting NO on "property tree". I'm not persuaded that this library should be added to boost. It should be broken up into seperate boost::spirit or boost::xpressive grammers and submitted seperately. Grouping all this stuff under the "property tree" library is convenient, but not up to the standards of a boost library.

4 3

interest in an automatic dereferencing mechanism?
by sm garth 24 Apr '06

24 Apr '06

I'm working on a small library that performs compile-time, inline dereferencing that may prove useful for writing more generic algorithms. For example, a function that searches a sequence of iterators for an integer could be designed that would treat an int***[] just as if it were an int[] array. Is this something that might belong in the Boost framework? --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

2 1

[property_tree review] Making the interface leaner, concretely...
by Ivan Vecerina 24 Apr '06

24 Apr '06

Hi, I wanted to give this a shot, as some others have agreed that the member-interface of ptree should be simplified - to being more like that of a container. I would plainly take out all the member functions labeled as "Ptree-specific operations" (see basic_ptree in the Synopsis in the main doc page: http://kaalus.atspace.com/ptree/doc/index.html ). A first step would be to convert them into a set of non-member functions (preferably in a separate header file). Another issue is that we have a multitude of functions because orthogonal features/concepts are being mixed together: - get, optional-get, default-get, put, and set (to be added) - own-data, child, and any-path access - for paths, custom or default separators - actual conversion of a value to/from a data string (or a ptree) - features such as first-class support for indexing an array also might be desirable Also what about: - stricter error checks: what happens if two children have the same name, making a path ambiguous? what about "hybrid" record/array tree nodes? - customization points: how do I specialize the conversion of a UDT to/from a ptree ? I would like to suggest as a starting point for this decomposition, to make the ptree library more flexible/adaptable to individual needs. How about the following building blocks: ? 1) value <-> ptree conversion templates void set( const Value& v, ptree& storage ); void get( Value& v, ptree const& storage ); //throws if conv. fails bool tryget( Value& v, ptree const& storage ) //ret. false if fails { try{ get(v,storage); return true; }catch(...){} return false; } The default implementation of these functions would use lexical_cast to store/retrieve a value to/from a ptree with only an 'own' value set. The template could of course be specialized for user-defined types. For example, I could implement these functions for a struct used as a member in various locations, and convert it into a ptree with a child for each struct data member. Which of get/tryget (throwing and non-throwing functions) is implemented in terms of the other is TBD. 2) Child access (direct child only) ptree const& getField( ptree const& tree, string childName ); // gets a field, throws in case of failure or ambiguity ptree const& trygetField( ptree const& tree, string childName ); // returns empty_ptree if the field is not found or ambiguous ptree& makeField( ptree& tree, string childName ); // accesses the field, creates it if needed ( like std::map::op[] ) + Do we want an "addField" function that always creates a new child even if one already exists? Or should we provide array-indexing functions ? 3) getoptional etc Shall be defined in terms of a sequence of calls to the previous functions. Exact set to be defined as discussed elsewhere. 4) path access TBD. I'll find it acceptable if existing get/put functions are preserved as non-member functions, but left outside of the class, and maybe preferably in a sub-namespace (ptree_stringpath, or whatever). Various proposals have been discussed in these review posts, and again could be implementable in terms of the above. Comments/opinions ? Ideas for using operator overloading? Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

4 13

Re: [boost] [Boost Review] Property Tree Library
by Tom Brinkman 24 Apr '06

24 Apr '06

Sorry, But I cant follow you in the thread so I have to put this at the top level of the thread. I am not at home right now. > I understood it perfectly well. However, you also stated that the > parsers should come in at a later point. Thus my point still applies, if > only for limited time. However, that time is crucial. If there is a > Boost release (1.35) that includes the tree, but not the parser, people > might get used to that "useless property_tree thing" and not care to > look at its improved value in 1.36. Bad reputations tend to stick. Poor points. Getting this library thing ready by version 1.35 or any other version is my last concern. I want it to be correct. Its not acceptable that that this fairly large library will not get the full review that is necessary for a boost library. The scope of this library is too diverse for it that too occur in only a 10 day review period. It is very, very common for libraries to need a second or even a third review. I think that this library falls in that category of libraries that will need multiple reviews. > Also, the way I understood your post, your objection to the parsers was > that they are a completely separate thing from the tree and thus should > not be reviewed together. I find this objection simply wrong. The > parsers are a very important part of the property_tree library, and IMO > it's just its inappropriate name that makes them seem misplaced. As this seems to be opinion that you share with one or two others, please educate me. Why does the "property tree" require a parser. I just dont get it. How is the "property tree" container different from the vector and map containers, which almost certainly did not have parsers included along with them when they were added to the standard. What makes the "property tree" different from other containers that dont require parsers. I dont recall a single example of a container in C++ that had to have a parser. I suspect that those of you who want the parsers included with this library are just trying to sneek an XML parser through the review process without a full review. Please tell me that I'm wrong on this point. This library will eventually get accepted, I'm fairly sure of that, possibly even portions of the library will be approved this time around. What is your rush to get this one through. Lets take our time and get it right.

6 8

Overlap of property_trees with other boost libraries
by Ben Artin 24 Apr '06

24 Apr '06

The question was raised of possible overlap between the proposed property_tree library and the existing serialization and program_options libraries. My view on this matter: The primary purpose of the program_options library is to provide an input mechanism for simple (flat) data, specifically for the purpose of providing configuration options to programs that are configured via the command line or config files. The need for this library arises because those mechanisms for entering configuration options are common in command-line tools. The primary purpose of the serialization library is to provide a way to convert live C++ data structures into a form that can be transported to another program (or to the same program at a later time) and there reconstituted into a clone of the original data structure. The need for this library arises because the need for communication with other processes and storage of application data outside of the application process is common across many problem domains. The fact that the serialization library in its current form provides only conversions to byte streams is not important. This is just an implementation detail that arises from the fact that most common forms of interprocess communication and external storage use byte streams, and so conversion of C++ data to byte streams easily addresses both of those problems. Let us assume there there exists a data representation other than a byte stream that is suitable for external data representation or interprocess communication. Such a representation would be a reasonable archive format for the serialization library. A user of the serialization library could (at least in principle) take advantage of the strengths of this data representation. Regardless of the data representation used by the serialization library, one must treat the serialized format as opaque; there is a substantial amount of metadata embedded in it, and while the format can be made to be human-readable, it's predictably difficult to make it human-editable and even harder to make it human-writable. It it not possible to eliminate this metadata and retain other features provided by the serialization library (such as pointer tracking and class versioning). Now consider those design goals and constraints: the program_options library is an input method only; the serialization library is an input and output method, with features that prevent the data format from being human-editable. It is clear that in any case in which a human-editable input and output file format is needed, neither of these libraries will satisfy the requirement. As it turns out, the domain of persistent configuration data edited both by humans and by programs (such as configuration data of most GUI programs) is such a case, and that the need for persistent user-editable configuration data is not addressed by either program_options or serialization. Enter property_trees. This library attempts to fill this need (persistent user-editable data) and as a result overlaps with some functionality already provided by serialization and program_options. If all you need is data input, you could use either property_trees or program_options, as long as your data structures are simple enough to be representable by program_options. If you need input and output, you could use either serialization and property_trees, with different data format and code complexity tradeoffs. Here are some questions that I think need to be answered in order to decide whether this overlap is a good idea: 1) Is a property tree in-memory data structure a valuable abstraction, regardless of how it is serialized? I think the answer to this is yes. Representation of a hierarchy of key-value pairs is useful across the board, whether you are writing a compiler (symbol tables) or a GUI FTP client (cached per-directory data). 2) Is the serialization of such a data structure to formats less rich than those needed by the serialization library useful? I think the answer to this is yes. The obvious motivation for this is in serialization of configuration data to a user-editable form. 3) Could such serialization be done by the serialization library? I believe so. Provided that the serialization library has the notion of an archive that doesn't allow for class versioning or pointer tracking and may have limited ability to represent hierarchical data, many common configuration file formats (including Windows INI files, Mac OS X property lists, UNIX key<delimiter>value formats) can be produced by the serialization library. 4) Should such serialization be done by the serialization library? I believe so. The serialization library already has an interface for defining a way to convert C++ objects to an external representation, and I think it would be a good idea to maintain one interface for that purpose in boost. 5) Could a serialized form of property trees be used to input program options? Yes. So, here is one way that I see to resolve the property_trees conundrum: 1) A library providing an in-memory property tree abstraction should be submitted. 2) A library providing serialization of property trees to some common configuration file formats should be submitted. This could be part of the same library as in part 1. As part of this work, serialization library may need to be modified to allow for archive formats that cannot represent the full range of object and class tracking metadata. 3) Ideally, this should result in the ability to serialize arbitrary C++ objects directly to a configuration file format -- in-memory data shouldn't have to be in the explicit form of a property tree in order to be serializable to a configuration file. 4) Property tree file formats should be allowed as inputs to the program options library (and the existing program options configuration file format should be subsumed by the library from part 2 above). This would result in orthogonal components for each of the following responsibilities: 1) In-memory property tree representation 2) External property tree representation 3) Conversion of C++ objects, including in-memory property tree representation, to external property tree representation 4) Interpretation of property trees as command line program options 5) Parsing of command line program options from argv For what it's worth, Mac OS X has a native property tree API, and I have implemented a serialization archive format that produces such a property tree from C++ data structures using the serialization library. My understanding of the various abstractions and their interactions is based on that experience. Ben -- I changed my name: <http://periodic-kingdom.org/People/NameChange.php>

3 3

Re: [boost] Fwd: Program Options: string iterator not dereferencable
by Olaf van der Spek 24 Apr '06

24 Apr '06

On 4/24/06, Vladimir Prus <ghost(a)cs.msu.su> wrote: > On Monday 24 April 2006 12:19, you wrote: > > ---------- Forwarded message ---------- > > From: Olaf van der Spek <olafvdspek(a)gmail.com> > > Date: Apr 22, 2006 11:59 AM > > Subject: Program Options: string iterator not dereferencable > > To: boost(a)lists.boost.org > > > > > > Hi, > > > > I think there's a bug in the program options library. It appears to > > dereference an invalid string iterator. > > Hi Olaf, > I've just fixed this and now re-running all tests. I'll let you know when the > change is in. Thanks. There also seem to be 'typos' in some comments. Should I report those to you too? And what about: Is it possible to allow long options without -- prefix? The code doesn't seem to support it, but I think it's handy in cases where positional options aren't used.

1 0

Program Options: string iterator not dereferencable
by Olaf van der Spek 24 Apr '06

24 Apr '06

Hi, I think there's a bug in the program options library. It appears to dereference an invalid string iterator. libs\program_options\src\value_semantic.cpp: void validate(any& v, const vector<string>& xs, std::string*, int) { check_first_occurrence(v); string s(get_single_string(xs)); if (*s.begin() == '\'' && *s.rbegin() == '\'' || *s.begin() == '"' && *s.rbegin() == '"') v = any(s.substr(1, s.size()-2)); else v = any(s); } A !s.empty() check should be added.

2 1

[iostreams] Patch for BCB2006
by Nicola Musatti 23 Apr '06

23 Apr '06

Hallo, the enclosed patch brings support for the latest Borland compiler to the same level as bcc 5.6.4 . I tested it against bcc 5.8.2, bcc 5.6.4, VC++ 8.0 and g++ 3.4.2 . Cheers, Nicola Musatti ******Index: positioning.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/positioning.hpp,v retrieving revision 1.8 diff -d -u -r1.8 positioning.hpp --- positioning.hpp 19 Nov 2005 19:56:13 -0000 1.8 +++ positioning.hpp 8 Apr 2006 14:09:33 -0000 @@ -46,7 +46,7 @@ return std::streampos(std::mbstate_t(), off); } -inline stream_offset fpos_t_to_offset(fpos_t pos) +inline stream_offset fpos_t_to_offset(std::fpos_t pos) { // Helper function. #if defined(_POSIX_) || (_INTEGRAL_MAX_BITS >= 64) return pos; Index: detail/bool_trait_def.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/detail/bool_trait_def.hpp,v retrieving revision 1.6 diff -d -u -r1.6 bool_trait_def.hpp --- detail/bool_trait_def.hpp 12 Oct 2005 00:32:43 -0000 1.6 +++ detail/bool_trait_def.hpp 8 Apr 2006 14:09:57 -0000 @@ -20,7 +20,7 @@ // Description: Used to generate the traits classes is_istream, is_ostream, // etc. // -#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) +#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) # define BOOST_IOSTREAMS_TRAIT_NAMESPACE(trait) #else # define BOOST_IOSTREAMS_TRAIT_NAMESPACE(trait) BOOST_PP_CAT(trait, _impl_):: Index: detail/config/codecvt.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/detail/config/codecvt.hpp,v retrieving revision 1.3 diff -d -u -r1.3 codecvt.hpp --- detail/config/codecvt.hpp 1 Jun 2005 19:13:15 -0000 1.3 +++ detail/config/codecvt.hpp 8 Apr 2006 14:10:21 -0000 @@ -63,7 +63,7 @@ #if defined(__LIBCOMO__) using ::mbstate_t; -#elif defined(BOOST_DINKUMWARE_STDLIB) +#elif defined(BOOST_DINKUMWARE_STDLIB) && !defined(__BORLANDC__) using ::mbstate_t; #elif defined(__SGI_STL_PORT) #elif defined(BOOST_NO_STDC_NAMESPACE)

1 2

[io] Patch for BCB2006
by Nicola Musatti 23 Apr '06

23 Apr '06

Hallo, If I do not receive objections in the next few days I plan to apply the attached patch. Cheers, Nicola Musatti ******Index: ios_state.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/io/ios_state.hpp,v retrieving revision 1.4 diff -d -u -r1.4 ios_state.hpp --- ios_state.hpp 2 May 2005 06:24:20 -0000 1.4 +++ ios_state.hpp 18 Apr 2006 05:58:04 -0000 @@ -134,7 +134,11 @@ explicit basic_ios_exception_saver( state_type &s ) : s_save_( s ), a_save_( s.exceptions() ) {} +#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) + basic_ios_exception_saver( state_type &s, aspect_type a ) +#else basic_ios_exception_saver( state_type &s, aspect_type const &a ) +#endif : s_save_( s ), a_save_( s.exceptions() ) { s.exceptions(a); } ~basic_ios_exception_saver()

1 0

boost::bimap [was Re: Do really property_tree and program_options overlap? ]
by JOAQUIN LOPEZ MU?Z 23 Apr '06

23 Apr '06

----- Mensaje original ----- De: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> Fecha: Domingo, Abril 23, 2006 9:28 am Asunto: Re: [boost] Do really property_tree and program_options overlap? > Pavel Vozenilek wrote: > > "Thorsten Ottosen"wrote: > > > > > >>Well, I think we need both. Boost.MultiIndex is a great library > and can > >>do all kinds of wonderful things. But I would still like to see > >>a bidirectiobal map (boost::bimap) written as a wrapper around > it to > >>get an easy and specialized interface. > >> > > > > bimap is available in > > libs/multi-index/examples/bimap.cpp. > > Right, but the real value comes when somebody designs a nice > STL-like interface and write docs etc, at least that was my point. > Hello Thorsten, we have talked about this privately in the past, but I feel like bringing it to the list in the hope of getting the attention of potential contributors: There are some data structures buildable with B.MI which are regarded as particularly useful or common, like for instance the bidirectional map or bimap. A lean and mean implementation is provided in the aforementioned example, but certainly a much carefully crafted interface can be provided keeping B.MI as the implementation core: operator[], selection of 1-1/1-N/N-1/N-N variants, hashing/ordering, etc. I'm afraid I don't have the time to pursue this, as the current roadmap for core features of B.MI is taking all the spare time I can dedicate to the library. For this reason, I would love to see some volunteer jumping in who can develop this and other singular containers using B.MI (a cache container comes to mind) and then propose the results here either as a stand alone library of as part of B.MI --I'd prefer the former so as to keep the size of B.MI bounded. If there's such a volunteer I can provide her with some help/mentoring. I also wonder whether this is a task suitable to be proposed for Google Summer of Code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

Re: [boost] [Boost Review] Property Tree Library
by Alexander 23 Apr '06

23 Apr '06

I am participating at project at which similar system was "invented". And so could provide some suggestions concerning the problem. We start our project from necessity to create windows registry like system for value storage at hierarchical order. Windows approach was quite adequate for our tasks but desire of compatibility makes it impossible to use it. After all win registry interface is archaic and inconvenient. It was our start point. We implemented interface which use node, leaf and attribute approach because of win registry influence. Now I could say that it's looks like mistake. This multilevel model makes interface too complicated without any benefits at reality. So, homogeneous interface of Property Tree Library is much more elegant and simple. I think that one tree implementation is not enough for all kinds of task. The simplest tree of course could be useful for small tasks. But it is not adequate for really big projects. So we create proxy which hides from us details of realization. It gives me opportunity to make unexpected solution for GUI. I don't like GUI programming and try to avoid it if only possible. So I create solution which allows users modify registry at safe manner. Methods of input, validators, access policy and so on prevents user from unsafe input. Safe behavior is based on attributes which stored at the same registry. But it's unsafe and inefficient to store data and visualization attributes at the same place. So proxy which mixed two different proxies for benefits of visualization was created. We decide that symbol '/' is forbidden for using as name. (If you wish to store filename or something which contains '/' you could store it as data not as key. Or if it so necessary to have '/' at name it is possible to use "//" mechanism. Point is not better at all because it's also could be at filename. 'Point looks strange as separator at hierarchical systems. Once more I prefer '/' after win registry semantic. Specifying separator at every function is ugly solution. ) For saving and loading we also use parser mechanism. But we have the basic class for it. It's my favorite trick to use vector of parsers for saving and loading. About name. Property Tree Library is not bad name I think, because being familiar with such approach I immediately understood what it's about. >What is your evaluation of the design? At least, the separator problem should be resolved adequately. >What is your evaluation of the implementation? >What is your evaluation of the documentation? Good enough >What is your evaluation of the potential usefulness of the library? I'm not quite sure but author do not positioning library as registry. I think this road should be leading to registry. At current form it is bonded to quite simple systems. >Did you try to use the library? With what compiler? no >Did you have any problems? no >How much effort did you put into your evaluation? It was only the comparison with my current solution. But it's taking a long time to. >Are you knowledgeable about the problem domain? Yes The Boost library at my opinion should resolve problem at full scale. It should provide foundation for full variety of different applications from small ini files to multithreaded and even dispersed registries. Alas, at current design library couldn't help me. But bear in mind that I am rather centered on my existing design and that library resolve more simple case I should vote for addition library to boost. Regards, Alexander Belyakov P.S. Well, I want make it clear to prevent misunderstanding that this library is not overlapped by boost.serialization at all but it will be overlapped by boost.registry if some one proposed it. It's clear enough for me that this library shouldn't be viewed as XML reader or any other reader. It's nice library with elegant and simple interface. Author defines property tree as a recursive data structure at another place he wrote it's a container. And it is really so. But REGESTRY is CONCEPTION not data structure. SERIALIZATION is also CONCEPTION. Author makes a lot of work. And he makes it almost ready to transform interface of container to something more interesting - to interface of conception. His library useful and I couldn't ask him to make a lot of work more. But if he wants he could make from it something more powerful. I could provide more information about my project if it's interesting.

1 0

Re: [boost] Do really property_tree and program_options overlap?
by JOAQUIN LOPEZ MU?Z 23 Apr '06

23 Apr '06

----- Mensaje original ----- De: Marcin Kalicinski <kalita(a)poczta.onet.pl> Fecha: Domingo, Abril 23, 2006 3:48 pm Asunto: Re: [boost] Do really property_tree and program_options overlap? > > I had now a look at the source code: If I understand correctly > it is > > possible to use the read/write functions (like read_xml, > read_ini, > > read_json etc.) with other containers? So there is no tight > coupling? > No, it is not normally possible. read/write functions expect a > recursive > container, because they need tree-like structure. I made no > attempt to > generalize the library, so that read/write functions can work with > general > recursive containers (btw. the whole idea of recursive container > is actually > quite fuzzy). What would it take to make the generalization? IMHO some concept of recursive container visitation/population along with an example of how your parsers can be made to work with data structures other than ptree would be a boon wrt to acceptance of the lib. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Do really property_tree and program_options overlap?
by Marcin Kalicinski 23 Apr '06

23 Apr '06

Hi Everybody, I see there is some confusion about possible overlap of program_options and property_tree libraries. First of all, my opinion is there is very little overlap. The biggest difference between the libraries is that property_tree is hierarchical and program_options is linear - i.e. options are accessible through a map-like interface. Structure of file formats, like XML, JSON etc. is inherently hierarchical. The presence of hierarchy is their greatest strength, and most important feature. Large amount of information is conveyed by structure of the tree alone, not only by values it contains. The same value in two different branches of the tree can have completely different meaning. Contrary to that, in program_options library there is only at best a notion of "positional options", which is completely different from hierarchy. Briefly, PO library operates on a flat strings of options, property_tree is a DOM. Think of property_tree like a replacement for Microsoft XML parser, or JSON API, or Windows INI API, or registry API. Do you imagine using program_options to manipulate XML trees, like the ones you get from XML parser? It is not suited for that, its problem domain lies in completely different place, namely parsing a linear string of (command-line) options, possibly supplied as a config file or files. In addition to that, PO library does not support writing the structures back to config files. It is not a flaw with the library, it just does not need to do it, because options for programs are meant to be "one shot", or "read and forget", like command line arguments. There's not need to store them back where they came from. On the other hand, PO library supports many things that do not belong to property_tree. These include, for example, options descriptions and notify mechanisms. Taking all that into account I do not see why anybody insists there might exist 1:1 correspondence between the libraries. I agree both can parse command lines, but that's about it. Other functionality is very different. One has to distinguish between reading command-line options (or other simple configuration) and reading structured DOM data. For example, take a program like visual XML editor. It could use both PO and property_tree to read its startup config (keyboard shortcuts, font etc.). But only property_tree would be suitable to handle XML files to be parsed, displayed, edited and saved by the editor. It would be rather ridiculous to use program_options to do that, although not impossible, if one tried really hard. Best regards, Marcin

6 12

Re: [boost] [Boost Review] Property Tree Library
by Tom Brinkman 23 Apr '06

23 Apr '06

Marcin wrote > I think I understand your point, although you did not state it directly. > (Please correct me if I'm wrong) you believe basic_ptree class has some > value, and meets boost quality standard. On the other hand you think that > parsers that accompany it do not. I dont have a strong opinion one way another about the parsers meeting or not meeting boost standards. I just want to make shur that they get reviewed and let the boost members voice there opinions about them. > However, I'm also sure you are aware of the fact that without _any_ parsers > the library is quite useless. It might still have some obscure uses, but at > least 90% of it is gone. I'm not aware of this. Please explain why the "property container" is useless without a parser. This is the critcal reason why I have issues with this library in its present form. Why is "property container" different from other containers such as vector or map in this regard. > Therefore I can only agree to your proposition if > at least _one_ parser is included with the library. Which one is another > issue, but I believe it should be XML. That may be accaptable. However, its the XML parser that is my main concern. That would be the one that I would save for a later review. > Also please note that while at the moment some parsers may look ugly, it is > the implementation that is ugly, not the interface. And implementation can > be safely improved while the library is already in boost. Noted. Tom Brinkman Boost Review Wizard

2 1

[Property Tree] Some initial Review Thoughts / Questions
by Jeff Garland 23 Apr '06

23 Apr '06

This isn't my full review, just a few issues I see. I think this library has great potential and value, but I'm going to stick to the issues for now. I posted most of this just before the review, but got no response: http://lists.boost.org/Archives/boost/2006/04/103305.php I see 3 serious issues at this point: 1) Find is under documented / doesn't work for me ptree pt; read_ini("test.ini", pt); ptree::const_iterator ci = pt.find("value2"); if (ci != pt.end()) { std::cout << ci->second.data() << std::endl; } //test.ini [User Data] ; This is a comment value1 = v1 value2 = v2 date = 2006-Apr-18 I tried various keys in the find including: ptree::const_iterator ci = pt.find("User Data.value2"); All returned null iterator. So there are two problems. From the docs it wasn't clear what syntax to use with find and it doesn't appear to work. 2) Iterators are underspecified It was totally unclear to me from the docs what the interface to iterators returned from the interface. I finally found a test or example and copied. std::cout << ci->second.data() << std::endl; 3) Write operations are not 'whitespace' and comment preserving To me this is a critical point not fulfilled by the library. Most real-world configuration files have comments. If the application needs to read/write the files it needs to maintain the comments as human written. In my experiment if I start with this: //test.ini [User Data] ; This is a comment value1 = v1 value2 = v2 date = 2006-Apr-18 After I write it back I get: [User Data] value1=v1 value2=v2 date=2006-Apr-18 I realize that this requirement might increase the resource usage of property_tree, so I'm fine with this being an optionally enabled feature. Jeff

4 5

Re: [boost] [Boost Review] Property Tree Library
by Tom Brinkman 23 Apr '06

23 Apr '06

*>What value does the library have, if there are no parsers to get >a property tree from or to write it back to a file? > >* > I fully agree with this point. Removing the parsers from the review > makes the library essentially useless. They are an important part of the > functionality the library provides. A simple string tree is not enough > functionality to be relevant; if only a tree was to be submitted, I'd > expect it to be a fully generic tree. Please, RE-READ what I said. I want this review broken up into two parts. I said nothing about the value of this library being useless without the parsers. Thorsten, please contact me off-list about this.

3 2

Re: [boost] [Property_tree review] Summary of enhancements proposed so far
by JOAQUIN LOPEZ MU?Z 22 Apr '06

22 Apr '06

----- Mensaje original ----- De: Marcin Kalicinski <kalita(a)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

4 3

[Property_tree review] Summary of enhancements proposed so far
by Marcin Kalicinski 22 Apr '06

22 Apr '06

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. 2. Split Traits into smaller policy classes. For example KeyPolicy and DataPolicy. Indeed, these two are mostly orthogonal, and it should be possible to replace one without touching the other. 3. Allow use of other data types as keys/paths (for example a vector of ints). Initial support is in the library, but key is still required to support string-like interface. 4. Add possibility to disable indexed lookup, if not required 5. Add possibility to specify names of "special" keys in parsers (<xmlattr>, <xmlcomment> etc.). Add whitespace-handling flags to XML reader. 6. Add "set" function. "set" will work in a similar fashion to put, except that it will always replace existing key if it exists. Extra boolean parameter to put functions will be gone. Alternative approach is to replace bool parameter to put with enum to improve readability. 7. Add "del" function. Del will erase existing keys from the tree, while presenting get/put/set style interface. This is clearly missing, although not immediately obvious. 8. Add support for array-style indexing in paths. This will probably work well with #1. 9. Add support for serialization of ptree objects 10. Add possibility to iterate over the whole tree in one go 11. Use multi_index internally for indexing 12. Make get/put functions freestanding 13. Add more docs on customizing key/data types. 14. Improve docs grammar/style in places. Break large index into smaller files. Additionally there were proposals to use runtime polymorphism to distinguish between leaf and branch nodes. I think this idea strays so far from current implementation/interface of the library, that it is not feasible to do. I hope this will serve as a basis for continued discussion. Best regards, Marcin

2 1

Serialization and Editing Archives
by Robert Ramey 22 Apr '06

22 Apr '06

I've been looking at the posts regarding the Property Tree Library. I haven't had the time to give it a proper review. Fortunately it seems that there are a good number of people willing to help with this. I would like to make some observations regarding the serialization library and the creating of "editable" archives. This seems to me the central issue being discussed. The fundemental notion that the serialization library is meant to address is the deconstruction of an arbitary set of C++ data structures into a series of bytes in such a way that the original set can be restored at another time and place. The requirements for such a library were a) completeness - basically no constraints on the C++ data structures to be saved/restored. b) factoring out the actually storage of the bytes in such a way that this could be changed by the user to suit his application. c) minimal effort - the the library has to leverage on the structure of the data as described by the C++ code itself rather than than requiring some extra specification as to how all the data is organized and related. This goal has been in large part achieved with the help of many people on this list, The set of requirements was demanding, and required lots of code to implement. Much of that code had to relie on more demanding techniques such as template metaprogramming. Also, in some cases, extra information had to be be appended to "reflect" information necessary for the implementation. BOOST_CLASS_EXPORT is an example of this. In addition a number of user customizable attributes had to be defined to permit the library to be applied as widely as was reasonable to expect. I know not everyone is totally happy with the library but all in all I'm satsified that a good balance has been struck. The goal and requirements dictate that the resultant archive (however it is stored is dependent on the C++ data structure defined at compile time and invoked at runtime. In general, one cannot expect that any changes in an archive will possible without changing the C++ data structures and code to which the changes correspond. Note this is an entirely reverse situation to the most common one exemplified by doing something like parsing an XML file. In this case one will load the data into some dynamic data structure which will reflect the structure of the data being loaded. At that point some code will have to traverse the structure to extract or set the data in memory. Note that there is no requirement that the C++ data structures map in any special way to the file. Also the file doesn't have to include as much "detail" because it doesn't have to reconstruct an arbitray set of C++ data structures. And of course we see and will continue to see a proliferation of file formats and programming modules to support them. Some attempts have been made to map serialization to some formats which permit arbitray data - XDR and a couple of others. I don't think they've been successful because part of the file format is really held in the C++ code which saves and loads the archives. The requirement to be able to arbitrarily edit an archive is clearly not possible. But then ... it seems tantalizingly close - I meant hell its XML I can read it!. So could anything be done? I haven't spent too much time on this but I can speculate some. Suppose one wanted to create and editable XML format. First of all on will have to accept the fact that not all editing is going to be possible. One won't be able to make a new class which the C++ code doesn't implement. I might be possible to do something like the following; a) parse the whole XML file with a standard parser b) as the serialization algorithm visits each data structure, ratther than just presuming that all the data is there in sequence, it would check to see if the tag has been loaded.. This would permit the following types of editing: i) deletions ii) changing data A little more work would permit expanding / contracting collections. I really don't know how much work this would end up being but no one has had sufficient interest to undertake it - or perhaps they have but it hit a dead end. To summarize I see two almost irreconciliable paths a) Archive formats reflect the set of C++ data structures which generate them b) A format for arbitrary data (e.g. XML) is defined and a general- not application specific - data strucure (e.g. tree) is defined. Then the application walks the tree in an application dependent manner. Basically only one thing can be boss - either the C++ data strucures in the app or the file format. one can drive the other but they can't be varied independently. It seems to me that the property tree library is driven by the need to be able to edit one's "serialized" data out side the main application. My personal view is that if one feels that he needs to do this - he should be rethinking his application. A huge portion of applications are really variations on just this theme: Load some data, edit it, save data. And its not just word processors or things like that. Machines startup, run, and shutdown. a customer recored is accessed, updated, and saved. etc. So I think many more applications can be considered in terms of serialization than in fact are. The applicatons edit data. There can also be the case where different applications edit the same data. I might make an application which loads configuration, runs a machine and save the data from the run. Someone else needs and application to browse and/or annotete the the data. One could say - oh then we need the data in some application independent manner such as XML. Well that's one way - but then we have to recode all over again to get and save the data. Or we can use something like a text editor but then we are casting aside all the facility of using a computer in the first place. Finally we can make a new application which used the original C++ serialization code and data structures - which hopefully have been compiled into a library. Now we just use our special editor for that "other" applicaion. To me - definition of a file format independent of the C++ code which is going to use has wasted billions of man years of human brain time just trying to keep things in sync. So, I see the whole XML approach as a misguided attempt to separate the fundementally inseparable - data and code - they are one now. I predict that XML will be made continually more elaborate and spawn ever more variations in vane attempts to reconcile the unreconcilable. Remember you heard it here first - XML and is progeny is destined for the ash heap of history! (hmmm - like COBOL?) For someone who has nothing else to do there are interesting things to look at here. What would be very interesting would be a xml_archive which created in parallel an (XML?)_schema which would be used by a generic editor to edit the xml (and maybe other) data in the archive within the bounds of what is permitted. I see this as quite doable. Another idea would be a generic editor which could be compiled from the serialization code which would exploit the "reflected" data about the C++ and perhaps define a little bit more. For example I could imagine a template for each datatype which would invoke a functino to edit it. On a GUI, just compile the generic editor with your own serializtion code. and BAM you've got an application specific editor which runs at full runtime speed. Just a couple of misceleaneous observations a) It seems there is a perception that the serialization library is large, cumbersome and inefficient. I believe it can be used inefficiently (like all libraries) and it can be made faster (and incremental improvemetns are being made). But I don't think this is true in general. When I compile with release mode, make sure I haven't included in the debug symbols, and use the DLL (which isn't all that big), a program which saves and loads 4 different types of archives with several classes only takes 30 KB. So if you're not getting similar results, take a closer look. b) much has been made of things like - you can't turn off tracking etc and the difficulty of modifying the library. I believe that most of these difficulties comeabout by tyring to implemnent some external requirement - which I've called about trying to reconcile the irreconciable. If one turns off tracking- then how is one going to recoveer pointers. By default, someting track only if its used as a pointer somewhere. And why would one have pointers in something like configuration parameters. And if tracking is turned off and somethng is duplicated - then what if one edits only one of the copies. etc. Its not so much that I want to dicuss tracking- its more that I think these kinds of questions reveal that things originally thought to be almost identical e.g and XML archive and general XML file are more different than they first appear. So when this occurs its time to step back and look at the big picture (BTW I believe it would be easy to suppres the object_id etc in he xml archive just be overridding with stubs the serialziations for these types - but then how would one read the archve?) Anyway - I'm sorry if this is a little rambling and off topic Robert Ramey

1 0

Re: [boost] Do really property_tree and program_options overlap?
by Matt Doyle 21 Apr '06

21 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcin Kalicinski > the lot. You can use BOOST_FOREACH on it. You can use > algorithms on it (just keep in mind it is not sorted by key > unless you do that explicitly). Are you talking about basic_ptree::sort? Or pre-sorting the keys before populating the tree? Scanned by McAfee GroupShield {X3BTB534}

2 1

[Property tree review] Error in docs
by Marcin Kalicinski 21 Apr '06

21 Apr '06

I just noticed there is a serious error in docs, it states that parsers are in namespaces of their own, (e.g. read_xml is in namespace boost::property_tree::xml_parser). This is correct, but they are also all imported into boost::property_tree namespace by means of using declarations. And they should be used from there. Their presence in other namespaces should be considered an implementation detail, and obviously not documented. I will fix that after review completes. In the meantime please bear in mind that there's not so much namespace bloat as the docs purport ;-). One reason that parser functions _must_ be in property_tree namespace is Koenig lookup, e.g.: boost::property_tree::ptree pt; read_xml("x.xml", pt); // Koenig lookup here Lookup above obviously relies on read_xml being in the same namespace as ptree. Marcin

3 3