- Boost - lists.boost.org

Proposal: property_tree rev.2 uploaded to vault and sandbox cvs
by Marcin Kalicinski 15 Nov '05

15 Nov '05

Hi All, Thanks to everybody who took time to look at the library, and especially to those who sent me feedback. Second revision of property_tree is now in the vault as property_tree_rev2.zip (it is now also in boost-sandbox cvs). Outline of the changes: - new methods get_o, get_own_o, get_child_o, which return boost::optional (suggested by Pavel Vozenilek) - added locales support to get and put methods (suggested by Martin) - pointer to bool removed from get_d (suggested by Daniel Wesslen) - ptree/wptree are now case sensitive by default. Added iptree/wiptree which are case-insensitive (suggested by Daniel Wesslen) - fixed multiple definitions bug when including some of the headers in more than one translation unit (spotted by Daniel Wesslen) - added more examples - updated docs and regressions to match current state of library (that was the biggest job actually :-) - hopefully kept the quality high Outstanding work: - XPath-like syntax for retrieving XML attributes (suggested by Caleb Epstein) - ptree mathematical relations (difference, union, intersection) - nice e.g. for tracking config file changes, or combining configs Original message (posted with revision 1): Property tree is a data structure - a tree of (key, value) pairs. It differs from its cousin, "usual" PropertyMap, because it is hierarchical, not linear. Thus, it is more like a minimalistic Document Object Model, but not bound to any specific file format. It can store contents of XML files, windows registry, INI files, even command line parameters. The library contains parsers for all these formats, and more. I tried to make the library as high quality as possible before posting here, so it contains a (hopefully) full documentation, and a comprehensive set of regression tests - more than 300 test cases. By any chance it is not a substitute for (upcoming?) boost XML library - it only supports a fairly narrow subset of XML, and focuses rather on being format-independent. For more curious, excerpt from the doc: Property tree is a recursive data structure that stores a single data string, and an ordered list of (key, value) pairs, where value is a property tree itself. It therefore forms a tree, hence the name. It is a versatile structure that can store in uniform way data coming from various sources, such as XML or INI files, as well as windows registry, program command line etc. Property tree interface is similar to the interface of a standard C++ container. It supports iterators, insertion, erasing, searching etc. One can think of it as a sort of Document Object Model, which is minimalistic, not bound to any specific file format, designed to be easy to use, and comes as Boost-compatible, headers only C++ library. Many software projects develop a similar tool at some point of their lifetime, and property tree long ago originated the same way. I hope the library can save many from reinventing the wheel. cheers, Marcin Kalicinski

1 0

Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging: formalre view)
by Martin Bonner 15 Nov '05

15 Nov '05

----Original Message---- From: Pavel Antokolsky aka Zigmar [mailto:zigmar@gmail.com] Sent: 15 November 2005 14:55 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging: formalreview) > On 11/15/05, Caleb Epstein <caleb.epstein(a)gmail.com> wrote: >> On 11/15/05, Darryl Green <darryl.green(a)unitab.com.au> wrote: >>> >>>>>>>> Ok, will do. >>>>>>> >>>>>>> But note that will can bloat the library. Showing hex data is a >>>>>>> much harder >>> >>> Hex data formatting (or any data formatting) shouldn't be part of >>> the library. Or if it should, it probably means the lib shouldn't >>> be dragging in all that std streams stuff that is supposed to be >>> responsible for formatting... >> >> >> The proposed Boost.Log library already depends (rightly, IMHO) on >> iostreams for message formatting and buffering of >> partially-formatted messages. I can't see why or how this dependency >> could be reasonably eliminated without major sacrifices to the >> usefulness of the library. >> >> The necessary code to do hex dumps on an iostream should hardly be >> considered bloat. I agree with Gennadiy's assesment that 50 lines of >> code should be more than adequate to do it. These can be in a >> separate header file that is included only by the user. What >> possible harm could this be? > > It would not hard of course, but I think this code does not belong to > the logging library. It's such a common requirement that I think it does. > For example, in some cases I do not want to print non-ascii > characters in hex dump, in others I do. ? How does a hex dump contain anything other than hex digits and space (to separate bytes). You might want a way of controlling whether to use upper or lower case letters (but I wouldn't bother). > The grouping depends on length > of the data worlds I'm working with, and also should be configured, > and so on. > My point is that the simple solution is not even worth implementing, > and general solution is definitely out of scope of logging library. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 4

[string_algo] error in example code
by Caleb Epstein 15 Nov '05

15 Nov '05

In: *http://tinyurl.com/b9tjl *Example code shows: typedef split_iterator<string::iterator> string_split_iterator; for( string_find_iterator It= make_split_iterator(str1, first_finder("-*-", is_iequal())); It!=string_find_iterator (); ++It) { cout << copy_range<std::string>(*It) << endl; } string_find_iterator should be string_split_iterator here. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Boost regression notification (2005-11-15 [RC_1_33_0])
by Douglas Gregor 15 Nov '05

15 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-15T14:29:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0

Boost regression notification (2005-11-15 [HEAD])
by Douglas Gregor 15 Nov '05

15 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-15T06:00:10Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 141 failures in 13 libraries: concept_check (12) date_time (2) graph (2) io (1) math (6) mpl (1) serialization (30) spirit (8) thread (4) tr1 (51) tuple (1) typeof (18) xpressive (5) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 mingw-3_4_2 vc-7_1 |mpl| size_t: gcc-4_0-darwin |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_hash: gcc-2.95.3-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

"Re: serialization performance"
by bwood 15 Nov '05

15 Nov '05

