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

[Graph] Caching Dijkstra results
by Sensei 14 May '14

14 May '14

Dear all, I need to find the shortest path from a node to another, and this operation will be performed several times with different source/destination nodes. In many cases, I would need the same source, so I was thinking about caching the results from Dijkstra. Sincerely, I don't know what I should cache. My initial thought is creating a hashmap with key being the source node, and value something that allows me to easily retrieve the path. What do you think I need to cache? Does it suffices to have a map from node index (std::size_t) to the node's predecessor map? Thanks & Cheers!

4 5

[thread] pthread/once.cpp doesn't compile for iOS
by Igor R 14 May '14

14 May '14

I'm upgrading Boost in an iOS project form 1.53 to 1.55, and getting the following error: cc1plus: error in backend: Couldn't allocate input reg for constraint 'Q'! cc1plus: error in backend: Couldn't allocate input reg for constraint 'Q'! lipo: can't figure out the architecture type of: /var/folders/j1/9fz1wymd0xs91683nq8gzwhr0000gn/T//ccBue08f.out "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -gdwarf-2 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -pthread -arch arm -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -arch armv7 -arch armv7s -fpermissive -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DNDEBUG -D_LITTLE_ENDIAN -I"." -c -o "bin.v2/libs/thread/build/darwin-6.1~iphone/release/architecture-arm/link-static/macosx-version-iphone-6.1/target-os-iphone/threading-multi/pthread/once.o" "libs/thread/src/pthread/once.cpp" Is it a known issue? Is there a workaround? Thanks.

1 0

boost::geometry::model::linestring
by alev mutlu 13 May '14

13 May '14

Hi all, I have the following code. I can correctly print the content of line_smp with boost::geometry::dsv but get strange results when I copy line_smp into a vector and then print the content of the vector. Any ideas on what I am doing wrong? bg::model::d2::point_xy p; while(rs->next()){ bg::set<0>(p, i); bg::set<1>(p, rs->getDouble("num")); i++; line +=p; } boost::geometry::simplify(line, line_smp, 0.3); std::cout<< " original: " << boost::geometry::dsv(line) << std::endl << "simplified: " <<boost::geometry::dsv(line_smp) << std::endl; std::vector<xy> v; v.clear(); std::copy(line_smp.begin(), line_smp.end(), std::back_inserter(v)); stringstream sa, ssa; for(int ia = 0; ia < v.size(); ia++){ sa << bg::get<1>(v[i]); cout << sa; sa.str(""); }

2 1

[boost] [mpl] Hard upper limit for range_c
by Javier Dehesa 13 May '14

13 May '14

I was testing for_each and range_c and I've discovered that there's a hard limit in the range_c template. I'm attaching an example (copied from the for_each docs http://www.boost.org/doc/libs/1_55_0/libs/mpl/doc/refmanual/for-each.html) to illustrate it. This program compiles fine for me (g++ 4.9.0), but if I set NUM to a number over 890, the compilation fails. I receive an error about template instantiation depth, so I guess I could tune it in the compiler to make it work. But, anyway, why is this template recursively defined? Is it on purpose? I get that maybe range_c was intended just for small ranges, but, is it the only way it can work? Also, it only allows for statically defined range limits. Also, whenever it compiles, the bigger the number you put, the longer it takes to compile. Thanks. -- Javier Dehesa

2 1

geomety::within not compiling for model::box
by mark meijer 13 May '14

13 May '14

