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

nearest neighbors search with boost
by Georgios Samaras 11 Apr '14

11 Apr '14

I just find out that boost supports nearest neighbor searching, will amazes me. However, I do not want just to use the nearest() method, I want to study it and understand it. Is there any relevant documentation, specifically on how NNS is performed in R-tree? Are the code files that implement this method visible to the user? I downloaded the latest .tar file. Thank you in advance, Georgios PS - Hello Boost world! :)

2 1

possible bug with boost::is_convertible
by Matei David 11 Apr '14

11 Apr '14

Hi, I found a situation where (with gcc 4.8.2 & 1.55) I cannot compile a call to boost::is_convertible, but I can compile a similar call to std::is_convertible. I don't know yet if this is a bug. Is it undefined behaviour to pass is_convertible a type with a deleted or private copy ctor? Before I go into the details, I'd like to ask, which type_traits library should we prefer these days, post c++11? Intuition says std should be more stable/portable, is that wrong? If it is indeed std, is there a way (perhaps a macro?) to make boost mirror std (I'm talking about type_traits only). The reason for having such a mirror option is not for new code, but for other boost libraries which need type_traits. E.g, I came across this issue from boost::iterator. Here is the discordant code: #include <type_traits> #include <boost/type_traits/is_convertible.hpp> struct A { A() = default; A(const A&) = delete; // or private: A(const A&) = default; }; struct Ref_A { // proxy reference to A operator A& () { return *_ptr; } A* _ptr; }; int main() { (void)std::is_convertible< Ref_A, A >::value; (void)boost::is_convertible< Ref_A, A >::value; } I compile with: {g++|clang++} -std=c++11 -I${BOOST_INCLUDE} -Wall -Wextra -c With gcc 4.8.2, the call to boost::is_convertible fails, complaining that the copy ctor of A is deleted (or private.) The similar call to std::is_convertible compiles ok. With clang 3.4, both calls compile. The reason for the discrepancy is that boost/type_traits/intrinsics.hpp defines the macro BOOST_IS_CONVERTIBLE(T,U) for clang, but not for gcc. Because of that, at the bottom of boost/type_traits/is_convertible.hpp, clang uses the macro to implement is_convertible, whereas gcc uses is_convertible_impl_dispatch instead (which is the one that fails). A temporary fix I found is to define that macro to defer to std: #include <type_traits> #include <boost/type_traits/intrinsics.hpp> #ifndef BOOST_IS_CONVERTIBLE #define BOOST_IS_CONVERTIBLE(T, U) (std::is_convertible<T, U>::value) #endif #include <boost/type_traits/is_convertible.hpp> As I was asking above, is there a way to do that systematically for all type_traits? Thanks, M

1 0

[asio] Crash when posted handlers execute in one thread only?
by Sohail Somani 10 Apr '14

10 Apr '14

Hi, Not sure if there is a race condition in the code below, or if I am not stopping the service in a sanctioned manner but when run, the code consistently crashes on OSX 10.9 with Boost 1.55 and Clang. The only regular pattern was that the crash occurs when all the posted completion handlers execute in one thread only. When the completion handlers execute across both threads, there is no crash. This seems to me like there could be an initialization bug somewhere. I'll try and create a smaller test case. Thanks for any ideas or suggestions. The code: #define LOG(msg) { \ boost::mutex::scoped_lock lock(log_mutex); \ std::cout << "[" << boost::this_thread::get_id() \ << "] " << msg << std::endl; \ } void test() { boost::mutex log_mutex; LOG("Boost version: " << BOOST_LIB_VERSION); for(int ii = 0; ii < 100; ++ii) { LOG("Iteration: " << ii); boost::asio::io_service service; boost::asio::io_service::work work(service); boost::thread_group group; auto fun = [&](){ LOG("Starting service"); service.run(); LOG("Completing service"); }; group.create_thread(fun); group.create_thread(fun); int ntasks = 10; volatile int val = 2; std::vector<volatile int> ints(ntasks,val); for(int ii = 0; ii < ntasks; ++ii) { service.post([&ints,ii,&log_mutex]() { LOG("Task: " << ii); ints[ii] = 1; }); } service.post([&service,&log_mutex](){ LOG("Stopping service"); service.stop(); }); group.join_all(); for(int ii = 0; ii < ntasks; ++ii) { if(ints[ii] != 1) { LOG(ii << "->" << ints[ii]); } } } LOG("Done test"); } int main() { try { test(); } catch(...) { std::cout << "Exception in main()" << std::endl; } } The output + stack trace: ... [0x7fff7aeb9310] Iteration: 91 [0x104681000] Starting service [0x104704000] Starting service [0x104704000] Task: 0 [0x104704000] Task: 1 [0x104704000] Task: 2 [0x104704000] Task: 3 [0x104704000] Task: 4 [0x104704000] Task: 5 [0x104704000] Task: 6 [0x104704000] Task: 7 [0x104704000] Task: 8 [0x104704000] Task: 9 [0x104704000] Stopping service [0x104704000] Completing service [0x104681000] Completing service Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000104703c57 0x00007fff8b06cdf3 in _pthread_cond_updateval () (gdb) where #0 0x00007fff8b06cdf3 in _pthread_cond_updateval () #1 0x00007fff8b06c91e in _pthread_cond_signal () #2 0x00000001000048d0 in boost::asio::detail::posix_event::signal_and_unlock<boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex> > () at build/boost/include/boost/asio/detail/posix_event.hpp:62 #3 0x00000001000048d0 in boost::asio::detail::task_io_service::wake_one_idle_thread_and_unlock () at build/boost/include/boost/asio/detail/task_io_service.hpp:484 #4 0x00000001000048d0 in boost::asio::detail::task_io_service::wake_one_thread_and_unlock (this=<value temporarily unavailable, due to optimizations>, lock=<value temporarily unavailable, due to optimizations>) at posix_event.hpp:493 #5 0x0000000100004776 in boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::~scoped_lock () at task_io_service.ipp:278 #6 boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::~scoped_lock () at build/boost/include/boost/asio/detail/scoped_lock.hpp:52 #7 0x0000000100004776 in boost::asio::detail::task_io_service::post_immediate_completion (this=<value temporarily unavailable, due to optimizations>, op=<value temporarily unavailable, due to optimizations>, is_continuation=<value temporarily unavailable, due to optimizations>) at scoped_lock.hpp:279 #8 0x0000000100001952 in test () at task_io_service.hpp:70 #9 0x0000000100002ca0 in main () at app/exe/testcpp/main.cpp:64 (gdb) info threads 2 0x00007fff985fc662 in kevent64 () * 1 0x00007fff8b06cdf3 in _pthread_cond_updateval ()

3 5

Re: [Boost-users] [Graph] Questions and remarks
by Jeremiah Willcock 10 Apr '14

10 Apr '14

On Sun, Apr 6, 2014 4:14 AM PDT Albert Yiamakis wrote: >Hello, > >Some questions and remarks regarding Boost.Graph: > >i) Why does write_graphviz require a VertexEdgeListGraph? I was unable >to invoke it on an adjacency_list using sets as containers for vertices >and edges; instead I had to switch to vectors. However, the function is >meant to output - does the efficiency of the traversal really matter? The issue is more likely to be a missing vertex index map than that concept constraint. Graphs with setS as vertex container do not have that by default, and I believe the graphviz writer needs that. You can look online for how to create that map. >ii) Would it be possible to mutate the graph in the visitors of an >algorithm? For instance, generating the graph during a breadth-first >search, by adding vertices and edges. Presumably, it would be the user's >responsibility to color the vertices appropriately. (Interestingly, >visitors take a non-const reference to the graph - but compilation >failed at some other point). That would almost always be dangerous because of iterator and descriptor invalidation. The loop variables, current source vertex, etc. would often become invalid (and thus invalid to use) because of the structural modifications. > >iii) The documentation of the distance_recorder states that > >"A WritablePropertyMap where the key type and the value type are the >vertex descriptor type of the graph." > >which has to be a mistake. It seems this has already been pointed out in >the past >(http://boost.2283326.n4.nabble.com/BGL-distance-recorder-td2571349.html) > >but is yet to be corrected. Yes, that does appear to be a bug. -- Jeremiah Willcock

