- Boost - lists.boost.org

Boost.StringAlgo:library defects?
by Mathias Gaunard 29 Jul '09

29 Jul '09

As I integrated my Unicode library with Boost.StringAlgo, I noticed a few issues: - The Finder concept seems inappropriate, since find_iterator<last_finderF> can't work as expected. I suggest building left-to-right and right-to-left searching directly into the Finder concept. - Certain functions that take ranges only take Range& and not const Range&. Interestingly enough, in the cases where I've found it does that a const Range& would have been enough. - Usage of the Finder concept is incompatible with its definition. Indeed, finders are passed by const reference, which means the operator() must be const, unlike in the examples. - Finders are explicitly calling boost::as_literal on the string to search for, which I believe should not be their responsibility but that of the callee (or not, but I would have expected a rationale at least). - Why is there no trim variant that simply returns a sub range of the input range? There are only ways to modify the sequence in-place or copy a trimmed one. - Algorithms such as find being pushed in the boost namespace is incompatible with, for example, updated version of Boost.Range (Boost.RangeEx). Since boost::algorithm::find is quite different from std::find, it should not be promoted to boost::find. Since the library is fairly old (2002), I assume some of these issues are known. Is there any plan to fix them?

2 1

proposal - Statistically robust function timing for performance decisions.
by Edward Grace 29 Jul '09

29 Jul '09

Dear All, Having developed what I think is an easy to use C++ library for the robust and statistically meaningful timing of functions I'm looking to place it under the terrifying glare of peer review and to find a home for it. My motivation for its development was simply to be able to state: "Function 'foo' is between 'x' percent and 'y' percent faster than function 'bar' at the 95% confidence level." since I wish to make reliable, automatic, informed decisions about function choice at run-time. While this looks like a trivial problem - it is not! Being able to determine some confidence limits on the relative speedup, particularly when other user processes are active, turns out to be quite challenging. I am aware of code snippets such as http://www.boost.org/doc/libs/1_34_1/libs/multi_index/perf/ test_perf.cpp based on wrap_code.cpp and, while it's better than many approaches, I'm dissatisfied with it. It's not as reliable as one might think at first blush. I am also aware of the timing code used internally in FFTW for selecting codelets - while it may be appropriate for this type of application I do not view it as a reliable general solution to the problem. I strongly suspect that many people reinvent the wheel regarding this problem and make decisions in an ad-hoc manner. There certainly doesn't seem to be a standard and reliable solution. I'm not sure whether Boost is an appropriate home for such a (compile time) library. Is this something anyone 'out there' would be interested in? If it's not the right place - does anyone have any suggestions other than sourceforge.net? I look forward to your responses. Regards, -ed P.S. A typical example of its use is presented in the output below. Here we time two simple and otherwise identical functions, one of which (a) iterates 1000 times, the other (b) 1005. Once we demand of the timer a nominal percentage precision approaching the difference in expected run-time (0.5%) they can be discriminated successfully. It should be noted that this was carried out simply using gettimeofday () while significant user processes were present! ================================== Calibrate overhead (0,1)? 1 Point estimate of clock overhead (t_c): 0.0975994 Potential jitter on t_c : 0.633371 Increasing precision until I can discriminate between function a and b. The nominal confidence interval represents the region: 1-alpha=0.95 Timing at a nominal precision of: 50% 0 1.82141<--- Uncertain. Timing at a nominal precision of: 10% 0 2.00391<--- Uncertain. Timing at a nominal precision of: 2% 0.383285 0.593955<--- Ok. Timing at a nominal precision of: 0.4% 0.411541 0.62412<--- Ok. Timing at a nominal precision of: 0.08% 0.448847 0.582617<--- Ok. Nominal confidence bounds on percentage speedup of A relative to B: 0.448847 [0.516456] 0.582617 ================================== ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997

6 13

Problems with inspection output page for trunk
by Daniel James 29 Jul '09

29 Jul '09

---------- Forwarded message ---------- From: Jeremiah Willcock <jewillco(a)osl.iu.edu> Date: 2009/7/29 Subject: [Boost-docs] Problems with inspection output page for trunk The page at http://boost.cowic.de/rc/inspect-trunk.html is an error message, not a valid inspection report output. The version for the release branch is fine. Could you please take a look at it? Thank you. -- Jeremiah Willcock

1 0

[property_tree] RapidXML needs updating
by Preston A. Elder 29 Jul '09

29 Jul '09

