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

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