1 0

Re: [Boost-users] [Graph] Run-time weight search
by Jeremiah Willcock 10 Apr '14

10 Apr '14

On Tue, Apr 8, 2014 5:38 AM PDT Sensei wrote: >Dear all, > >after many speculations and your previous advice I've come to the conclusion that I still need your help :) > >The setting is simple: I have an oriented graph, and I have two nodes. I wish to find all paths from one node to the other. > >Some restrictions apply: >- I *cannot* calculate weights except at run-time when needed, it's too costly; >- I can, if you say it's needed, restrict the path length to a certain threshold. > >What can I relax? The "all paths". Since weights are costly, I could set for just the best path, i.e., the one with the lowest weight. I don't think it would be possible to find the optimum path, in case I cannot search for all possible paths, but I can be easily wrong. > >I'm not that skilled with BGL, so any help would be quite appreciated! I've read the Table of Contents, but at first I cannot see if this can be done. > You might consider using A* search instead of a normal shortest path algorithm. You don't need a heuristic function (just use one that always returns zero). There is a function_property_map type that you can use to turn a weight-computing function into a property map. -- Jeremiah Willcock

1 0

the asio example which implement the tcp long connection
by lx 10 Apr '14

10 Apr '14

hi : I want to learn how to implement long connection by asio.But I can't find example. So, where I can find ? Thank you.

1 0

conflicting intmax_t definitions - Boost 1.53 and gcc 4.8 incompatibility?
by Nate Finch 09 Apr '14

09 Apr '14