Hi, There is an existing problem with the version of rapidxml included with boost::property_tree (from the trunk, I have this as an SVN external into my own repository for my own project in preparation for it getting into boost proper). If I have something like: <field> </field> The intention is obviously to have the value of field be a space. Since spaces are trimmed and condensed, something like: <field> </field> will not work. It seems that condensing of whitespace is happening AFTER the expansion of the &#xNN; expansion (similarly with &#NNN;). This is obviously an error, because otherwise there is no way for me to have a space as the first or last character (or have multiple spaces in a row). It seems this bug is coming from RapidXML itself. I noticed the version of RapidXML is 1.0. So I downloaded the new version of RapidXML (1.13), and made the necessary changes in xml_parser_read_rapidxml.hpp (namely changing first_child() to first_node() ) and the above problem is fixed. So I would like to request that whoever is maintaining this update the version of RapidXML to the latest one available from the RapidXML website. As an addendum, it would be REAL nice if one could use flags to turn on or off string condensing and trimming. RapidXML provides options for both. Oh, and you might also want to fix this warning: In file included from /sandbox/mantra/trunk/Mantra-I/boost/property_tree/detail/json_parser_read.hpp:18, from /sandbox/mantra/trunk/Mantra-I/boost/property_tree/json_parser.hpp:14, from /sandbox/mantra/trunk/Mantra-I/src/core/admin/command.cpp:20: /sandbox/boost/boost/spirit.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic.hpp" (Remember that I have property_tree as an SVN external pointing to the property_tree directory in boost's trunk, so the above IS current boost head code). Minor issue. PreZ :)

3 3

Building BJam and Boost in Sun's Virtual Box
by Monte Jones 28 Jul '09

28 Jul '09

Hi All, I need to be able to use Boost in a virtual environment, specifically, Sun's Virtual Box. I'm further limited in the company I am working for has not approved any Boost upgrades since 1.34 for use. I thought the best way to approach this would be to build Boost Jam and then Boost within the virtual box. Below is what I've done so far. Downloaded platform independent zip files for Boost Jam 3.14.1 and Boost 1.34.0 and saved into directory I called Boost cd Boost unzipped both files cd boost-jam-3.1.14 sh ./build.sh I received the following: ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: {^M: not found ./build.sh: ^M: not found ./build.sh: syntax error at line 67: 'elif' unexpected I then attempted sh ./build.sh sunpro and got ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: {^M: not found sunpro ./build.sh: sunpro^M: not found ./build.sh: syntax error at line 67: 'elif' unexpected Thinking I may need administrative privileges, I did su root and reran the same commands with the same results. I had previously built these versions on a Sun 4800 without problems. Could these errors be the result of running in a virtual box with WindowsXP as the base operating system and an Intel Pentium 4 CPU? Any advice would be greatly appreciated. Thanks, Mont

3 3

[asio] Closing posix::stream_descriptor sets it back to blocking
by Preston A. Elder 28 Jul '09

28 Jul '09