Is this not supported for box type? NOT_IMPLEMENTED_FOR_THIS_TYPES Thanks for having a look, Mark typedef boost::geometry::model::d2::point_xy<int16_t, boost::geometry::cs::cartesian> FrameCoord_t; typedef boost::geometry::model::box<FrameCoord_t> FrameBox_t; FrameBox_t box1; FrameBox_t box2; boost::geometry::assign_values(box1, 10, 10, 20, 20); boost::geometry::assign_values(box2, 0, 0, 100, 100); bool is_within = boost::geometry::within(box1, box2); 15>ClCompile: 15> Main.cpp 15>G:\work\software-external\libs\Boost\boost_1_51_0\boost/geometry/strategies/within.hpp(57): error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 'boost::mpl::failed ************(__thiscall boost::geometry::strategy::within::services::default_strategy<TagContained,TagContaining,CastedTagContained,CastedTagContaining,CsTagContained,CsTagContaining,GeometryContained,GeometryContaining>::NOT_IMPLEMENTED_FOR_THIS_TYPES::* ***********)(boost::mpl::assert_::types<T1,T2>)' to 'boost::mpl::assert<false>::type' 15> with 15> [ 15> TagContained=boost::geometry::box_tag, 15> TagContaining=boost::geometry::box_tag, 15> CastedTagContained=boost::geometry::box_tag, 15> CastedTagContaining=boost::geometry::areal_tag, 15> CsTagContained=boost::geometry::cartesian_tag, 15> CsTagContaining=boost::geometry::cartesian_tag, 15> GeometryContained=Media::DetectionBox_t, 15> GeometryContaining=Media::DetectionBox_t, 15> T1=Media::DetectionBox_t, 15> T2=Media::DetectionBox_t 15> ] 15> No constructor could take the source type, or constructor overload resolution was ambiguous 15> G:\work\software-external\libs\Boost\boost_1_51_0\boost/geometry/algorithms/within.hpp(285) : see reference to class template instantiation 'boost::geometry::strategy::within::services::default_strategy<TagContained,TagContaining,CastedTagContained,CastedTagContaining,CsTagContained,CsTagContaining,GeometryContained,GeometryContaining>' being compiled 15> with 15> [ 15> TagContained=boost::geometry::box_tag, 15> TagContaining=boost::geometry::box_tag, 15> CastedTagContained=boost::geometry::box_tag, 15> CastedTagContaining=boost::geometry::areal_tag, 15> CsTagContained=boost::geometry::cartesian_tag, 15> CsTagContaining=boost::geometry::cartesian_tag, 15> GeometryContained=Media::DetectionBox_t, 15> GeometryContaining=Media::DetectionBox_t 15> ] 15> FrameProcessorVideoIq.cpp(357) : see reference to function template instantiation 'bool boost::geometry::within<Media::DetectionBox_t,Media::DetectionBox_t>(const Geometry1 &,const Geometry2 &)' being compiled 15> with 15> [ 15> Geometry1=Media::DetectionBox_t, 15> Geometry2=Media::DetectionBox_t 15> ] 15>G:\work\software-external\libs\Boost\boost_1_51_0\boost/geometry/strategies/within.hpp(57): error C2866: 'boost::geometry::strategy::within::services::default_strategy<TagContained,TagContaining,CastedTagContained,CastedTagContaining,CsTagContained,CsTagContaining,GeometryContained,GeometryContaining>::mpl_assertion_in_line_40' : a const static data member of a managed type must be initialized at the point of declaration 15> with 15> [ 15> TagContained=boost::geometry::box_tag, 15> TagContaining=boost::geometry::box_tag, 15> CastedTagContained=boost::geometry::box_tag, 15> CastedTagContaining=boost::geometry::areal_tag, 15> CsTagContained=boost::geometry::cartesian_tag, 15> CsTagContaining=boost::geometry::cartesian_tag, 15> GeometryContained=Media::DetectionBox_t, 15> GeometryContaining=Media::DetectionBox_t 15> ] 15>G:\work\software-external\libs\Boost\boost_1_51_0\boost/geometry/algorithms/within.hpp(285): error C2039: 'type' : is not a member of 'boost::geometry::strategy::within::services::default_strategy<TagContained,TagContaining,CastedTagContained,CastedTagContaining,CsTagContained,CsTagContaining,GeometryContained,GeometryContaining>' 15> with 15> [ 15> TagContained=boost::geometry::box_tag, 15> TagContaining=boost::geometry::box_tag, 15> CastedTagContained=boost::geometry::box_tag, 15> CastedTagContaining=boost::geometry::areal_tag, 15> CsTagContained=boost::geometry::cartesian_tag, 15> CsTagContaining=boost::geometry::cartesian_tag, 15> GeometryContained=Media::DetectionBox_t, 15> GeometryContaining=Media::DetectionBox_t 15> ] 15>G:\work\software-external\libs\Boost\boost_1_51_0\boost/geometry/algorithms/within.hpp(291): error C2955: 'boost::type' : use of class template requires template argument list 15> G:\work\software-external\libs\Boost\boost_1_51_0\boost/type.hpp(14) : see declaration of 'boost::type' 15> 15>Build FAILED. 15>

2 1

DateTime library - how to count "working days"?
by qplace 13 May '14

13 May '14

