May 2009 - Boost-users - lists.preview.boost.org

[ANN] Boost 1.39.0
by Beman Dawes 02 May '09

02 May '09

Boost 1.39.0 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

1 0

Recent compilation troubles with gcc atomics
by tom fogal 02 May '09

02 May '09

Hello all, Recently I have noted more than one posting to this list with regards to compilation troubles on some platforms utilizing Gnu C++ or Intel's C++ compiler. Specifically, I am referring to linking errors with some of gcc's internal `atomics' functions, e.g. `__sync_fetch_and_add'. Some searching brings up: http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg197119.h… http://www.nabble.com/Building-for-ARM926EJ-S-td16447579.html http://groups.google.com/group/boost-list/browse_thread/thread/8e757cc2788d… https://svn.boost.org/trac/boost/ticket/2525 http://www.nabble.com/issues-with-unit-tests-on-intel-32-bit,-gcc-4.3,-unde… I also happen to follow the libstdc++ mailing list, which has just seen an elucidating post by Joseph S. Myers: http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html In it, he notes that the availability of these builtins is not solely a function of the compiler version. In particular, the platform (CPU, OS, runtime support) seems to be a factor, as well as the backend code generation options (i.e. -march gcc compiler option). He also suggests that the only reliable methodology for discovering the availability of these functions/builtins is by doing link-time tests. I mention as much because (unverified) I think boost's current solution is #ifdefs based on architecture and compiler version, which I think is fighting a losing battle. I hope this information is useful for those stuck on the problem, and/or boost developers. Cheers, -tom

1 0

[asio] async write handler is not called until the socket is not closed
by Roman Shmelev 02 May '09

02 May '09

Hi! I've got very strange problem - handler passed to async_write is not called in time. What I mean - it is called only when socket is closed - then handler is invoked many times. Sometimes it is so, sometimes everything is fine. The main thing is that traffic exists. I mean - async writes get completed. I call io_service.run() in proper time, etc. Another moment - the first two times the handler is invoked, but not more. As I guess, the problem is somewhere in my code. But I ask you to point to probable reasons of such behaviour that breaks asio rules..

2 7

[iterator] std::sort on zip_iterator
by Jeremiah Willcock 02 May '09

02 May '09

I would like to sort two separate vectors of numbers, treating corresponding elements of the two vectors as tuples and sorting the tuples. In particular, I am only comparing the first elements of the tuples; that may or may not be relevant to my problem. An example program is: #include <vector> #include <algorithm> #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/iterator/zip_iterator.hpp> struct compare_first_elements_in_tuples { template <typename Tuple> bool operator()(const Tuple& a, const Tuple& b) const { return (a.template get<0>()) < (b.template get<0>()); } }; int main(int, char**) { size_t a_data[5] = {0, 2, 1, 2, 4}; size_t b_data[5] = {1, 1, 5, 3, 7}; std::vector<size_t> a(a_data, a_data + 5); std::vector<size_t> b(b_data, b_data + 5); std::cout << "Before:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; typedef std::vector<size_t>::iterator vec_iter; typedef boost::zip_iterator<boost::tuple<vec_iter, vec_iter> > zip_iter; std::sort(zip_iter(boost::make_tuple(a.begin(), b.begin())), zip_iter(boost::make_tuple(a.end(), b.end())), compare_first_elements_in_tuples()); std::cout << "After:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; return 0; } On gcc 4.0.1, the sort operation results in the element (2, 1) (a pair of corresponding elements in a and b) being duplicated, while the element (1, 5) does not appear in the result at all: Before: (0, 1) (2, 1) (1, 5) (2, 3) (4, 7) After: (0, 1) (2, 1) (2, 1) (2, 3) (4, 7) I suspect the problem is related to the fact that zip_iterator does not return a "real" reference when dereferenced. Am I mistaken about this? Is the code above supposed to work? If not, is there an alternative way to sort one sequence while swapping elements in another in a corresponding way? I am not able to join the two input sequences into a single sequence of pairs because of other factors in the use case for this code. Thank you for your help. -- Jeremiah Willcock

1 0

General C++: Class Method Signatures Miss-Match
by Etienne Philip Pretorius 02 May '09

02 May '09