Martin Slater wrote: >> //build oArch. >> Ebenezer: >> msgs.Send(buffer, lst); // where I didn't remove anything >> // from Send's implementation. >> >> I think as you say, whether a flush gets embedded in the Send >> function should be configurable, but right now it just is. >> I'll admit it would be better if I didn't have to remove (#if 0) >> the end of the Send function, but I don't think that invalidates >> anything. > >This I humbly disagree with, from a user point of view I would not >want to patch either library to get optimal performance, If it is >there and required then tests need to be done with it in. It would >be simple to speed up boost.serialization by #if 0'ing out per class >meta information lookups (versioning etc) but would still be >extremely artificial. Either way, with or without the embedded flush code, Boost serialization is less efficient than Ebenezer's Send in both tests. Today I timed how long it takes to build the two testcases mentioned in the original post on Nov. 8th. I used the date command so the numbers are only in seconds. list<int> list<int> and deque<int> ----------------------------------------------------------- Boost 42 61 ----------------------------------------------------------- Ebenezer 12 20 >>>It would be interesting to see what the results are with a vanilla >>>version of your library as well as a feature by feature comparision to >>>see if you really are comparing apples to apples. >>> >> Both Boost and s11n.net support things like XML that Ebenezer doesn't. >> Boost in my opinion mistakenly tries to support "versioning." We >> don't and I don't think s11n does either. > >Well since I use versioning heavily with boost.serialization this is >a must have feature for me. What happens if you want to change the type of an existing data member between releases - say from char to short? Brian www.webEbenezer.net

3 3

[multi_index][rfc] random access indices preview
by Joaquín Mª López Muñoz 15 Nov '05

15 Nov '05

Hello, Some months ago I prompted for interest in a new type of indices for Boost.MultiIndex featuring random access facilities, and received a couple of expressions of itnerest. The preliminary specification was published at: http://195.235.93.150/rnd_indices_spec.html I've just uploaded a preview version of random access indices at FileVault -> Containers (http://tinyurl.com/9zlmj) This preview follows the previous specification save for one point: reserve/capacity is provided for control of an internal array of pointers to the nodes, as explained in http://195.235.93.150/rnd_indices_spec.html#interface. There's no docs yet on this type of indices, but the usage should be straightforward from the preliminay specification notes. Random access indices act as a functional drop-in replacement of sequenced indices, so you can start playing with them very easily. My requests: * Do you find these indices worth including in Boost.MultiIndex? * If so, do you have comments on the specification? Things you'd change/add? There's a list of concrete issues at the end of the specification page, * Do you envision any interesting use case for random access indices? Have you experimented with them? Thank you very much for your feddback, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 6

Howto set SONAME (DLLVERSION)?
by Neal Becker 15 Nov '05

15 Nov '05

I want to set SONAME to 1.33, since 1.33.1 should be compatible with 1.33.0. Where/how can I set this?

6 8

[Boost-bugs] [ boost-Feature Requests-1357106 ] darwin 64 bit support
by SourceForge.net 15 Nov '05

15 Nov '05

Feature Requests item #1357106, was opened at 2005-11-15 05:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1357106&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ian Fasel (ianfasel) Assigned to: Nobody/Anonymous (nobody) Summary: darwin 64 bit support Initial Comment: To get 64-bit support, I was able to get a large chunk of boost-1_33_1 to build on darwin by inserting -arch ppc64 in strategic places in the darwin-tools.jam file. This was sufficient to be able to use the filesystem and program-options libraries in a 64-bit app I've built that needs to access > 4GB. Some libraries failed to build however, and I don't really know what I'm doing. Attached is a patch file showing what I added where. Also, it would probably be best to add -arch ppc -arch ppc64 to get "fat" binaries that work for both 32-bit and 64-bit code. However I'm no pro with these things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1357106&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] "Re: serialization performance"
by bwood 15 Nov '05

15 Nov '05

On Mon, 14 Nov 2005 22:24:41 00100 (CET), bwood <brass_at_[hidden]> wrote: >> >> Either way, with or without the embedded flush code, Boost >> serialization is less efficient than Ebenezer's Send in both >> tests. >What are we comparing here? You really need to give the Boost commuinity >more visibility into your code if you expect your arguments to be taken >seriously. There is nothing on http://www.webebenezer.net that resembles >documentation or a complete test application that can be compiled. Hi, Caleb, I'm not sure if I understand your first question. I assume you read the previous posts. I compared the time it takes to serialize/send a list of ints using Boost and Ebenezer approaches. I timed the following Boost: oArch & lst; // using boost 1.33.0 Ebenezer: msgs.Send(buffer, lst); Without making any modifications to the two "vanilla" approaches, Boost takes more than twice as long than Ebenezer. On the surface, the two lines above look similar, but the Ebenezer line is flushing the buffer at the end of the Send function. So the Ebenezer side is doing more functionally in less time. (I've tested this by killing both test cases internally with a raise(9) right after the above lines. The Boost output file has 0 bytes in it. The Ebenezer file has all the data.) So in order to compare apples to apples, I #if 0ed out the flush code. In that case the Boost code is 7 times slower than the Ebenezer and both files have 0 bytes in them. If you want the code I used in these tests I will send it to you. It may be that gcc doesn't optimize the Boost code very well and another compiler would produce results that are better. The documentation is not very good. We hope to work on that. The "Send Sample" compiled last time I checked it. The code in the file MsgManager.h is generated by the site. It is not difficult to obtain that from the site. As far as build times, I agree that they aren't the most important factor. In my opinion they aren't trivial either. Brian

2 1