I have two posix::stream_descriptors to the same element, in this case, a dup() of the STDIN_FILENO, reated as such (basically): class MyClass { char buf[4096]; posix::stream_descriptor in; void read(const system::error_code &err, size_t xfer) { // Do something ... then ... in.async_read_some(buffer(buf, 4096), &read); } public: MyClass(io_service &svc) : in(svc, dup(STDIN_FILENO)) { in.async_read_some(buffer(buf, 4096), &read); } }; MyClass *myc; // ... io_service svc; void init() [ char buf[4096]; posix::stream_descriptor stdin(svc, dup(STDIN_FILENO)); stdin.async_read_some(buffer(buf, 4096), &read_func); while (!myc) sleep(1); } // ... void read_func(const system::error_code &err, size_t xfer) { // ... do some stuff ... myc = new MyClass(svc); } The reason I do this is a design one, and it's a lot more complicated than the above, but suffice to say there are lots of other factors involved, and I cannot just pass around the stdin object and send it to the constructor of my MyClass. Making multiple dup's of STDIN_FILENO is really not a problem. And having them in posix::stream_descriptors means they even get cleaned up nicely. That's all well and good, but the problem comes in with how stream_descriptor handles non-blocking I/O. When I do my async_read_some on the stdin object (created in init()), it sets non-blocking I/O, and then sets a flag inside the stdin object. When I create the in object inside of MyClass, it thinks the socket is non-blocking, but when I call the async_read_some function on THAT object, it again sets the FD to non-blocking I/O and sets the internal flag. A little redundant but I can deal with this. In reality that flag should be set by finding out what the blocking state is rather than assuming it's blocking. Here is where the problems start. When the stdin object is destructed (goes out of scope), it CHANGES the blocking state to blocking (because the internal flag says it's non-blocking) before it closes the FD. The code that does this is in detail/reactive_descriptor_service.hpp in both reactive_descriptor_service::destroy() and reactive_descriptor_service::close(). Because both objects are dup's of the same source FD, they all share blocking state, and this now sets my in object inside of MyClass to blocking I/O - without changing the internal flag. Meaning that when I DO get some data, and call MyClass::read, and then go to call async_read_some, now this will be a blocking call because reactive_descriptor_service::async_read_some() sees the flag already set indicating we are non-blocking, and will not re-do it. There is no reason to change the blocking state on a descriptor you are just about to close or destroy. The very idea seems just wrong, you're about to make the descriptor invalid, yet you take the time to change it's blocking state before it becomes invalid? To what purpose? Additionally, there is no way to manually OVERRIDE this internal state with boost calls. For example, executing the following: posix::stream_descriptor::non_blocking_io nb(true); in.command(nb); Will just set a FLAG inside the reactive_descriptor_service that says the user wants the handle to go to non-blocking mode when the next blocking action takes place. It does not alter the state immediately. And since the internal flag state (which is now wrong) is checked first, setting this flag has no effect. The only thing in the end I can do is manually call ioctl myself in my code the first time MyClass::read() is invoked. This then basically makes the blocking state match the internal flag of the 'in' object and from then on everything is fine. But this is klugy. So I would like to request the asio maintainer either a) STOP setting the object back to blocking on close/destroy, given that it serves no purpose when you're just about to close the damn descriptor anyway. b) Set the internal blocking state flag based on the actual blocking state on construction, rather than just assuming it's non-blocking. And c) provide a way to actually change the blocking state of the descriptor, rather than just setting a flag saying we want it changed when you next go to do a blocking I/O operation. There may be a good reason to make such a request, such as the user knowing the state has changed without the reactive_descriptor_service having any knowledge of it, such as in this case. PreZ :)

1 0

[1.40][release][bug-spring] Release Notes
by Daniel James 28 Jul '09

28 Jul '09

Hi all, Since we're moving towards the release, this would be a great time to add your release notes to the site. As always, if you can't or don't want to update the website, reply to this email and I'll do it for you. Also, if you've fixed anything in the bug sprint that's worth mentioning, it should probably be in there. Daniel

2 2

proposal for tree container
by Kasper Peeters 28 Jul '09

28 Jul '09

Hi all, On a regular basis, users of my 'tree.hh' library ask me whether I would be interested in submitting it to boost. As you may have guessed from the name, tree.hh is a templated n-ary tree container class in the spirit of the STL, but of course deviating from it in the sense of offering various ways of iterating over the tree. More info at http://www.aei.mpg.de/~peekas/tree/ Back in 2002 I tried to estimate the interest for inclusion in boost, see http://lists.boost.org/Archives/boost/2002/10/37383.php The most serious criticism back then was the 'lack of abstraction' (for more details please consult the original thread), and I didn't have the time to address that. Given the continuing interest by users of tree.hh to propose it for inclusion in boost, I would like to give this another shot and see what's the current opinion. While I would be happy to clean up the code, I do not have the time to do a substantial rewrite (along the lines suggested in 2002), but would be interested to help someone else do that. License-wise, tree.hh is now available under GPL-2 or 3, but all of the above of course implies that I'd be willing to re-license. Cheers, Kasper

10 13

[test] Documentation license
by Daniel James 27 Jul '09

27 Jul '09

Hi, Would it be possible to add copyright and license info to the test documentation? thanks, Daniel

1 0

Generalized concept usage in Boost libraries
by Mathias Gaunard 27 Jul '09

27 Jul '09

With Concepts removed from C++Ox, people have been disappointed that this chance of making C++ template code generate better error messages was given up. Yet, there is no need for C++0x concepts in order to achieve this. Indeed, we have Boost.ConceptCheck that already makes things a bit simpler. Plus, by extending it with SFINAE for expressions, which allows to detect whether a type models a concept at compile-time, we get almost the same quality in error messages as with C++0x concepts. It would even allow to do concept-based overloading, but since SFINAE for expressions is not an universally supported feature, code shouldn't rely on that. Should all Boost libraries be modified in order to include concept checking, and should it become part of the programming policy? From what I can see, it seems most libraries don't make use of Boost.ConceptCheck at all.

5 7