July 2008 - Boost - lists.preview.boost.org

Re: [boost] Any interest in generic sequence searching through single-pass iterators?
by dpxguard-boost＠yahoo.gr 04 Jul '08

04 Jul '08

Jim Xochellis wrote: > > I have written in my free time the "single_pass_search" C++ template function, which performs generic sequence searching similarly to the std::search STL algorithm. The most important quality of single_pass_search and its main advantage over std::search > > is its capability to search for a sub-sequence in a search-range that is accessed through a pair of single-pass (input) iterators, while std::search requires that the search-range must be accessed via forward iterators at least. Mathias Gaunard wrote: > I guess it could be interesting to overload std::search to work with > input iterators too. > There is no need to give it a different name. Unfortunately, I cannot think of a way to "overload" std::search to work with input iterators, without changing its behavior significantly. Please see the section "Oddities and drawbacks" of the Home/Algorithms/single_pass_search/single_pass_search.html documentation file in the "Boost File Vault", for more details. Best regards, Jim Xochellis ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

1 0

Any interest in generic sequence searching through single-pass iterators?
by dpxguard-boost＠yahoo.gr 04 Jul '08

04 Jul '08

Hi list, I have written in my free time the "single_pass_search" C++ template function, which performs generic sequence searching similarly to the std::search STL algorithm. The most important quality of single_pass_search and its main advantage over std::search is its capability to search for a sub-sequence in a search-range that is accessed through a pair of single-pass (input) iterators, while std::search requires that the search-range must be accessed via forward iterators at least. For example, single_pass_search can easily search a file directly through a pair of istream iterators, while std::search requires the interference of an intermediate container in order to obtain the file data via a pair of forward iterators at least. With data sources like istream, using single_pass_search instead of std::search is by far simpler, more efficient and less memory consuming as well, because the std::search algorithm additionally requires an intermediate container and some stream buffering logic. Anybody interested? For more information, I have uploaded in the "Boost File Vault" the following files: Documentation: Home/Algorithms/single_pass_search/single_pass_search.html Implementation: Home/Algorithms/single_pass_search/single_pass_search.h Example: Home/Algorithms/single_pass_search/Example..cpp Best regards, Jim Xochellis ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

2 1

[1.36.0] Final requirements for directory and file names
by Beman Dawes 04 Jul '08

04 Jul '08

The final requirements for directory and file names are now posted at http://beta.boost.org/development/requirements.html#Directory_structure These are now stable for 1.36.0. Hopefully they will also be stable for quite some time beyond 1.36.0. The inspect program has been updated accordingly. --Beman

7 12

Compile time maths/square root?
by Joseph Gauterin 04 Jul '08

04 Jul '08

Does boost have a library of compile time maths functions? I've only been able to find GCD and LCM algorithms (boost/math/common_factor.hpp) If such a library exists, it would be worth adding a summary of them to /libs/math/doc/html/index.html In paticular, I was looking for a compile time integer square root function.

2 1

[extension] load_single_library() - silent failure?
by Robert Dailey 04 Jul '08

04 Jul '08

When calling load_single_library(), if the 3rd parameter, which is the name of the export factory function, is incorrect, load_single_library() will silently fail and return as if nothing went wrong. However, since the name of that function was mistyped (in my case), I had to debug into the boost.extensions library to figure out the actual source of the problem. I think this should have thrown an exception. For example, I called the function like below: factory_map fm; load_single_library( fm, "my_library.dll", "my_export_method_typo" ); And my function, as defined in the DLL source, is as follows: extern "C" void BOOST_EXTENSION_EXPORT_DECL my_export_method( boost::extensions::factory_map& fm ) { } As you can see, the string (in the first code example) is clearly mistyped/misnamed. This results in silent failure. Opinions on this would be useful.

2 2

[property_tree] XML parser errors
by Preston A. Elder 03 Jul '08

03 Jul '08