Hello list, I know this is not boost related, but I will appreciate it if anyone could shed some light on what is happening here? Compiler error: xml.cpp: In member function ‘xml::document& xml::document::parse(std::vector<unsigned char, std::allocator<unsigned char> >&)’: xml.cpp:25: error: no matching function for call to ‘xml::document::characters(std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >)’ xml.hpp:24: note: candidates are: virtual void xml::document::characters(unicode::string) unicode::string definition starts: namespace unicode { typedef std::size_t code_point; class string : public std::basic_string<code_point> { Is "std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >" not the same as "unicode::string"? If not why is it not? Etienne

7 15

[BGL] unordered_set<std::vector<edge_descriptor> >
by Johan Oudinet 02 May '09

02 May '09

Hi, I want to keep a set of paths, which are implemented as a vector of edge_descriptor. I don't care about the order. I just have to add paths and be able to know the number of different paths present in the set. So, I plan to use unordered_set but I'd like to know you opinion about a hash function, since AFAIK, unordered_set is like an hash_set? My main issue is to use as few memory as possible, because there will have a lot of paths in the set. Any idea? Thanks for your help. -- Johan

3 5

performance of dijkstra_shortest_paths
by Bhaskara Marthi 01 May '09

01 May '09

I recently ran into a situation where dijkstra_shortest_paths in the boost graph library was running very slowly. When I replaced the call to dijkstra_shortest_paths with the code below, things were a couple of orders magnitude faster. Any idea why? - Bhaskara Version 1: with dijkstra_shortest_paths ReachableCostVector GridGraph::singleSourceCosts (const Cell2D& source, const vector<Cell2D>& dests) { GridDistances distances; GridGraphVertex start = cellVertex(source); resetIndices(); typedef map<GridGraphVertex, GridGraphVertex> GridPreds; GridPreds predecessors; boost::dijkstra_shortest_paths (graph_, start, weight_map(get(&EdgeCost::cost, graph_)). vertex_index_map(get(&CellInfo::index, graph_)). distance_map(associative_property_map<GridDistances>(distances)). predecessor_map(associative_property_map<GridPreds>(predecessors)). // to avoid warnings visitor(GraphSearchVisitor())); ReachableCostVector v(dests.size()); transform (dests.begin(), dests.end(), v.begin(), bind(extractCost, this, distances, _1)); return v; } Version 2: without dijkstra_shortest_paths // Approximation to Dijkstra ReachableCostVector GridGraph::singleSourceCosts (const Cell2D& source, const vector<Cell2D>& dests) { GridDistances distances; GridGraphVertex start = cellVertex(source); typedef pair<GridGraphVertex, double> QueueItem; queue<QueueItem> q; set<GridGraphVertex> visited; q.push(QueueItem(start,0.0)); visited.insert(start); while (!q.empty()) { GridGraphVertex v; double d; tie(v,d) = q.front(); q.pop(); GridGraphAdjacencyIterator iter, end; for (tie(iter,end)=adjacent_vertices(v, graph_); iter!=end; iter++) { if (visited.find(*iter)==visited.end()) { double cost = d+graph_[edge(v,*iter,graph_).first].cost; q.push(QueueItem(*iter, cost)); visited.insert(*iter); distances[*iter] = cost; } } } ReachableCostVector costs; for (vector<Cell2D>::const_iterator iter=dests.begin(); iter!=dests.end(); ++iter) { GridDistances::iterator pos = distances.find(cellVertex(*iter)); if (pos==distances.end()) costs.push_back(ReachableCost(false,-42.0)); else costs.push_back(ReachableCost(true, pos->second)); } return costs; }

4 7

New declaration ambiguates old declaration mutant.hpp
by Celine.Murphy＠barclayscapital.com 01 May '09

01 May '09

/ThirdParty/include/boost-1.38.0/boost-1_38/boost/bimap/relation/detail/ mutant.hpp:68: new declaration `template<class View, class Type> boost::enable_if<boost::is_const<Reference>, const View&>::type boost::bimaps::relation::detail::mutate(Type&)' /ThirdParty/include/boost-1.38.0/boost-1_38/boost/bimap/relation/detail/ mutant.hpp:55: ambiguates old declaration `template<class View, class Type> boost::enable_if<boost::mpl::not_<boost::is_const<Reference> >, View&>::type boost::bimaps::relation::detail::mutate(Type&)' Hi, I am getting the above error when I try to compile a class that includes boost/bimap.hpp. It happens at the include stage. Has anyone seen this before? Gcc 3.2.3, boost 1.38. Thanks Celine _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. _______________________________________________

2 2

boost::posix_time::from_time_t bug ???
by Łukasz Majewski 01 May '09

01 May '09

Hello, i think that i've found bug in date time library or maybe i made something wrog. SAMPLE CODE: #include <boost/date_time/posix_time/posix_time.hpp> #include <iostream> using namespace boost::posix_time; int main( int argc, char** argv ) { time_t t = time( 0 ); std::cout << "time_t: " << ctime( &t ) << std::endl; struct tm* t2 = localtime( &t ); std::cout << "struct tm: " << asctime( t2 ) << std::endl; ptime t3 = from_time_t( t ); std::cout << "ptime from time_t: " << to_simple_string( t3 ) << std::endl; ptime t4 = ptime_from_tm( *t2 ); std::cout << "ptime from tm: " << to_simple_string( t4 ) << std::endl; return 0; } OUTPUT: time_t: Fri May 1 14:22:01 2009 struct tm: Fri May 1 14:22:01 2009 ptime from time_t: 2009-May-01 12:22:01 // incorrect result ptime from tm: 2009-May-01 14:22:01

2 2

[boost-users][StateChart] polymorphic_downcast failure
by Igor R 01 May '09

01 May '09

Hi, The above failure occurs in reaction_dispatcher::derived_with_action::react(). IIUC, state_machine tries to invoke in_state_reaction that's defined for an event, which is unrelated to the one being processed. What logical error in my state-machine might cause such a problem? Unfortunately, I don't have any self-contained code at the moment, so please treat my question as theoretical :). Thanks.

2 6