I need to find a day that stands 30 working days from a specific date, ignoring holidays. Currently I am doing it like this: boost::gregorian::date lastdate; int maxdays(30); for (int i = maxdays; i != 0; --i) { // skip weekends gregorian_calendar::day_of_week_type dow = lastdate.day_of_week(); while ( (dow == Sunday ) || (dow == Saturday) ) { lastdate -= boost::gregorian::date_duration(1); dow = lastdate.day_of_week(); } lastdate -= boost::gregorian::date_duration(1); } I did not find the iterator that can do it cleaner, but may be there is one? Thanks.

2 1

date_time output facet question
by Erik Türke 13 May '14

13 May '14

Hi all, i am trying to find out how to use date time output facet on a format like "%m-%d %T [%module:%level] %message" in a way that i get the date_time and the residual format ([%module:%level] %message). At the moment i am just getting the date and time without the rest of the format. Is there any chance to achieve that? Thanks in advance!

1 0

date time output facet question
by Erik Türke 13 May '14

13 May '14

Hi all, i am trying to find out how to use date time output facet on a format like "%m-%d %T [%module:%level] %message" in a way that i get the date_time and the residual format ([%module:%level] %message). At the moment i am just getting the date and time without the rest of the format. Is there any chance to achieve that? Thanks in advance!

1 0

Boost.Log - textual format with severity
by Keith Bennett 12 May '14

12 May '14

Hello! I'm new to boost log (like many others, I imagine since it's only a relatively new library). I'm trying to specify a format textually (eg, keywords::format = "blahblah", instead of using a compiled expression). The idea is that the format can be reconfigured easily either through a command line parameter or through the configuration file without needing to recompile. However, it seems that anything specifying %Severity% when using a custom severity_level enum will simply not be output at all. Take the example from libs/log/example/keywords/main.cpp Simply changing line 86 to be: logging::add_console_log(std::clog, keywords::format = "%Severity% %TimeStamp%: %_%"); will exhibit the problem I believe I am trying to resolve. My suspicion is that the core doesn't know about the custom Severity attribute because it hasn't been registered and so is unable to parse %Severity% to any formatter. In contrast, the add_file_log below that does correctly output the severity level because it uses a compiled expression and is therefore able to deduce what needs to be done (am I correct in that assumption)? I seem to be unable to add an attribute to resolve this without rolling my own attribute class. How do I add an attribute or formatter related to the Severity which was declared with BOOST_LOG_ATTRIBUTE_KEYWORD? I think it's worth noting that if I remove the template parameter to severity_logger on line 123 so that it matches thus: src::severity_logger< > slg; It then devolves into a standard int instead of an enum and the output is "correctly" seen -- as an int and not as a human-readable string. While this is okay for now, I would of course want it to be human-readable if possible. This is as it is in the example in libs/log/example/settings_file/main.cpp. Any help would be appreciated. -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Re: [Boost-users] [RFC] Modern CORBA C++ IDL Mapping and implementation
by Felipe Magno de Almeida 12 May '14

12 May '14

Sorry if this ends up duplicate. But I've sent it to the developer's list and it came back. Hello Boosters, Where I work we are implementing an open source, modern, CORBA implementation and IDL mapping. We want it to support C++ and C++11 IDL mapping, but we also want to create another IDL mapping. This new IDL mapping is being experimentated in the following url https://github.com/expertisesolutions/mORBid/tree/concepts It still has some very problematic issues (like compilation-time of generated code) and of course it is still far from completion. But, we would like to hear suggestions about this approach. What we did was that an IDL interface is mapped to a typedef for boost::type_erasure (I found the idea quite cool for the reasons that I'll mention below) with the requirements defined in the IDL, e.g. its operations. The IDL also emits a model for this type_erasure which is the actual stub class and is called remote_reference. It also emits a proxy_reference model for the same type_erasure typedef which receives a std::reference_wrapper and proxies the calls, this is needed because type_erasure can't switch between by-reference and by-value in runtime. Why I believe this approach is better than current IDL to C++11 mapping: Because the IDL to C++11 mapping is too intrusive. You can't really use normal classes you have written for use as servants in CORBA because you have to inherit from Skeletons classes *and* you have to use the *exact* same signature as defined in the mapping. This is *way too restricted*. This is also inerent to the OO paradigm that CORBA uses. But, we can mimic the same features using type-erasure instead of directly using dynamic polymorphism. This gives a much greater freedom to users. It might be that Boost.type_erasure is not the best tool here because of compile-time and compiler memory usage, but the idea surely is. We still haven't seriously profiled boost.type_erasure yet, but we will do so as soon as possible. I think it might be very interesting to experiment with lite concepts and Boost.concept_check as well. Also, we created a EDSL for GIOP and IIOP mapping based on the boost.spirit infrastructure. We use that to treat alignment and endianness automatically and to use the same grammar for generation and parsing of IIOP messages. The message header grammar is defined like this: start = "GIOP" & octet('\1') /* GIOP major version */ & octet('\0') /* GIOP minor version */ & endianness [ octet(MessageType) /* message_type */ & raw_size(ulong_)[body] ] ; Which is compiled to IIOP parser or generator through boost.spirit infrastructure of make_terminal, make_directive and etc. This works splendid well and is really easy to use, extend, is statically checked and has great performance. Whoever feel interested, please take a look and comments are highly appreciated. Regards, -- Felipe Magno de Almeida

1 0