- Boost - lists.boost.org

[test] msvc problems with user-testcase, shared_ptr and quick allocator
by Juergen Hunold 21 Mar '06

21 Mar '06

Hi ! I've been playing around with boost test and tried to run my test on my win32 box (after a needed hardware upgrade and reinstall) using msvc 7.1. To my surprise the tests don't run anymore. I've tracked this down to the attached minimal testcase (using V2). I admit that my setup is somewhat unusual, but now for the story: I use: - a user defined testcase ( to set up a lot of things in my tests, omitted here.) - our project uses BOOST_SP_USE_QUICK_ALLOCATOR to speed up shared_ptr. (proven to boost performance by 50%) - is multithreaded. When running the testcase, the test runs smooth, but then the msvc debug-runtime bombs at program exit and fires up the debugger. It claims it has detected a memory leak. The start of the message (see result.txt in attachment for full output): ====== BEGIN OUTPUT ====== Running 2 test cases... user_testcase.cpp(27): error in "Tests::testFailure": failure *** No errors detected Detected memory leaks! Dumping objects -> {173} normal block at 0x00326030, 12 bytes long. Data: <0`2 0`2 > 30 60 32 00 30 60 32 00 CD CD CD CD The cause seems to be some static variables in the quick allocator that are not deleted at program exit. I think this a known issue. I've tried to disable the msvc runtime check but it failed. Using the debugger I've traced this down to boost/test/impl/execution_monitor.ipp and there to detect_memory_leaks (line 623). It seems that the call to _CrtSetDbgFlag in line 629 is somehow failing. Myself being a linux programmer my wisdom ends at this point. This could even be a red herring and the failure might be caused by something else. Query: Can someone reproduce this ? Query: Is this a bug in boost.test, boost.shared_ptr or my fault ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

2 2

Repost: [inspect] Bug report: Terminates with std::out_of_rangeexception
by Andreas Huber 21 Mar '06

21 Mar '06

Hi there The following was posted a week ago: > When I run the inspect tool in boost/libs/statechart (current CVS) I > always get a std::out_of_range exception: > > **** exception(205): std::out_of_range: basic_string::substr > ******** errors detected; see standard output for details ******** > > I tried with vc-7_1 and mingw builds, both with the same result. Does > this ring a bell or should I investigate further? Is this already known and a fix in the works? If the author (Beman Dawes ?) doesn't have time to investigate this, I'd happily give it a try. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

[Boost-bugs] [ boost-Bugs-1455604 ] regex_replace bug
by SourceForge.net 21 Mar '06

21 Mar '06

Bugs item #1455604, was opened at 2006-03-21 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1455604&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: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: regex_replace bug Initial Comment: boost::tregex e("(.*)"); strResult = boost::regex_replace("a", e, "$1b"); strResult now equals "abb", but should be "ab". My e-mail: kdn01003(a)student.mdh.se ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1455604&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-docs] [quickbook] [MPL] Knowing where you are the wrong way (was: Re: know where you are)
by Daryle Walker 21 Mar '06

21 Mar '06