Hey, This is not a new issue, but a quick search sees it not reported. Each of the XML parsers that are available for property_tree has a problem, with the exception of the TinyXML version (which is annoying because it requires an external lib). - RapidXML (the default) Lines 95 and 98 of xml_parser_read_rapidxml.hpp need to be changed from this: if (flags & no_comments) doc.parse<parse_normalize_whitespace>(&v.front()); else doc.parse<parse_normalize_whitespace | parse_comment_nodes>(&v.front()); to this: if (flags & no_comments) doc.template parse<parse_normalize_whitespace>(&v.front()); else doc.template parse<parse_normalize_whitespace | parse_comment_nodes>(&v.front()); Without this change gcc 4.2 won't compile them (not sure about other versions of gcc). - PugXML Line 1827 of pugxml.hpp looks like: class xml_iterator : public std::_Ranit<_Ty,_Diff,_Pointer,_Reference> I don't know about anyone else, but my STL doesn't have a _Ranit class, and depending on non-standard components is a bad idea for portable code. - Spirit It fails to parse some XML that is perfectly valid under the RapidXML and and TinyXML versions. On the plus side, it compiles out of the box ;) I'm not 100% sure what it is, I get this error: terminate called after throwing an instance of 'boost::property_tree::xml_parser::xml_parser_error' what(): <unspecified file>: invalid character entity Aborted Here is a trimmed down XML file that should work fine, and does under rapid and tiny: <log> <formatter type="literal" name="BEGIN"> <string>TEMP</string> </formatter> <appender type="file" name="FILE"> <filename>test.log</filename> <formatter>BEGIN</formatter> <truncate>true</truncate> </appender> <logger name="test"> <threshold>10</threshold> <appender>FILE</appender> </logger> <fallback>test</fallback> </log> I don't see anything specifically wrong with this. Note however, that using spirit on a DIFFERENT xml file that imho is significantly more complex and larger parses just fine with spirit (I would paste it, but it >2.5k). PreZ :)

1 1

[filesystem] Change "remove" function's return to void?
by Beman Dawes 03 Jul '08

03 Jul '08

The remove(p) function is currently specified to return a bool with a value of exist(p) before the post-condition is established. The post-condition is !exists(p). The original thought in providing this was that the return value might be useful and would cost nothing. It turns out that providing this return value does have several costs: * A call to exists() could be omitted if the actual system removal call succeeds. exists() is surprisingly expensive on some operating systems. * It makes the remove() function less reliable in that it introduces a potential race condition. * It makes flow of control more complex (and thus harder to test) for some implementations. Thus I'd like to change the return to void. Although that will break some code, the breakage will result in a noisy compile-time error that is easy to fix by inserting a call to exits() before the call to remove(). Comments? --Beman PS: This was precipitated by ticket #1972, but doesn't affect the resolution of the remove() issue it raises. That will be fixed for 1.36.0 regardless.

4 4

boost::exception lib question
by Tom Brinkman 03 Jul '08

03 Jul '08

Is there a way to delay throwing an exception? Reason #1 Sometimes, one may want to accumulate all error conditions, but ignore them unless a fatal error condition occurs. These non-throw errors might be considered warnings, but useful to report if a later fatal error conditions occurs. Reason #2 It may be preferable to report all errors at once and not have a throw after each error. Waiting to throw the error may provide for more complete error statements. Example: my_error error; error << error1("aaaaa"); error << error2("bbbbbb"); .... <later> throw error << error3("cccc");

2 1

[allocators] Article and library about allocator improvements
by Ion Gaztañaga 03 Jul '08

03 Jul '08

Hi, While developing of Interprocess, I started to think about optimizations for STL-like allocators. I even wrote a proposal about some new features for standard containers (N2045, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html) that was not received with much interest by the committee. I refined those improvements for shared memory containers and I measured performance benefits when containers take advantage of more advanced allocators. The last few months, I've taken another step forward and I've developed a small Boost library based on a modified DLmalloc code. I've developed some allocators above the modified DLmalloc and I've measured the performance benefits that can be obtained with optimized allocators that offer some new features like buffer expansion, burst allocation, etc... Test were performed using Interprocess containers, but instead of shared memory allocators, I've compared DLmalloc based heap allocators against the standard std::allocator<>. I've written a long article with my explanations and conclusions: http://www.drivehq.com/web/igaztanaga/allocplus/ The library (includes the article) can be downloaded here: http://www.drivehq.com/web/igaztanaga/allocplus.zip The library has no docs (the article explains all the basics) and does not surely meet Boost standards. The only goal of this article, the library and this post is to share information with other Boost container authors and discuss possible improvements that maybe could be applied to Boost containers. If those improvements are considered interesting, it would be great if we could write a library with allocators and develop some "existing practice" with boost containers before writing a future proposal to improve allocators. I plan to publish the article somewhere (supposing someone is crazy enough to publish it ;-) ) but first I wanted to share this with boosters to try to improve the article/library and know if developers are interested in allocator issues. Comments are welcome! Regards, Ion

5 11

[filesystem] Function name changes
by Tom Brinkman 03 Jul '08

03 Jul '08

>> p.base_name() == base_name_prefix(p) + base_name_extension(p) Yep. These are much better names. I think I must have looked at the help file at least 5 or 6 times to find out what "leaf" means.

1 0