I recently upgraded to Ubuntu Trusty Tehr, and now the C++ project I'm working on won't build. It looks like the stdlib and Boost aren't working nicely together for some reason. A bunch of typedefs are conflicting between the two, below is one of the errors, where intmax_t is getting defined in two places. I'm not sure what changed, but I now have gcc (Ubuntu/Linaro 4.8.2-14ubuntu2) 4.8.2 and boost Version: 1.53.0.0ubuntu2 Here's an example error message: /usr/include/inttypes.h:290:8: error: reference to ‘intmax_t’ is ambiguous extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__)); ^ In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdint.h:9:0, from /usr/include/inttypes.h:27, from src/uint256.h:11, from src/key.h:12, from src/crypter.h:8, from src/keystore.h:8, from src/script.h:14, from src/script.cpp:11: /usr/include/stdint.h:134:19: note: candidates are: typedef long int intmax_t typedef long int intmax_t; ^ In file included from /usr/include/boost/math_fwd.hpp:12:0, from /usr/include/boost/math/common_factor_ct.hpp:13, from /usr/include/boost/variant/variant.hpp:44, from /usr/include/boost/variant.hpp:17, from src/script.h:12, from src/script.cpp:11: /usr/include/boost/cstdint.hpp:306:50: note: typedef boost::long_long_type boost::intmax_t typedef ::boost::long_long_type intmax_t; Any help would be much appreciated. I'm fine with downgrading something, I'm just not sure what to downgrade.... or if there's an actual fix, that's cool too. -- View this message in context: http://boost.2283326.n4.nabble.com/conflicting-intmax-t-definitions-Boost-1… Sent from the Boost - Users mailing list archive at Nabble.com.

8 20

Re: [Boost-users] [serialization] [multimap] change of element's order when deserialize
by Pablo Madoery 09 Apr '14

09 Apr '14

Thank you for your quick answer. I think I will use a map of vector instead of a multimap. On Wed, Apr 9, 2014 at 12:18 PM, Robert Ramey <robertmacleranramey(a)gmail.com > wrote: > > > On Wednesday, April 9, 2014 7:45:59 AM UTC-7, Pablo Madoery wrote: >> >> I have the following code: >> > > >> snip ... >> >> where you can see that the element's order is changed. >> >> When compiling it throw this warning: >> boost::mpl::print<boost::serialization::BOOST_ >> SERIALIZATION_STATIC_WARNING_LINE<98> > >> > > that I don't know what it means. > > You'll have to look into source code error stack to see the comment > associated with this warning. > > >> >> Is this a normal behavior of the serialization library? >> I am missing something ? >> > > This is a feature of the implementation of the serialization of multi map > as well as the implementation > of the std::multi map itself. The result is correct in that it's a valid > multimap but it is a different one that the original. > You could say it's an equivalent multimap. Should this have been done > differently? probably not. Trying > to guarantee this level of "equality" would couple the serialization > implementation to the > std::multimap implementation. This would add much work and never could be > entirely relied upon. > > If you want a specific order - don't use multi map. Expend your key size > and use map or set > > Robert Ramey > >

1 0

[serialization] [multimap] change of element's order when deserialize
by Pablo Madoery 09 Apr '14

09 Apr '14

I have the following code: #include <utility> #include <vector> #include <string> #include <fstream> #include <iostream> #include <map> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/map.hpp> using namespace std; void print(multimap<pair<string, string>, int> &m) { multimap<pair<string, string>, int>::iterator it1 = m.begin(); multimap<pair<string, string>, int>::iterator it2 = m.end(); for(; it1!=it2; ++it1) { cout<<"key = "<<(it1->first).first<<(it1->first).second<<"\t\t"; cout<<"value = "<<(it1->second)<<endl; } cout<<endl; } int main() { multimap<pair<string, string>, int> m1; pair<string, string> par1("A", "B"); pair<string, string> par2("A", "B"); pair<string, string> par3("E", "F"); pair<string, string> par4("E", "F"); m1.insert(pair<pair<string, string>, int>(par1,10)); m1.insert(pair<pair<string, string>, int>(par2,20)); m1.insert(pair<pair<string, string>, int>(par3,30)); m1.insert(pair<pair<string, string>, int>(par4,40)); ofstream ofs("filename"); boost::archive::text_oarchive serial1(ofs); serial1 << m1; ofs.close(); ifstream ifs("filename"); boost::archive::text_iarchive serial2(ifs); multimap<pair<string, string>, int> m2; serial2 >> m2; cout<<"map1 = "<<endl; print(m1); cout<<endl; cout<<"map2 = "<<endl; print(m2); cout << "end" << endl; return 0; } What I am trying to do is serialize a multimap and then deserialize it. The problem i that the order of the elements is not conserved. This program gives as result the following: map1 = key = AB value = 10 key = AB value = 20 key = EF value = 30 key = EF value = 40 map2 = key = AB value = 20 key = AB value = 10 key = EF value = 40 key = EF value = 30 end where you can see that the element's order is changed. When compiling it throw this warning: boost::mpl::print<boost::serialization::BOOST_SERIALIZATION_STATIC_WARNING_LINE<98> > that I don't know what it means. Is this a normal behavior of the serialization library? I am missing something ?

1 0

shared_lock owner
by shada 09 Apr '14

09 Apr '14

did shared_lock has a member like visual c++ critical_section's owner? i use shared_lock in a game server, it has several hundred threads. if has owner, it more easy resolve deadlock.

2 2