- Boost - lists.boost.org

[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

boost-style mutable heap
by Tim Blechmann 03 Jul '08

03 Jul '08

hi all, i am curious, is there any attempt to implement mutable priority queues as a boost-style library ... i am familiar with dietmar kuehl's heap implementations, which have never been reviewed nor integrated in boost ... is anyone working on / interested in a mutable priority queue implementation, maybe as part of boost.intrusive? thanks, tim -- tim(a)klingt.org http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage

3 2

A branching/tagging idea for releases
by Daryle Walker 03 Jul '08

03 Jul '08

Here's an idea on how we can manage our source-control for releases: 1. When we're ready to start a new release, make a branch from the trunk with a name like release_1_??_x (e.g. "release_1_37_x") 2. Finalize what needs to be done to make that branch ship-worthy 3. Make a tag from that branch with a name like release_1_??_0 (e.g. "release_1_37_0") 4. Export that tag to a fresh directory and create the appropriate archive file to upload to SourceForge, etc. (The directory shouldn't have any source-control debris in it. Maybe this needs to be done once on each platform to ensure the best archive format and the proper line-ending markers.) 5. If bug-fixes for that release need to be done, continue to use the release_1_??_x branch (and merge the fixes back to the trunk, or vice versa) 6. Make a new tag named like release_1_??_1 and ship it as in [4] for any bug-fix releases (increase the number for subsequent bug- fixes published) 7. New stuff and substantial changes go on the trunk; publish those by going back to [1] with a release_1_(??+1)_x branch -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

6 14

Documentation for Boost libraries
by Edward Diener 03 Jul '08

03 Jul '08

In general Boost has many libraries with good to absolutely first class documentation. Among the many Boost libraries I have used, all with good documentation, are regex, iostreams, function, bind, optional, signals. tribool, tokenizer, and spirit, but of course there are many other libraries with great documentation in Boost. One of my prerequisites for a library with good documentation is that some sort of overview must be given for the functionality of the library so that the end user knows what is available, and what each available part of the library generally entails. For me this overview must be written out and not just given as a series of programming examples, whether in the form of tutorial code, example code, or whatever one wants to call explanations of functionality based almost purely on some hypothetical program or mini-program. In this I may be different from many programmers but I just find it very hard to understand library functionality from example code without basic generalized explanations of functionality. Today, looking for a socket library to use in my C++ code I decided to look at the documentation for ASIO. I was shocked to find out that there is no overview of the functionality of this library at all, but just a series of tutorials and examples and then a reference listing a multitude of classes. I do not believe this is adequate for explaining library functionality and puts a totally unnecessary burden of the end-user when learning the functionality of a library. I would like to encourage Boost developers to always give an overview of the functionality of their library and its general concepts and classes, as almost all libraries currently do. While I am appreciative of tutorials and exmaples as an extra learning device, I do not believe that library documentation should exist with some sort of overview, as mentioned above. I have written this because I am disturbed that ASIO was accepted with the sort of documentation which has been created for it. I do not think such a way of presenting a library is adequate for an organization like Boost whose overall excellence is acknowledged throughout the C++ community.

6 12

[shifted_ptr] STL required modifications
by Phil Bouchard 03 Jul '08

03 Jul '08

Ok, If we comment out line 68 of shifted_ptr_test2.cpp in the sandbox and uncomment line 69 we will get a simplified version of the error messages we used to have with std::vector. It is easier this way uncovering the required modifications necessary to make STL user-friendly with smart pointers. I have also made shifted_allocator the way it should be. Yes it is strange replacing pointers to nodes inside containers and I don't see an urgent need for it but this can help unobfusticating the standards regarding pointers to nodes. Thanks, -Phil

1 0