[I've added the main Boost list to this response so the MPL guys can see it.] On 3/16/06 5:46 AM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: > In the link I presented a while ago (http://snipurl.com/no8s) > you might have noticed that the headings are clickable. > Headings now link to itself. Again, this is borrowed from > the MPL docs. This allows you to right click and copy > the URL, for example (especially useful in deeply nested > sections). You know where you are, anywhere. [That URL is <http://spirit.sourceforge.net/dl_docs/quickbook_doc/quickbook/doc/html/quic kbook/intro.html>, BTW. Check out the first word "Introduction" right before the quote for the link Joel is talking about.] I've read on some web design website that this is horrible UI. This is a feature that may be "kewl" for very advanced users, but it's obscure for above-average users, and detrimental to anyone else. 1. This word is an out-link without looking like an out-link. We shouldn't be presenting data like Easter egg hunts. You could counter by saying that the disguise is a good thing to dissuade newbies, but then how could oldbies discover it without looking at the source, scrubbing the page, or reading this e-mail? (It's a variant of guideline #3 at <http://www.useit.com/alertbox/20031110.html>.) 2. Out-links to the same page is confusing to newbies. They'll think "my link click failed," not "it's a mnemonic for my browser's 'copy URL link' contextual-menu function." (It's based on guideline #10 from the web page I mentioned in [1].) 3. You implemented it as: <a name="quickbook.intro"></a><a href="intro.html" title="Introduction">Introduction</a> As I said before, using an empty "<a name>" as an in-link is a bad idea. You need to associate the link with something. AFAIK, nothing prevents an anchor from being an in- and out-link simultaneously: <a href="intro.html" name="quickbook.intro" title="Introduction">Introduction</a> If you don't care about anything before HTML-4, you can use the "id" attribute to mark destinations. (That's why it shares the same namespace as the "name" attribute.) <h2 id="quickbook.intro">Introduction</h2> So my final advice is to remove this mis-feature, and have the MPL docs purge it too. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[Serialization] xml_archive version
by Richard Crossley 21 Mar '06

21 Mar '06

Hi, I'm trying to read in a xml_archive created by a previous version of the serialization library (version="3") with the version from CVS head (version="4"). The reading fails in load_collection here as there is no "item_version" field. if(3 < ar. get_library_version ()){ ar >> BOOST_SERIALIZATION_NVP(item_version); } Shouldn't a xml_archive be doing a set_library_version() based on the version of the archive it's reading, or am I missing something? Regards, Richard.

2 1

[Wave][Serialization] Problems with class versioning
by Hartmut Kaiser 21 Mar '06

21 Mar '06

Hi all, I was trying to add class versioning to the serialization code for the Wave library (for storing macro tables et.al.) but couldn't succeed. I've added a class version to the code by adding: namespace boost { namespace serialization { template< typename Iterator, typename LexIterator, typename InputPolicy, typename Hooks > struct version<boost::wave::context<Iterator, LexIterator, InputPolicy, Hooks> > { typedef boost::wave::context<Iterator, LexIterator, InputPolicy, Hooks> target_type; typedef mpl::int_<target_type::version> type; // version == 0x100 typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; }} // namespace boost::serialization The save function of the context<> now get's called during serialization with the correct version value. But during load the context<>::load function still get's passed zero as the loaded version. Is this a known behaviour, am I ding something wrong (perhaps essential: context is explicitely marked as 'track_never')? Regards Hartmut

2 2

[asio] Formal review results status
by Bulygin, Sergey 21 Mar '06

21 Mar '06

Hello! Let me come up with a question of curiosity. As [asio] formal review began on Dec'10 2005, there was a hope, that [asio] would become a part of Boost 1.34. Then it was taking weeks, but the review result is yet to be announced. Doubts arise of [asio] inclusion into Boost 1.35 already. Could the review manager or [asio] author give a clarification, what is the current state of [asio] formal review? What are the main reasons for formal review results delay? Are the issues raised in the formal review being addressed at that time? But according to the formal review process, this should happen right after the review completion. Sorry for impatience. :) Best Regards, Sergey Bulygin

4 3

[spirit] scanner_value_type_tests
by Vladimir Prus 21 Mar '06

21 Mar '06

Hello! The above test fails on large number of platforms, because of unresolved reference to char_traits<bool>::various_functions. I suppose that char_traits is explicitly instantiated for char and wchar_t for those compilers, so using it with 'bool' just does not work. Looks at the standard, it seems that non-specialized char_traits is not required to provide any member functions at all, so test that relies on any member functions in char_traits<bool> is wrong. Can somebody look into this, and fix the test? Thanks in advance, Volodya

2 1

A bug in smallest_last_vertex_ordering
by Roman Dementiev 21 Mar '06

21 Mar '06

Hi, I believe that boost::smallest_last_vertex_ordering has a bug. I tested the implementation with the CVS version from today. This is one of the graphs where it produces the wrong output: int n = 14; Edge edge_array[] = { Edge(0, 13), Edge(1, 5), Edge(1, 9), Edge(2, 6), Edge(3, 10), Edge(3, 4), Edge(7, 9), Edge(8, 12), Edge(11, 13) }; The attached picture bad_graph.jpg (ignore the directions) is a drawing of this graph. I have attached also a source file with a program that computes a smallest-last vertex ordering. Its output: Smallest-last vertex order: 2 6 10 4 3 5 1 7 9 0 13 11 8 12 The algorithm implementation removes nodes 12, then 8, 11, 12, 13, 0. But then it removes node 9 that has degree 2 at that moment, which is wrong, because nodes with a smaller degree exist (nodes 10,4,2,6,7,5). Can anyone fix this bug? With best regards, Roman #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/vector_property_map.hpp> #include <boost/graph/smallest_last_ordering.hpp> //#include <boost/graph/sequential_vertex_coloring.hpp> using namespace boost; typedef int Node; typedef std::pair<Node, Node> Edge; int main(int argc, char * argv[]) { typedef adjacency_list<listS, vecS, undirectedS> Graph; typedef graph_traits<Graph>::vertex_descriptor vertex_descriptor; typedef graph_traits<Graph>::vertices_size_type vertices_size_type; typedef property_map<Graph, vertex_index_t>::const_type vertex_index_map; int n = 14; Edge edge_array[] = { Edge(0, 13), Edge(1, 5), Edge(1, 9), Edge(2, 6), Edge(3, 10), Edge(3, 4), Edge(7, 9), Edge(8, 12), Edge(11, 13) }; int m = sizeof(edge_array) / sizeof(Edge); Graph g(edge_array, edge_array + m, n); std::cout <<"Number of nodes: "<<num_vertices(g) << std::endl; std::cout <<"Number of edges: "<<num_edges(g) << std::endl; std::vector<vertices_size_type> degree_vec(num_vertices(g)); std::vector<vertices_size_type> marker_vec(num_vertices(g)); vector_property_map<vertex_descriptor> order(num_vertices(g)); typedef iterator_property_map<vertices_size_type*, vertex_index_map> degree_i_map_type; iterator_property_map<vertices_size_type*, vertex_index_map> degree(&degree_vec.front(), get(vertex_index, g)); iterator_property_map<vertices_size_type*, vertex_index_map> marker(&marker_vec.front(), get(vertex_index, g)); typedef boost::detail::vertex_property_map<Graph, vertex_index_t>::type ID; typedef bucket_sorter<vertices_size_type, vertex_descriptor, degree_i_map_type, ID> BucketSorter; BucketSorter degree_bucket_sorter(n, n, degree, get(vertex_index, g)); smallest_last_vertex_ordering(g, order, degree, marker, degree_bucket_sorter); std::cout << "Smallest-last vertex order: "; for(int i=0;i<n;++i) std::cout << get(order,i) <<" "; std::cout << std::endl; return 0; }

2 4

[functional] boost::hash with 64-bit types
by Alexei Alexandrov 20 Mar '06

20 Mar '06

Hi boosters, I believe this question should already have been raised but I can't find any info on this: Why boost::hash is not specialized for 64-bit types by default? Is there any reasonable reason for that? Thanks a lot for the answer and for Boost itself. -- Alexei Alexandrov

3 7