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

ASIO + SSL + no shared cipher
by Luke Walker 21 Dec '11

21 Dec '11

Hi All,I've taken the SSL server example "as is" but when I attempt to send a request from (Safari, Firefox, Chrome or IE) the handshake fails with "no shared cipher". I've researched the issue for several days and made a few changes. I use OpenSSL_add_all_algorithms and SSL_CTX_set_cipher_list to attempt to satisfy the cipher's but I get the same error. I also used OpenSSL > s_client to try and negotiate a cipher but it fails as well. One assumption I've assembled is that Chrome, Safari and NSURLRequest (Cocoa API) all use the same cipher list. Again I am using the ssl server example and have changed the context SSL Version but still no success. Any help would be greatly appreciated. Luke

1 0

Selecting a random neighbor
by George Bezerra 21 Dec '11

21 Dec '11

Hi, I'm totally new to BGL. I would like to know what is the best way to select a random neighbor of a vertex in an undirected graph without having to iterate through all neighbors. Can anyone help me with that? Thanks! George. -- George Bezerra Doctoral Student Department of Computer Science University of New Mexico, USA

2 1

[Regex] anyone seeing performance dip w/regex matching moving from 1.47->1.48 w/gcc?
by Kopet, Gary 20 Dec '11

20 Dec '11

Hi, I just pulled down boost regex 1.48 and built it with gcc 4.3 on CentOS 5.5. My internal regex performance tests are showing > 30% performance degradation between versions 1.47 and 1.48. I wanted to ask if anyone else has seen anything like this? We've been using the same makefile to built boost regex for a long time, and we haven't converted to bjam. So I am wondering if this could be due to our particular build environment? TIA, Gary Protected by Websense Hosted Email Security -- www.websense.com

2 2

boost test framework logging xml to file
by Jarosław Bober 20 Dec '11

20 Dec '11

Hello, is there a way to get test case name from global fixture? What I would like to have is separate xml file report for every test case. I'd like to do it this way: #include <string> #include <fstream> struct LogToFile { LogToFile() { std::string logFileName(boost::unit_test:: framework::master_test_suite().p_name); logFileName = current_test_case_name ; logFile.open(logFileName.c_str(), std::ios_base::app); boost::unit_test::unit_test_log.set_stream(logFile); } ~LogToFile() { logFile << "</TestLog>" << std::flush; logFile.close(); boost::unit_test::unit_test_log.set_stream(std::cout); } std::ofstream logFile; }; BOOST_GLOBAL_FIXTURE(LogToFile); Can I do that? Regards

2 1

[Interprocess] managed_shared_memory problem in 64-bit windows (v. 1.48.0)
by Michel Lestrade 20 Dec '11

20 Dec '11

Hi, I am trying to make a shared memory block between 2 Intel Fortran programs and thought to use a small C/C++ lib file to accomplish this: Fortran can use the ISO_C_BINDING module to make its pointers point to C objects but not vice versa and there is a vast Fortran code base which we have no intention of porting. There is a native pipe mechanism but given the amount of data I will be exchanging, disk access is something I want to avoid. The application is FEM modeling and the sparse matrix can be several hundred MBs; as the program evolves and the matrix changes, I expect hundreds of GBs of data in total I/O. Seems like it would be better to have a shared memory region and let the OS manage things as much as possible. Starting small to test the idea, I am running into trouble with something which seems easy enough to do in the examples but which only seems to work in 32-bit. Here is an incomplete fragment (got stuck early): #include <string> #include <boost/interprocess/managed_shared_memory.hpp> using namespace boost::interprocess; struct shm_remove { shm_remove(const char *input) { name = std::string(input); shared_memory_object::remove(name.c_str()); } ~shm_remove() {shared_memory_object::remove(name.c_str());} std::string name; } *remover; extern "C" void alloc_mumps(const int n, const int nnz, const char *name) { int size_shm = sizeof(int)*(2+2*nnz) + sizeof(double)*(nnz+2*n); remover = new shm_remove(name); managed_shared_memory managed_shm(create_only,name,size_shm); // Trying to do the equivalent of *i = new int int *i = managed_shm.construct<int>(anonymous_instance)[1](n); } Calling the function with n=3 and nnz=6 (a very small value compared to my final application) works OK when the application is compiled under 32-bit. Compiling under 64-bit produces an access violation error in win32_api.hpp: inline long interlocked_compare_exchange(long volatile *addr, long val1, long val2) { return BOOST_INTERLOCKED_COMPARE_EXCHANGE(addr, val1, val2); } values in debugger: addr=0, val1=1 val2=0. I do not know enough about Boost to know whether this is a design limitation, a bug or just an issue with my initial build. Just for reference, this is what I used: bjam --toolset=msvc-9.0 address-model=64 --build-type=complete stage Any suggestions ? Michel Lestrade Crosslight Software

2 2

[Boost] [Program Options]: Special character # in configuration file
by Bruno Matos 20 Dec '11

20 Dec '11

Hi, There is any way to use # in a configuration parameter value without being interpreted as comment initiator? Example: url=http://www.example.com/#sometopic Tia. Regards. -- Bruno Matos

1 0

help figuring out msg
by Jacques C. Richard 20 Dec '11

20 Dec '11

Can anyone help decipher this message? Is it really trying to allocate that size? Is gcc really using malloc under all these boost code? :) malloc: *** mmap(size=380554168512811008) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc [jacques-richards-mac-mini:00700] *** Process received signal *** [jacques-richards-mac-mini:00700] Signal: Abort trap (6) [jacques-richards-mac-mini:00700] Signal code: (0) [jacques-richards-mac-mini:00700] [ 0] 2 libSystem.B.dylib 0x00007fff8449b1ba _sigtramp + 26 [jacques-richards-mac-mini:00700] [ 1] 3 ??? 0x0030303700837a50 0x0 + 13563811672062544 [jacques-richards-mac-mini:00700] [ 2] 4 libstdc++.6.dylib 0x00007fff809c65d2 __tcf_0 + 0 [jacques-richards-mac-mini:00700] [ 3] 5 libobjc.A.dylib 0x00007fff84609b4d _objc_terminate + 120 [jacques-richards-mac-mini:00700] [ 4] 6 libstdc++.6.dylib 0x00007fff809c4ae1 _ZN10__cxxabiv111__terminateEPFvvE + 11 [jacques-richards-mac-mini:00700] [ 5] 7 libstdc++.6.dylib 0x00007fff809c4b16 _ZN10__cxxabiv112__unexpectedEPFvvE + 0 [jacques-richards-mac-mini:00700] [ 6] 8 libstdc++.6.dylib 0x00007fff809c4bfc _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception + 0 [jacques-richards-mac-mini:00700] [ 7] 9 libstdc++.6.dylib 0x00007fff809c4efb _Znwm + 87 [jacques-richards-mac-mini:00700] [ 8] 10 Mg 0x0000000100113608 _ZN9__gnu_cxx13new_allocatorI12lattice_typeE8allocateEmPKv + 70 [jacques-richards-mac-mini:00700] [ 9] 11 Mg 0x000000010011362f _ZNSt12_Vector_baseI12lattice_typeSaIS0_EE11_M_allocateEm + 37 [jacques-richards-mac-mini:00700] [10] 12 Mg 0x0000000100113658 _ZNSt6vectorI12lattice_typeSaIS0_EE20_M_allocate_and_copyIPS0_EES4_mT_S5_ + 38 [jacques-richards-mac-mini:00700] [11] 13 Mg 0x000000010011376a _ZNSt6vectorI12lattice_typeSaIS0_EE7reserveEm + 114 [jacques-richards-mac-mini:00700] [12] 14 Mg 0x0000000100113881 _ZNK5boost13serialization3stl11reserve_impISt6vectorI12lattice_typeSaIS4_EEEclERS6_m + 33 [jacques-richards-mac-mini:00700] [13] 15 Mg 0x000000010011738b _ZN5boost13serialization3stl15load_collectionINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS6_EENS1_17archive_input_seqIS4_S8_EENS1_11reserve_impIS8_EEEEvRT_RT0_ + 189 [jacques-richards-mac-mini:00700] [14] 16 Mg 0x000000010011740c _ZN5boost13serialization4loadINS_3mpi15packed_iarchiveE12lattice_typeSaIS4_EEEvRT_RSt6vectorIT0_T1_EjN4mpl_5bool_ILb0EEE + 32 [jacques-richards-mac-mini:00700] [15] 17 Mg 0x0000000100117438 _ZN5boost13serialization4loadINS_3mpi15packed_iarchiveE12lattice_typeSaIS4_EEEvRT_RSt6vectorIT0_T1_Ej + 42 [jacques-richards-mac-mini:00700] [16] 18 Mg 0x0000000100117471 _ZN5boost13serialization11free_loaderINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEE6invokeERS3_RS7_j + 55 [jacques-richards-mac-mini:00700] [17] 19 Mg 0x0000000100117496 _ZN5boost13serialization10split_freeINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEEEvRT_RT0_j + 35 [jacques-richards-mac-mini:00700] [18] 20 Mg 0x00000001001174bb _ZN5boost13serialization9serializeINS_3mpi15packed_iarchiveE12lattice_typeSaIS4_EEEvRT_RSt6vectorIT0_T1_Ej + 35 [jacques-richards-mac-mini:00700] [19] 21 Mg 0x00000001001174f4 _ZN5boost13serialization13serialize_adlINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEEEvRT_RT0_j + 55 [jacques-richards-mac-mini:00700] [20] 22 Mg 0x0000000100117529 _ZNK5boost7archive6detail11iserializerINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS6_EEE16load_object_dataERNS1_14basic_iarchiveEPvj + 51 [jacques-richards-mac-mini:00700] [21] 23 libboost_serialization.dylib 0x0000000100533eb9 _ZN5boost7archive6detail14basic_iarchive11load_objectEPvRKNS1_17basic_iserializerE + 473 [jacques-richards-mac-mini:00700] [22] 24 Mg 0x00000001001178e3 _ZN5boost7archive6detail21load_non_pointer_typeINS_3mpi15packed_iarchiveEE13load_standard6invokeISt6vectorI12lattice_typeSaIS9_EEEEvRS4_RKT_ + 45 [jacques-richards-mac-mini:00700] [23] 25 Mg 0x000000010011790c _ZN5boost7archive6detail21load_non_pointer_typeINS_3mpi15packed_iarchiveEE6invokeISt6vectorI12lattice_typeSaIS8_EEEEvRS4_RT_ + 39 [jacques-richards-mac-mini:00700] [24] 26 Mg 0x0000000100117930 _ZN5boost7archive4loadINS_3mpi15packed_iarchiveESt6vectorI12lattice_typeSaIS5_EEEEvRT_RT0_ + 34 [jacques-richards-mac-mini:00700] [25] 27 Mg 0x000000010011795a _ZN5boost7archive6detail15common_iarchiveINS_3mpi15packed_iarchiveEE13load_overrideISt6vectorI12lattice_typeSaIS8_EEEEvRT_i + 40 [jacques-richards-mac-mini:00700] [26] 28 Mg 0x000000010011797f _ZN5boost3mpi15packed_iarchive13load_overrideISt6vectorI12lattice_typeSaIS4_EEEEvRT_iN4mpl_5bool_ILb0EEE + 35 [jacques-richards-mac-mini:00700] [27] 29 Mg 0x00000001001179ac _ZN5boost3mpi15packed_iarchive13load_overrideISt6vectorI12lattice_typeSaIS4_EEEEvRT_i + 42 [jacques-richards-mac-mini:00700] [28] 30 Mg 0x00000001001179d8 _ZN5boost7archive6detail18interface_iarchiveINS_3mpi15packed_iarchiveEErsISt6vectorI12lattice_typeSaIS8_EEEERS4_RT_ + 42 [jacques-richards-mac-mini:00700] [29] 31 Mg 0x0000000100117a0c _ZN5boost3mpi6detail21serialized_irecv_dataISt6vectorI12lattice_typeSaIS4_EEE11deserializeERNS0_6statusE + 40 [jacques-richards-mac-mini:00700] *** End of error message *** mpirun noticed that job rank 0 with PID 699 on node jacques-richards-mac-mini.local exited on signal 15 (Terminated). 1 additional process aborted (not shown) jacques-richards-mac-mini:SBF_T jacques$ Suspected cause: reqs.push_back( world.isend( Sender , SendTag , &Neighbor2Proc ) ) ; where std::vector< T > Neighbor2Proc ; Thanks!

3 4

Handler requirement for Asynchronous Operations in boost::asio
by Tu Hoang Do 20 Dec '11

20 Dec '11

It is specified in http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/reference/AcceptHa… that a handler for `async_accept()` must satisfy the following function signature: void accept_handler( const boost::system::error_code& ec) { ... } However, in the `Daytime.3` example, using boost::bind, the handler can be specified as much parameter as desired, as long as it does not exceed the limit of `boost::bind` (which is 9 arguments at maximum): class tcp_server { public: tcp_server(boost::asio::io_service& io_service) : acceptor_(io_service, tcp::endpoint(tcp::v4(), 13)) { start_accept(); } private: void start_accept() { tcp_connection::pointer new_connection = tcp_connection::create(acceptor_.get_io_service()); acceptor_.async_accept(new_connection->socket(), boost::bind(&tcp_server::handle_accept, this, new_connection, boost::asio::placeholders::error)); } void handle_accept(tcp_connection::pointer new_connection, const boost::system::error_code& error) { if (!error) { new_connection->start(); } start_accept(); } tcp::acceptor acceptor_; }; Why is that possible? I thought even with `boost::bind`, the exact function signature still has to be matched. Notice the `handle_accept()` funciton and how it is used in `async_accept()`. The full code listing is here: http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/tutorial/tutdaytim…

2 2

LINK : fatal error LNK1561: entry point must be defined
by ankit master 20 Dec '11

20 Dec '11

Hello, I am trying to run this simple example and I run into issues, could somebody please help me understand what am I doing incorrect here. #include <boost/test/unit_test.hpp> using namespace boost::unit_test; //____________________________________________________________________________// // you could easily implement test cases as a free functions // this test case will need to be explecetely registered in test tree void free_test_function() { // reports 'error in "free_test_function": test 2 == 1 failed' BOOST_CHECK(2 == 1); // non-critical test => continue after failure // reports 'unknown location(0): fatal error in "free_test_function": memory access violation // d:\source code\boost\libs\test\example\unit_test_example_02.cpp(25): last checkpoint' int* p = (int*)0x01; BOOST_CHECK( *p == 0 ); } //____________________________________________________________________________// test_suite* init_unit_test_suite( int, char* [] ) { framework::master_test_suite().p_name.value = "Unit test example 02"; // register the test case in test tree and specify number of expected failures so // this example will pass at runtime. We expect 2 errors: one from failed check and // one from memory acces violation framework::master_test_suite().add( BOOST_TEST_CASE( &free_test_function ), 2 ); return 0; } 1>------ Build started: Project: unitTestPrac2, Configuration: Debug Win32 ------ 1>Linking... 1>LINK : fatal error LNK1561: entry point must be defined 1>Build log was saved at "file://c:\Users\amaster\Desktop\AVM_Documents\CppPractise\unitTestPrac2\unitTestPrac2\Debug\BuildLog.htm" 1>unitTestPrac2 - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Thank you Ankit -- >From the withered tree, a flower blooms. - Zen -- >From the withered tree, a flower blooms. - Zen

1 0

Re: [Boost-users] Did he misunderstand you?
by John Wiegley 19 Dec '11

19 Dec '11

>>>>> Wayne Johnson <wjohnsonga(a)gmail.com> writes: > I'm new to the Boost libraries and becoming reacquainted with C++ after many > years of using other languages. As recommended in section 5.1 of the > "Getting Started on Windows", I visited the BoostPro website to find a > Windows 7 installer for v1.48.0 to use with VS C++ 2010. In response to a > followup message to BoostPro sales about the lack of an installer for the > latest version, I was told: >> "We don't have an installer at this time, and we are shortly about to >> remove that section from our website. The Boost build instructions can be >> found here ..." > Will there be no more Windows binary installers for the libraries or did I > misunderstand? Hi Wayne, What BoostPro does not have for 1.48 -- and has never made free to the public for any version -- are 64-bit installers for Windows. That was a paid service which we are now discontinuing. We may choose to make 64-bit installers freely available, time permitting, but we haven't finalized that decision yet. It's a bit of work to provide that service, and our plates have been overfull with paying work recently. -- John Wiegley BoostPro Computing http://www.boostpro.com

1 0

BoostPro (or any) installer for v1.48.0 on Windows 7/Visual Studio C++ 2010?
by Wayne Johnson 19 Dec '11

19 Dec '11

I'm new to the Boost libraries and becoming reacquainted with C++ after many years of using other languages. As recommended in section 5.1 of the "Getting Started on Windows", I visited the BoostPro website to find a Windows 7 installer for v1.48.0 to use with VS C++ 2010. In response to a followup message to BoostPro sales about the lack of an installer for the latest version, I was told: "We don't have an installer at this time, and we are shortly about to remove that section from our website. The Boost build instructions can be found here ..." Will there be no more Windows binary installers for the libraries or did I misunderstand? - wjohnson

3 3

Re: [Boost-users] [boost] [constrained_value] Constrained Value reviewresults
by Robert Ramey 19 Dec '11

19 Dec '11

Gordon Woodhull wrote: > Greetings, ... a report which sounded like an acceptance. My question is - what happened to this? What is the current status? Robert Ramey

3 2

boost::thread liker error in Release mode
by herzl&revital sham 18 Dec '11

18 Dec '11

I am write a program that use boost::thread like below class RPCClientManagment { boost::thread *pThread_; void RunSendRequestStatus() { boost::posix_time::seconds interval(30); while (bRunSendRequestStatus_) { SendRequestStatus(); boost::this_thread::sleep(interval); } } void StartRequestStatus() { bRunSendRequestStatus_ = true; pThread_ = new boost::thread(&RPCClientManagment::RunSendRequestStatus, this); } }; when I compile it in rlease mode I receive bleow error: 1>c:\program files (x86)\boost\boost_1_44\boost\asio\placeholders.hpp(91) : fatal error C1001: `An internal error has occurred in the compiler.` 1>(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x62542D7F:0x00000028]', line 182) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1>LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage 1> Version 9.00.21022.08 1> E when I comment this row error message hide //pThread_ = new boost::thread(&RPCClientManagment::RunSendRequestStatus, this); in debug mode I don't see this problem at all. I use vc++ 9

2 3

lexical cast: changesign is not a member of boost::math
by Philipp Münzel 18 Dec '11

18 Dec '11

Hi folks, I'm trying to compile the http server example of boost::asio: http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/example/http/serve… I'm using gcc 4.6 on ubuntu Linux 11.10. When compiling the reply.cpp, I get the following error: In file included from reply.cpp:13:0: /usr/local/include/boost/lexical_cast.hpp: In function ‘bool boost::detail::parse_inf_nan_impl(const CharT*, const CharT*, T&, const CharT*, const CharT*, const CharT*, const CharT*, CharT, CharT)’: /usr/local/include/boost/lexical_cast.hpp:676:31: error: ‘changesign’ is not a member of ‘boost::math’ /usr/local/include/boost/lexical_cast.hpp:693:31: error: ‘changesign’ is not a member of ‘boost::math’ /usr/local/include/boost/lexical_cast.hpp: In function ‘bool boost::detail::lcast_ret_float(T&, const CharT*, const CharT*)’: /usr/local/include/boost/lexical_cast.hpp:1025:50: error: ‘changesign’ is not a member of ‘boost::math’ I remember having compiled this example some time ago with boost 1.46 or so. Is there some regression in 1.48 that prevents this from compiling? Regards, Philipp

2 1

lexical_cast throws when used with empty vector (1.48.0)
by Braden Northington McDaniel 18 Dec '11

18 Dec '11

Boost 1.48.0's lexical_cast throws bad_lexical_cast when used with an empty vector. This is observable in the following program: #include <boost/lexical_cast.hpp> #include <cassert> #include <iostream> #include <iterator> #include <string> #include <vector> std::ostream & operator<<(std::ostream & out, const std::vector<long> & v) { std::ostream_iterator<long> it(out); std::copy(v.begin(), v.end(), it); assert(out); return out; } int main() { std::vector<long> v; //v.push_back(1); std::cout << boost::lexical_cast<std::string>(v); } If the commented line is uncommented (making the vector nonempty), the program runs without an exception. Is this the intended behavior? -- Braden McDaniel e-mail/Jabber IM: braden(a)endoframe.com http://endoframe.com

1 0

[Range] Generating a singular range.
by Robert Jones 17 Dec '11

17 Dec '11

Hi All Is there an easy and obvious way to construct a single element range from a value_type of that range? Thx - Rob.

3 2

[boost-users][container] associative placement insertion
by Cromwell Enage 17 Dec '11

17 Dec '11

Hi, all! I'm wondering how placement insertion works for pair-associative Boost.Container types. For example, given: //[ex_code struct D { D(char,char) {} // Insert Boost.Move awareness here... }; boost::container::map<int,D> my_map; //] Will my_map.emplace(0, 't', 'p') call D('t', 'p') and move the object into the map? Will Boost.Unordered work the same way? TIA! Cromwell D. Enage

1 1

[call_traits] Having trouble with call traits combined with type deduction
by Rhys Ulerich 17 Dec '11

17 Dec '11

'Afternoon, I have a quick question on call traits and template argument deduction. I want to use call_traits' value_type and param_type to deduce a signature like double desired_result(double const& x); given an argument of type double. Is there any way to get type deduction working on a snippet like lousy_attempt (below) to produce my desired_result? #include <boost/call_traits.hpp> template<typename Scalar> typename boost::call_traits<Scalar>::value_type lousy_attempt(typename boost::call_traits<Scalar>::param_type x) { return x; } int main() { double y = 5; // Works... lousy_attempt<double>(y); // "No matching function call to lousy_attempt(double&)" lousy_attempt(y); return 0; } Thanks in advance, Rhys

2 2

[MPI] compilation with c++0x and gcc-4.6
by tcb 17 Dec '11

17 Dec '11

hi, I have a problem compiling simple boost mpi programs with gcc4.6 on osx. The broadcast_test.cpp from libs/mpi/test compiles just fine with the -std=gnu++98, but when I use -std=gnu++0x I get a compilation error which seems to implicate boost::serialization. The code compiles just fine with gcc-4.4 and gcc-4.7 with the -std=gnu++0x flags. There is no c++0x specific code in the test file itself. Any ideas what the problem is with gcc-4.6 and -std=gnu++0x? $ OMPI_CXX=g++-mp-4.6 openmpic++ -std=c++0x -m64 -o broadcast_test broadcast_test.cpp -lboost_mpi-mt -lboost_serialization-mt In file included from /opt/local/include/boost/mpi/collectives.hpp:21:0, from /opt/local/include/boost/mpi/collectives_fwd.hpp:19, from /opt/local/include/boost/mpi/collectives/broadcast.hpp:11, from broadcast_test.cpp:8: /opt/local/include/boost/mpi/communicator.hpp:1633:58: error: specialization of 'boost::mpi::status boost::mpi::communicator::recv(int, int, T&) const [with T = boost::mpi::packed_iarchive]' after instantiation /opt/local/include/boost/mpi/communicator.hpp:1668:65: error: specialization of 'boost::mpi::request boost::mpi::communicator::isend(int, int, const T&) const [with T = boost::mpi::packed_oarchive]' after instantiation In file included from /opt/local/include/gcc46/c++/vector:64:0, from /opt/local/include/gcc46/c++/bits/random.h:34, from /opt/local/include/gcc46/c++/random:50, from /opt/local/include/gcc46/c++/bits/stl_algo.h:67, from /opt/local/include/gcc46/c++/algorithm:63, from /opt/local/include/boost/optional/optional.hpp:19, from /opt/local/include/boost/optional.hpp:15, from /opt/local/include/boost/mpi/communicator.hpp:18, from /opt/local/include/boost/mpi/collectives.hpp:21, from /opt/local/include/boost/mpi/collectives_fwd.hpp:19, from /opt/local/include/boost/mpi/collectives/broadcast.hpp:11, from broadcast_test.cpp:8: /opt/local/include/gcc46/c++/bits/stl_uninitialized.h: In function 'void std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator&) [with _ForwardIterator = char*, _Size = long unsigned int, _Allocator = boost::mpi::allocator<char>]': /opt/local/include/gcc46/c++/bits/vector.tcc:474:8: instantiated from 'void std::vector<_Tp, _Alloc>::_M_default_append(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /opt/local/include/gcc46/c++/bits/stl_vector.h:592:4: instantiated from 'void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /opt/local/include/boost/mpi/detail/packed_oprimitive.hpp:96:46: instantiated from here /opt/local/include/gcc46/c++/bits/stl_uninitialized.h:576:6: error: no matching function for call to 'boost::mpi::allocator<char>::construct(char*)' /opt/local/include/gcc46/c++/bits/stl_uninitialized.h:576:6: note: candidate is: /opt/local/include/boost/mpi/allocator.hpp:168:8: note: void boost::mpi::allocator<T>::construct(boost::mpi::allocator<T>::pointer, const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*] /opt/local/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 arguments, 1 provided In file included from /opt/local/include/boost/serialization/extended_type_info_typeid.hpp:37:0, from /opt/local/include/boost/archive/detail/oserializer.hpp:38, from /opt/local/include/boost/mpi/detail/mpi_datatype_oarchive.hpp:14, from /opt/local/include/boost/mpi/detail/mpi_datatype_cache.hpp:13, from /opt/local/include/boost/mpi/datatype.hpp:27, from /opt/local/include/boost/mpi/communicator.hpp:20, from /opt/local/include/boost/mpi/collectives.hpp:21, from /opt/local/include/boost/mpi/collectives_fwd.hpp:19, from /opt/local/include/boost/mpi/collectives/broadcast.hpp:11, from broadcast_test.cpp:8: /opt/local/include/boost/serialization/access.hpp: In static member function 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = boost::mpi::packed_oarchive]': /opt/local/include/boost/serialization/serialization.hpp:69:5: instantiated from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = boost::mpi::packed_oarchive]' /opt/local/include/boost/serialization/serialization.hpp:128:9: instantiated from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = boost::mpi::packed_oarchive]' /opt/local/include/boost/archive/detail/oserializer.hpp:148:5: instantiated from 'void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::mpi::packed_oarchive, T = boost::mpi::packed_oarchive]' broadcast_test.cpp:153:1: instantiated from here /opt/local/include/boost/serialization/access.hpp:118:9: error: 'class boost::mpi::packed_oarchive' has no member named 'serialize' /opt/local/include/boost/serialization/access.hpp: In static member function 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = boost::mpi::packed_iarchive]': /opt/local/include/boost/serialization/serialization.hpp:69:5: instantiated from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = boost::mpi::packed_iarchive]' /opt/local/include/boost/serialization/serialization.hpp:128:9: instantiated from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = boost::mpi::packed_iarchive]' /opt/local/include/boost/archive/detail/iserializer.hpp:188:5: instantiated from 'void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_iarchive, T = boost::mpi::packed_iarchive]' broadcast_test.cpp:153:1: instantiated from here /opt/local/include/boost/serialization/access.hpp:118:9: error: 'class boost::mpi::packed_iarchive' has no member named 'serialize'

1 0

Re: [Boost-users] [BGL] Issue using connected_components
by Nicolas Saunier 16 Dec '11

16 Dec '11

Hi everyone, I finally found a solution by myself to get connected_components from a graph of type adjacency_list<listS, listS, undirectedS> with bundled properties for the vertices and edges. So I will post it here so that others can find it, to get feedback and make sure I am doing it right: #include <boost/graph/adjacency_list.hpp> #include <boost/graph/connected_components.hpp> using namespace boost; using namespace std; struct FeatureConnection { float minDistance; float maxDistance; }; struct VertexInformation { int featureId; int index; }; typedef adjacency_list<listS, listS, undirectedS, VertexInformation, FeatureConnection> UndirectedGraph; int main() { UndirectedGraph g; UndirectedGraph::vertex_descriptor u, v, w, x, y; UndirectedGraph::edge_descriptor e, f; u = add_vertex(g); v = add_vertex(g); w = add_vertex(g); x = add_vertex(g); y = add_vertex(g); bool unused; tie(e, unused) = add_edge(u, v, g); tie(f, unused) = add_edge(x, y, g); cout << num_vertices(g) << " " << num_edges(g) << endl; graph_traits<UndirectedGraph>::vertex_iterator vi, vend; graph_traits<UndirectedGraph>::vertices_size_type cnt = 0; for(tie(vi,vend) = vertices(g); vi != vend; ++vi) g[*vi].index = cnt++; property_map<UndirectedGraph, int VertexInformation::*>::type components = get(&VertexInformation::index, g); int num = connected_components(g, components, vertex_index_map(get(&VertexInformation::index, g))); cout << num << endl; for(tie(vi,vend) = vertices(g); vi != vend; ++vi) cout << *vi << " " << components[*vi] << " " << g[*vi].index << endl; return 0; } Thanks, Nicolas -- Nicolas Saunier, ing. jr, Ph.D. Professeur Adjoint / Assistant Professor Département des génies civil, géologique et des mines (CGM) École Polytechnique de Montréal http://nicolas.saunier.confins.net

1 0

Boost on Mac w/ C++2011
by John M. Dlugosz 16 Dec '11

16 Dec '11

A co-worker reports that on a Mac, turning on the C++2011 dialect (to enable 'auto', lvalue references, etc.) makes the Boost headers choke. The release notes for the latest Boost show an older version of the compiler (Clang) as what is supported. Is there a simple way, like with a #define or a published patch to the config files, to make it work? —John

1 0

Condition Variable and optimization
by John M. Dlugosz 16 Dec '11

16 Dec '11

The example in the documentation for Condition Variables illustrates the implication that these are Mesa-style (non-blocking signals) with this example: boost::condition_variable cond; boost::mutex mut; bool data_ready; void process_data(); void wait_for_data_to_process() { boost::unique_lock<boost::mutex> lock(mut); while(!data_ready) { cond.wait(lock); } process_data(); } This needs to declare data_ready as mutable, so the compiler doesn't reduce the while loop to a no-op and assume the value doesn't change, or just hold it in a register so it doesn't see the change made by another thread. More generally, how do you write it in this case? while ( !collection.empty() ) cond.wait(lock); where the condition is a function of an existing class? The compiler might inline that function and give the same issue. I think a form of wait that takes a predicate ought to be introduced, that prevents this particular issue and ensures correct use. —John

2 2

Parsing statements from ascii files in arbitrary order into hierarchies of structs using boost spirit
by Stefan Zellmann 16 Dec '11

16 Dec '11

Hello! I'd like to parse one-line statements from an ascii file using boost spirit into structs. Statements may be quite different and may occur in arbitrary order. I'm wondering how I can achieve something like the following: /qi::rule<T, Statement(), Skipper> r_statement; qi::rule<T, DerivedStatement0(), Skipper> r_derivedStatement0; qi::rule<T, DerivedStatement1(), Skipper> r_derivedStatement1;/ With: /struct Statement { // empty }; struct DerivedStatement0 : public Statement { // members }; struct DerivedStatement1 : public Statement { // members };/ First thing I'm not sure about is how to adapt (using /BOOST_FUSION_ADAPT_STRUCT/) this hierarchy, since /Statement/ has no members. I've seen some snippets on the internet where inherited members (data members are good for me, no member functions) were adapted using /BOOST_FUSION_ADAPT_STRUCT/, so I'm right to believe that inheritance in my case shell pose no problem? Well, I'm actually not sure if the idea I came up with is the right way to accomplish this in the first place, so I'm grateful for any suggestions on how to do this more appropriately. Thanks in advance! Cheers, Stefan -- Stefan Zellmann Dipl.-Wirt.-Inf. Universität zu Köln RRZK Phone: +49 221 478 86578 Mail: zellmans(a)uni-koeln.de

2 3

[Geometry] 3D Oriented Bounding Box
by Jérémy Coulon 15 Dec '11

15 Dec '11

Hi All, Boost.Geometry looks promising for my personal projects. Reading the doc, I couldn't figure if it is possible to create a 3D oriented bounding box (OBB). I read that axis aligned bounding box (AABB) is supported but nothing on OBB. I need to use it in usual algorithms like intersetion, distance, ... Can anybody tell me if it is possible with the current Boost version and how I can achieve that ? Thanks. Jérémy

3 4

Boost Threads on Android
by John M. Dlugosz 15 Dec '11

15 Dec '11

I've heard that there are some issues with using Boost libraries that are not header-only on the Android platform. Where might I find some real information on that?

2 1

no thread pool?
by Jeff Graham 15 Dec '11

15 Dec '11

Hello, I do not see a thread pool in current boost. Has one never been accepted? Thanks.

2 1

[gil] Project Link
by Dan Bloomquist 15 Dec '11

15 Dec '11

I have put my adventure with gil on the web, this is just the start. If I have any stuff that needs attention about gil, I'd like to hear it. I'm thinking this will help others that have not started with gil yet. <http://lakeweb.net/test/codeproject.html> Best, Dan.

2 1

Re: [Boost-users] [Units] Temperature conversion problem
by Pieter 14 Dec '11

14 Dec '11

>>>> If 'f' is 212ÂºF, why, when converting it to ÂºC, do I end up at 117 and change? Is this really what we should expect? It seems that this very simple use case produces unexpected, and to a casual user wrong, results. I understand the need for complexity but it seems to show up very early in the user experience. >>> >>> Because a temperature change of 212ÂºF is equal to a temperature change of 117.778ÂºC = (5/9)*212. What would you expect the following to do: > > >> [ snipped a very complete response ] > >> Hi Matthias, > > Sorry, I didn't explain myself very well. I was merely surprised that quantities of temperature are, by default, temperature differences not absolute temperatures. With my rusty engineering hat on, I'd have expected quantities of temperature to be absolute so they're consistent with the published literature. I think of temperature differences as needing explanation such as outputting a Celsius temperature difference as Âºâˆ†C (delta ÂºC, ÂºdC, ...) rather than expressing a temperature difference with just ÂºC. Operating under the principle of least surprise, I found the default temperature behavior surprising, that's all. I don't know how useful temperature difference by itself really is but I'd guess it's less common than absolute temperatures or normalized temperatures though differences are useful, for example, in temperature gradients. >Don't mean to come across as prickly - there was just a lengthy debate on this topic during review. Basically, while the first order "principle of least surprise" is probably for temperatures to be absolute, this would make quantities of temperature an anomalous special case relative to all other quantities and would immediately cause problems when someone wanted, e.g., to implement something like the Planck radiation law, etc... In any case, we do appreciate feedback and try to incorporate suggestions for improvements wherever possible. >Cheers, >Matthias Dear Matthias, In the example given by you earlier: quantity<fahrenheit::temperature> f(32*fahrenheit::temperature()); quantity<celsius::temperature> c(0*celsius::temperature()); std::cout << f+quantity<fahrenheit::temperature>(c) << std::endl; std::cout << quantity<celsius::temperature>(f)+c << std::endl; would give different outputs 32+32 = 64 and 0+0 = 0 if the temperature were to be interpreted as being absolute. As far as I see it, it is in fact not ‘the order of conversion, but rather the scale that is used to do the addition in is what matters: in the Fahrenheit scale, taking twice the absolute temp. means something different than taking twice the absolute temperature in the Celsius scale (due to the affine relation between the scales). This does not make it meaningless to allow such additions (or other arithmetic operations). To give an example: take Plank’s radiation law which computes radiation of a body as a function of the temperature T in K, which is of the form (for appropriate constants a1 and a2): B(T) = a1*(1-exp(a2*T))^-1 As arithmetic is not allowed on absolute temperatures, my implementation would have to define T as a relative temperature, something like (in admittedly non-compiling 'code'): quantity<intensity> BodyRadiation(const quantity<si::temperature>& T) { // define a1 and a2 here return a1*(1/(1-std::exp(a2*T))); } Suppose the radiating body is at room temperature which I measure using my thermometer on the wall as 20.0 degrees Celsius. When I would define this as a relative temperature: quantity< celsius::temperature> TRoomInCelcius(20.0); and plug it into the radiation law: Intensity = BodyRadiation(quantity<si::temperature>(TRoomInCelcius)) This would give wrong results (without any warning) as the value T = 20K would be used unintentionally. I know it is the intent of the library to emphasize safety over convenience but I fail to see a problem with my abstraction here, while I don't regard this safe behavior. To get correct results I would need to define my room temperature as being absolute: quantity< absolute<celsius::temperature> > TRoomInCelcius (20.0); then translate it into an absolute temperature in K: quantity<absolute< si::temperature> > TRoomInK(TRoomInCelcius); and then ‘somehow’ translate this into a relative temperature to be plugged into the model, maybe like: quantity<absolute<si::temperature> > TZero(0*si::kelvin) ; quantity<si::temperature> T(TRoomInK – TZero); Intensity = BodyRadiation(T) which is far from elegant of course. Core of the matter is that I need the temperature to be converted using the ‘absolute’ notion, while I need it to be interpreted as ‘relative’ to be able to use it in the radiation law. This while the underlying numerical value of the ‘relative’ and ‘absolute’ temperature is the same and in both cases represents the same measured value. If arithmetic on the absolute type was allowed, this could all be avoided as the model could be specified in ‘absolute’ temperature – I don’t really understand why you say that would not make sense. I am not sure whether there is an elegant solution to allow this in natural manner. Maybe conversion for units with affine relations between scales should only be allowed to be explicitly done in either the absolute or relative manner, which could possibly also relieve the need for two different 'types' of temperature; as the example shows a single measurement can have both 'relative' and 'absolute' interpretations in the current system depending on the context in which it is used and the type of conversion that the context requires. Does this make any sense to you? Kind regards, Pieter

1 0

b-tree merge
by Jeff Ramsey 14 Dec '11

14 Dec '11

As an example, I've the following b-tree model with each node containing tag/value pairs. The tree indicates precedence (or priority), with the root being highest, down to the leaves as lowest (but this is application specific). I want to merge a new tree section into the parent, with the new section containing potentially common tag/value pairs all the way down to the node just above a leaf node (a completely duplicate new tree section would just not be merged). E.g. Existing tree (tag,value) pairs indicated: A,0 ,----------,----|--------, B,1 B,2 B,3 ,------|------, C,1 C,2 New tree to merge: A,0 | B,3 ,------|------, C,1 C,2 Final merged tree: A,0 ,----------,----|--------------, B,1 B,2 B,3 ,------|------, ,-----------, C,1 C,2 C,1 C,2 Question: is there a boost solution to this b-tree merge, and if not any suggestions? Thanks.

1 0

[Ref] unwrap_ref and TR1
by Krzysztof Żelechowski 14 Dec '11

14 Dec '11

The following code is valid: #if 1 #include <boost/ref.hpp> int const & (&b_unwrap_ref) (int const &) ((::boost ::unwrap_ref)); #endif The following code, however, is not (as of libstdc++ 4.5.1): #if 1 #include <tr1/functional> int const & (&tr1_unwrap_ref) (int const &) ((::std ::tr1 ::unwrap_ref)); #endif With the following diagnostic: > error: ‘unwrap_ref’ is not a member of ‘std::tr1’ So I started to ask myself: WTF? * It turns out that unwrap_ref did not make it to TR1, although reference_wrapper did. But why? * Because ref.hpp did not provide it when TR1 was formed? [1] Implication: * unwrap_ref (std:: reference wrapper) is a mismatch. #if 1 void test () { unwrap_ref (::boost ::cref (0)); unwrap_ref (::std ::tr1 ::cref (0)); // error: ‘unwrap_ref’ was not declared in this scope ::boost ::unwrap_ref (::std ::tr1 ::cref (0)); // error: error: invalid initialization of non-const reference } #endif Shouldn't we do something about it? Like, e.g., extend the scope of unwrap_ref to cover the corresponding standard class? This would at least allow expression #3. Chris ___ [1] <URL: https://svn.boost.org/svn/boost/!svn/bc/16384/trunk/boost/boost/ref.hpp >

1 0

challange to MPL gurus
by Robert Ramey 14 Dec '11

14 Dec '11

I am trying to implement concept checking for a couple of MPL concepts as part of a large project. I've having a heck of a time with some aspects of this. The example below illustrates one of the problems I'm having. The intent is to test the concept. for next<I>, the concept check is invoked recurrsively until the end of iteration is encountered. (I'm assuming it's a list in this test). But the is_end<false_> branch is always invoked leading to failure on both MSVC 9.0 and gcc 4.5.3 compilers I'll be quite impressed with anyone who can figure out how to make this work. Robert Ramey template<typename I> struct ForwardIterator { template<typename B> struct is_end {}; template<> struct is_end<false_> { typedef typename deref<I>::type t1; typedef typename next<I>::type t2; BOOST_CONCEPT_ASSERT(( ForwardIterator<t2> )); }; typedef typename boost::mpl::print< I >::type t1; typedef typename is_end< typename boost::is_same< boost::mpl::l_iter<boost::mpl::l_end>, I > > type; BOOST_MPL_ASSERT(( is_convertible< typename I::category, forward_iterator_tag > )); }; template<typename S> struct ForwardSequence { typedef typename end<S>::type t2; BOOST_CONCEPT_ASSERT(( ForwardIterator<t2> )); }; #include <boost/mpl/list.hpp> void test_list_sequence(){ BOOST_CONCEPT_ASSERT(( boost::mpl::ForwardSequence< boost::mpl::list<int, char> > )); }

4 15

Re: [Boost-users] Removing a vertex and adding another one with the same id causes segmentation fault?
by Alper Aydemir 14 Dec '11

14 Dec '11

The formatting went bad with the previous email. Sorry about that. Here it is once again. Hello, I'm using a labeled graph typedef boost::labeled_graph<boost::adjacency_list<boost::listS, boost::listS, boost::undirectedS, Room, RoomEdge>,std::string> MyGraph; which lets me access vertices with string ids. I add a vertex and set it's relevant fields this way: MyVertex u = boost::add_vertex(id, g); g[id].category = category; //crashes here g[id].vertex_id = id; Here id is an std::string. And remove them like so: // First we remove all edges from this vertex BGL_FORALL_VERTICES(v, g, MyGraph){ if (QString(g.graph()[v].vertex_id.c_str()).compare(roomIdToBeRemoved) == 0){ ve = v; BGL_FORALL_OUTEDGES(v, e, g, MyGraph) { ev.push_back(e); } } } foreach(MyEdge e, ev){ remove_edge(e,g); } // Then we remove the vertex itself remove_vertex(roomIdToBeRemoved.toStdString().c_str(),g); This so far seems to work. The trouble is, if I want to add a removed vertex once again with the same id, I get the following: Exception Type: EXC_BAD_ACCESS (SIGSEGV) while setting the fields of the newly added vertex (above commented "crashes here"). What might be the reason? I'm using boost functions for removing/adding things.

1 0

Error in accessing label of an edge, urgently need help.
by Amanullah Yasin 14 Dec '11

14 Dec '11

Hello, I want to put edge label but facing an error. Please share any better idea. Thanks in advance. YASIN ======================= My graph is: namespace boost { struct computable_object_t { typedef vertex_property_tag kind; }; } typedef boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::computable_object_t, plComputableObject*> > slVertexProperty; typedef boost::property<boost::edge_weight_t, slScoreValueType, boost::property<boost::edge_name_t, std::string>> slEdgeProperty; typedef boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, slVertexProperty, slEdgeProperty> slGraph; slGraph graph; .... ... //Now i want to add edge name boost::property_map<slGraph, edge_name_t>::type labelmap = get(edge_name, graph); for(tie(ei, ei_end) = edges(graph); ei != ei_end; ++ei){ string label = "unknown"; put(labelmap, *ei, label); cout<<"\nUndirected s: "<<vertex_id[source(*ei, graph)] <<" T: "<<vertex_id[target(*ei, graph)]<<" LABEL: "<< get(labelmap,*ei); } ////////////But it gives me an error//////////////// E:\ProBT22\boost_1_46_1\boost/property_map/property_map.hpp(361): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const std::string' (or there is no acceptable conversion) 1> E:\ProBT22\boost_1_46_1\boost/pending/detail/property.hpp(21): could be 'boost::detail::error_property_not_found &boost::detail::error_property_not_found::operator =(const boost::detail::error_property_not_found &)' 1> while trying to match the argument list '(boost::detail::error_property_not_found, const std::string)' 1> MMHC\ResultAnalysis.cpp(558) : see reference to function template instantiation 'void boost::put<boost::adj_list_edge_property_map<Directed,Value,Ref,Vertex,Property,Tag>,Ref,boost::detail::edge_desc_impl<Directed,Vertex>,std::string>(const boost::put_get_helper<Reference,LvaluePropertyMap> &,K,const V &)' being compiled 1> with 1> [ 1> Directed=boost::bidirectional_tag, 1> Value=boost::detail::error_property_not_found, 1> Ref=boost::detail::error_property_not_found &, 1> Vertex=void *, 1> Property=boost::property<boost::edge_weight_t,slScoreValueType>, 1> Tag=boost::edge_name_t, 1> Reference=boost::detail::error_property_not_found &, 1> LvaluePropertyMap=boost::adj_list_edge_property_map<boost::bidirectional_tag,boost::detail::error_property_not_found,boost::detail::error_property_not_found &,void *,boost::property<boost::edge_weight_t,slScoreValueType>,boost::edge_name_t>, 1> K=boost::detail::edge_desc_impl<boost::bidirectional_tag,void *>, 1> V=std::string 1> ]

2 2

boost::hashes status
by Martin Dyring-Andersen 14 Dec '11

14 Dec '11

Hello, I've been using (parts of) the boost::hashes library for some time, and it seems to work quite well. Thanks Scott! A few changes are necessary to compile without errors and warnings Visual Studio 10 (see attached). I was wondering what the plans are for making it an official library? IMO it would be a very nice addition. As I recall, a suggestion was made to rename the library to boost::digest instead, to avoid confusion with boost::hash and the plural form. That seems sensible to me. -- Best regards, Martin Dyring-Andersen

2 1

Ambiguous boost::move
by Kelvin Chung 13 Dec '11

13 Dec '11

I'm having this compiler issue while trying to use boost::packaged_task (gcc, C++03, move emulation). When I try to compile, I get the following: src/KMBuilder.cpp:54: error: call of overloaded ‘move(boost::unique_future<long unsigned int>&)’ is ambiguous boost/include/boost/thread/detail/move.hpp:44: note: candidates are: typename boost::enable_if<boost::is_convertible<T&, boost::detail::thread_move_t<T> >, boost::detail::thread_move_t<T> >::type boost::move(T&) [with T = boost::unique_future<long unsigned int>] boost/include/boost/move/move.hpp:294: note: typename boost::move_detail::disable_if<boost::has_move_emulation_enabled<T>, T&>::type boost::move(T&) [with T = boost::unique_future<long unsigned int>] The offending line of code: futures.push_back(boost::move(taskResult)); // futures is a boost::container::deque Is there a way to force one version of boost::move over the other? If so, which one should I use?

3 2

Using unique_future in C++03, boost 1.47.0
by Kelvin Chung 13 Dec '11

13 Dec '11

I have a bunch of boost::packaged_task<unsigned long>, which I intend to execute on separate boost::threads. Before I do that, though, I want to insert each boost::unique_future<unsigned long> in a container as I make them. Given that I am using C++03 and boost 1.47.0 (boost 1.48.0 craps out over an ambiguous overload of boost::move), I have something like the following: std::deque<boost::unique_future<unsigned long>> futures; // std::deque<boost::thread> evalThreads; TODO for (…) { boost::packaged_task<unsigned long> task = …; // Create the tasks, one at a time boost::unique_future<unsigned long> taskResult = task.get_future(); // boost::thread taskThread(boost::move(task)); TODO // boost::unique_future and boost::thread can't be copied, but can be moved futures.push_back(boost::move(taskResult)); // evalThreads.push_back(boost::move(taskThread)); TODO } boost::wait_for_all(futures.begin(), futures.end()); // Now we can do stuff with futures The problem is that the code above is failing to compile, saying that /usr/include/c++/4.1.2/ext/new_allocator.h:104: error: passing ‘const boost::unique_future<long unsigned int>’ as ‘this’ argument of ‘boost::unique_future<R>::operator boost::detail::thread_move_t<boost::unique_future<R> >() [with R = long unsigned int]’ discards qualifiers I don't fully understand the problem, but I blame the move emulation. How do I fix this?

2 1

boost::shared_locks and boost::upgrade_locks
by Kelvin Chung 13 Dec '11

13 Dec '11

I'm trying to implement a read-write lock, and I was told to use boost::upgrade_lock. However, only one thread can have a boost::upgrade_lock, and everyone else gets blocked, so it's not much on the read end. (Correct me if I am wrong, but boost::upgrade_lock only waits if someone has exclusive, but someone with boost::upgrade_lock will cause everyone else to block) But reads are cheap in my case - I just need to use locks for a cache. So, suppose I have the following: class Cache { std::map<Input, Output> cache; boost::shared_mutex mutex; public: Output query(const Input& in); }; It would appear that the proper way to implement Cache::query() is as follows: Output query(const Input& in) { boost::shared_lock<boost::shared_mutex> readLock(mutex); if (cache.count(in) == 0) { readLock.unlock(); boost::unique_lock<boost::shared_mutex> writeLock(mutex); // Check to see if the result was added while waiting for lock if (cache.count(in) != 0) return cache[in]; cache[in] = compute_output(in); return cache[in]; } else { return cache[in]; } } Is this correct? Or maybe it should be this: Output query(const Input& in) { boost::shared_lock<boost::shared_mutex> readLock(mutex); if (cache.count(in) == 0) { readLock.unlock(); boost::upgrade_lock<boost::shared_mutex> rereadLock(mutex); // Check to see if the result was added while waiting for lock if (cache.count(in) != 0) { return cache[in]; } else { boost::upgrade_to_unique_lock<boost::shared_mutex> writeLock(rereadLock); cache[in] = compute_output(in); return cache[in]; } } else { return cache[in]; } } A side question is that if compute_output() is an expensive operation, should that be moved to the part between releasing the read lock and getting the write/reread lock?

5 9

Priority task queues using Boost.Asio and Boost.Thread
by Kelvin Chung 13 Dec '11

13 Dec '11

Suppose I have this abstract class Task like so: struct Task { virtual int doStuff() = 0; }; I then also have this: class CompositeTask : public Task { std::vector<Task> tasks; public: int doStuff() { for (std::vector<Task>::const_iterator it = tasks.begin(); it != tasks.end(); ++it) { it->do_stuff(); } } }; Now suppose that there is a point where I have a list of Tasks and I want to have them executed concurrently. To do so, I've leveraged Boost.Asio to create a thread pool task queue construct (via boost::asio::io_service). The next step beyond that is that I want to evaluate each of the tasks in CompositeTasks in parallel. I have a few questions about this: * One idea is to make a separate task thread for each CompositeTask. I'm under the impression that there is an absolute limit to the number of threads that I can make, which is determined by boost::thread::hardware_concurrency(). Is this true? If so, if the main Task queue has that many threads, would making a second task queue fail because it can't get more? * If I keep to one task queue (ie. throw all the Tasks in the CompositeTask to the main Task queue), then the possiblity exists of some kind of starvation (eg. the queue is full of CompositeTasks, and they are all blocking due to dependencies on Tasks in the queue). Is there a way to prioritize Tasks in the queue so that this doesn't happen?

3 2

Try-upgrade locking
by Kelvin Chung 13 Dec '11

13 Dec '11

Suppose I have a boost::upgrade_lock<boost::shared_mutex>. When I want to create the boost::upgrade_to_unique_lock<boost::shared_mutex> and upgrade to exclusive locking, this blocks until all the shared lock holders leave. However, it does not appear that there is a non-blocking version of this, unlike, say, making a boost::unique_lock<boost::shared_mutex> and passing in boost::try_to_lock. So what should I do in order to create my own "try-upgrade" lock? I'm trying to use it like so: boost::upgrade_lock<boost::shared_mutex> upgradeLock(mutex); ... if (...) { // Substitute for boost::upgrade_to_unique_lock<boost::shared_mutex>, but also with aspects of // boost::try_to_lock, basically my_upgrade_to_unique_lock<boost::shared_mutex> deferredWriteLock(lock); // Do stuff where it doesn't matter whether I have exclusive or not, while the readers leave if (!deferredWriteLock) deferredWriteLock.lock(); // Now we need exclusive // We have exclusive, do more stuff } // Back to regular upgrade_lock here

3 2

Boost matix question from a newbie
by boostnewbie 13 Dec '11

13 Dec '11

Hello, I want to use the boost matrices, and I have examples how to deal with that. But now, I want to store those matrix in a std-Array or an std-list. To do this, I must be able to name the type of for example a 3X3 matrix. I mean I nbeed an expressione similar to std::vector<matrix<double>> trafos; but I don´t know how to say that the matrix is a 3X3 type. Thanks in advence Egon -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-matix-question-from-a-newbie-tp418… Sent from the Boost - Users mailing list archive at Nabble.com.

3 2

shared_ptr to object in stl set container?
by Galen 13 Dec '11

13 Dec '11

Hi, -- I'm trying to use shared_ptr in a stl set, but am having trouble with find() Any help? Documentation on this seems hard to find. -- Also, are the overloaded < and == useful or correct here? thanks! Output is: ------------------ 0 adding neighbor 1 0 adding neighbor 2 1 adding neighbor 0 2 adding neighbor 1 0's neighbors 1 has 1 neighbors 0 2 has 1 neighbors 1 NOT WORKING is 1 a neighbor of 0? 0 is 0 a neighbor of 1? 0 Code below: ------------------- #include<set> #include<iostream> #include<boost/shared_ptr.hpp> using namespace std; //use typedef instead in actual code #define NodePtr boost::shared_ptr<Node> // TODO: should this extend shared_ptr? class Node { private: int id; set<NodePtr> neighbors; public: Node() { } Node(int newID) { id = newID; } ~Node() { } int getID() { return id; } int addNeighbor(NodePtr newNode) { int newID; newID = newNode->id; // if not already a neighbor, add if (!isNeighbor(newID)) neighbors.insert(newNode); } set<NodePtr> getNeighbors() { return neighbors; } bool isNeighbor(int searchID) { set<NodePtr>::iterator it; // check if this neighbor already in list NodePtr searchNode(new Node(searchID)); it = neighbors.find(searchNode); // if not found, add to neighbors if (it == neighbors.end()) { return false; } //else return true; } //overload == for find() bool operator== (NodePtr otherNode) { cout << "==: " << otherNode->id << " " << id << endl; return (otherNode->id == id); } //overload < in case we want to sort bool operator< (NodePtr otherNode) { return (id < otherNode->id); } }; int main() { // the nodes are pointers to Node objects NodePtr n0(new Node(0)); NodePtr n1(new Node(1)); NodePtr n2(new Node(2)); cout << n0->getID() << " adding neighbor " << n1->getID() << endl; n0->addNeighbor(n1); cout << n0->getID() << " adding neighbor " << n2->getID() << endl; n0->addNeighbor(n2); cout << n1->getID() << " adding neighbor " << n0->getID() << endl; n1->addNeighbor(n0); // cout << n2->getID() << " adding neighbor " << n0->getID() << endl; // n2->addNeighbor(n0); cout << n2->getID() << " adding neighbor " << n1->getID() << endl; n2->addNeighbor(n1); set<NodePtr> neighbors = n0->getNeighbors(); set<NodePtr>::iterator NB; int id = n0->getID(); cout << id << "'s neighbors" << endl; for (NB = neighbors.begin(); NB != neighbors.end() ; NB++) { set<NodePtr> neighborsList = (*NB)->getNeighbors(); cout << (*NB)->getID() << " has " << neighborsList.size() << " neighbors" << endl; cout << (*neighborsList.begin())->getID() << endl; } // http://www.engr.sjsu.edu/wbarrett/SortFind.htm cout << "NOT WORKING" << endl; cout << "is 1 a neighbor of 0? " << n0->isNeighbor(1) << endl; cout << "is 0 a neighbor of 1? " << n1->isNeighbor(0) << endl; }

6 11

Re: [Boost-users] Boost-users Digest, Vol 2933, Issue 5
by Marat Abrarov 13 Dec '11

13 Dec '11

Hi, Rory. > Is there a reason io_service::run does not set an appropriate error on the > passed boost::system::error_code object when this is encountered? Certainly > it seems like an error case and would help circuital circumstances such as > my own. With current behavior of asio::io_service we can continue working with io_service after it was stopped by calling asio::io_service::reset(). It's like pause on io_service. It's not often used feature but it is nice to know that such behavior is possible. Also note that invocation of handlers is done only within threads that executes asio::io_service::run (run_one, poll, poll_one - http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/overview/core/thre…) When io_service switches to the "stopped" state asio::io_service::run have to exit as fast as possible. When io_service is already in the "stopped" state asio::io_service::run have to exit immediately. So if io_service is already in stopped state before any user thread calls asio::io_service::run how can Asio pass "appropriate error" to asynchronous completion handlers? IMHO, current design of Asio is very clear. Regards, Marat Abrarov.

2 1

Re: [Boost-users] incompatible serialization format of boost::property_tree between 1.44 and 1.48 (Robert Ramey)
by kpzhang 13 Dec '11

13 Dec '11

Hi Robert, os: windows 7 compiler: visual studio 2008 sample code: #include <iostream> #include <string> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/json_parser.hpp> int main() { std::string str; { std::stringstream sstr; boost::property_tree::ptree pt; char a= '\0'; pt.put("a",a); boost::property_tree::write_json(sstr, pt); str = sstr.str(); std::cout << str << std::endl; } { std::stringstream sstr(str); boost::property_tree::ptree pt; boost::property_tree::read_json(sstr, pt); char a = '\1'; std::cout << (int)pt.get("a",a) << std::endl; } return 0; }

1 0

Request for change on Solaris platform
by Leo Carreon 13 Dec '11

13 Dec '11

Hi, I have just discovered that the Apache Standard C++ Library (stdcxx4) is now available in both Solaris 10 U10 and Solaris 11. Would it be possible to add stdcxx4 as a standard library option for Solaris on the next Boost release? Kind regards, Leo

1 0

[BGL] Default-constructibility of vertices
by Kelvin Chung 13 Dec '11

13 Dec '11

Suppose I have a class hierarchy, like so: struct Foo { virtual Output doSomething(const Input& in); }; class CompositeFoo { std::vector<Foo*> fooList; // Use your favorite smart pointer standin for Foo* here public: Output doSomething(const Input& in); }; Now, suppose I have a functor: class Functor { Foo* foo; Input input; // assume Input is copyable public: Output operator()() { foo->doSomething(input); } }; Now, the structure of doSomething() calls leads to a DAG structure with Functor as the vertices. What I want to do is create a graph with BGL that shows that structure, before topologically sorting it and doing other stuff with it. However, it would appear that the vertices of the graph (which I would assume to be of type boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, Functor>) must be default-constructible, which Functor is clearly not. Is there a nice workaround to this without changing the vertex type to Functor* (again, use your favorite smart pointer standin for Functor* here)?

2 1

[boost] [review] [Local] Review Result - ACCEPTED
by Jeffrey Lee Hellrung, Jr. 13 Dec '11

13 Dec '11

Local is ACCEPTED into Boost. After following the lively Local review discussion several weeks ago, and reviewing the discussion a second (and sometimes third) time, I have come to the above conclusion. There was quite a bit of passion on both the sides of "aisle", and thus, obviously, no decision I make would be well-received by all. Let me start by summarizing the main arguments against including Local in Boost: (a) Local functions are not very useful, at least in the presence of existing alternatives (e.g., namespace functions and Boost.Phoenix). (b) Local is really a portability library for C++03 presenting an imperfect emulation of features readily available in C++11. (c) Local's interface is primarily macro-based, making code ugly and difficult to read. In my opinion as the review manager, a sufficient number of individuals in the discussion found the library "useful" to address (a) (sometimes with additional positive adverbs); indeed, at least a couple individuals have shared positive experiences with real-world use. Namespace functions require one to move code to somewhere other than where one may prefer to have it, and often requires a significant amount of boilerplate when binding local variables. Aside from any perceived issues with Boost.Phoenix's syntax and compiler error messages, it has been noted that binding member functions within Boost.Phoenix can get ugly. As far as (b) is concerned, the community seems pretty far from reaching a consensus on whether a library described by (b) belongs in Boost. There are certainly libraries currently in Boost that could be pegged to satisfy (b) as well, though they all have other mitigating features they make their situation different from Local in some way. As far as (c) is concerned, several have acknowledged that a macro-based interface is necessary to implement local functions in C++03, and it seems to have been generally agreed that, given this limitation, Lorenzo has done an admireable job making the interface as easy-to-use as possible. Some find it ugly, others find it reasonable. In addition to the counterarguments of (a-c) above, the following facts weighed into my final decision: * Lorenzo has been engaging and in constant communication with the developer's list during the development of Local. This gives me confidence that he will continue to actively maintain (and improve?) Local. * The documentation is unanimously agreed to be of Boost quality. * The transition of some organizations from C++03 to C++11 may take several more years, and Boost has a history of supporting "ancient" compilers (for better or worse). The point being, a library that eases the transition from C++03 to C++11 has some merit based on current precedent. * There had been previous work on local functions by Alexander Nasanov and Steven Watanabe shared on the developer's list, suggesting a desire for this functionality for some time. * Local is approximately an extension of Boost.ScopeExit; indeed, it basically fulfills the request to Alexander Nasanov from the review result [2] of Boost.ScopeExit to create such an extension. Lastly, my own opinion of "what Boost is" factored in here. I view Boost as *partly* a collection of general purpose libraries that can be used in wide variety of applications (and thus Boost frequently acts as a staging ground for standard adoption). Based on review feedback, I believe Local satisfies this criterion; and based on the mailing list discussion, I believe this view of Boost is not entirely inconsistent with others on the mailing list. Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as it was the above general considerations. Regardless, I think independent of how the votes were counted, the "yes" votes outnumbered the "no" votes. This required some discretion on my part as not everyone who expressed an opinion submitted a formal review, and some participants were only arguing in favor of some specific point supporting either acceptance or rejection of Local. "Yes" reviews (7) -------- Krzysztof Czainski Andrzej Krzemienski Pierre Morcello Nat Lindon John Bytheway Edward Diener Gregory Crosswhite "No" reviews (3) -------- Vicente J. Botet Thomas Heller Hartmut Kaiser Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both submitted reviews but did not express an opinion (as far as I could tell) on whether Local should be included in Boost, though if I had to peg Paul's, it would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local in Boost (the aforementioned did not submit a formal review, though a formal review might be unnecessary if your vote is "no"). On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart participated in the discussion and argued in favor of some point that supported accepting Local in Boost. I want to be clear here that certainly not everyone in the aforementioned list even implied that they supported acceptance of Local (I would guess that only roughly half implied as much), but they indirectly helped its case by addressing arguments against inclusion. Overall, that indicates to me that more individuals support acceptance of Local into Boost than rejection. [Apologies for any name misspellings and absent accents.] Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating Boost.ScopeExit; 3 reviews felt there was nothing wrong with both Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the possibility of improving Boost.ScopeExit with the features provided by Local's exits. As such I'm inclined to let Alexander (who opposed any kind of merging of Local and Boost.ScopeExit) work with Lorenzo on improving Boost.ScopeExit as he sees fit, and hopefully both libraries can address this apparent duplication of functionality within their respective documentation to avoid user confusion. Regarding local::function::overload: Based on the review comments, it makes the most sense to add this to Boost.Functional. Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the other hand, there doesn't appear to be a compelling use case for BOOST_IDENTITY_VALUE. The following are some suggested *possible* improvements that reviewers brought up. This list is by no means exhaustive. Further, I personally don't think all of these suggestions are necessarily "good", but I think it's fair for Lorenzo (and the community) to consider them nonetheless. Parenthetic comments are my own opinions. * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases appear fairly narrow so it might be best to simplify the library and remove this capability.) * Use "this_" (as opposed to "_this") as an alias for "this" within function bodies, and possibly also within bind declarations. * Present Boost.PP sequence interface as a workaround for the variadic interface? (I don't have a problem with supporting both interfaces at the top level.) * "Local" and "Locale" look too much alike, suggesting a name change to "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? * Allow use without dependence on Boost.TypeOf. * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? (I don't mind the current macros.) * Explicitly separate bound variables from function parameters. (I think this suggestion has merit but I don't know what the interface could look like.) * Remove support for default parameters to simplify interface and documentation? (It doesn't seem like default function parameters would be very useful.) * Use "capture" instead of "bind" for the bind/capture keyword? (I like and prefer "bind".) Finally, here the links to the submitted formal reviews, for reference. Of particular note are Krzysztof's and John's reviews for their comments on the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has already agreed to address the relevant conditions. Krzysztof Czainski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 Vicente J. Botet http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 Andrzej Krzemienski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 Paul A. Bristow [...cannot find link to review...] Pierre Morcello http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 Nat Lindon http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 Thomas Heller http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 Hartmut Kaiser http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 John Bytheway http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 Alexander Nasanov http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 Edward Diener http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 Gregory Crosswhite http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Finally, really big thanks to everyone for participating in the review and ancillary discussions. I attempted to be as transparent as possible in outlining the rationale for my decision above, but if you have any further questions, do not hesitate to ask. - Jeff, Review Manager for Local [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 [2] http://lists.boost.org/boost-announce/2008/05/0190.php

2 1

Calls to asio::io_service::run on io_service object in stopped state don't generate an error.
by Rory Hart 12 Dec '11

12 Dec '11

Hey I spent a day trying to work out why calls to io_service::run was returning directly without running my async operations. It was my own fault of course, the io_service was in a stopped state as I had previously called io_service::stop and needed to call io_service::reset on it. This is documented in both the stop and reset documentation if I had RTFM instead of just skimming the interface. Is there a reason io_service::run does not set an appropriate error on the passed boost::system::error_code object when this is encountered? Certainly it seems like an error case and would help circuital circumstances such as my own. If there is no obvious reason not to I will put in a feature request and attempt a patch (I haven't touched the boost code base before). Thanks -- Rory Hart http://www.roryhart.net http://www.relishment.com

1 0

incompatible serialization format of boost::property_tree between 1.44 and 1.48
by kpzhang 12 Dec '11

12 Dec '11

Hi, Several days ago I upgrade boost from 1.44 to 1.48 and I found that serialization format is not compatible for node of 'char' type. The serialization format of a "char a=0" node in boost1.44 is: { "a": "\0" } while in boost1.48 is: { "a": "\u0000" } For the format of boost1.44, read_json of boost1.48 will throw exception which complains unexpected escaped slash. Is this intended behavior or a bug or my misuse? Any suggestions is welcomed. Regards, Ivan

2 1

boost asio: Crash on timer.expires_from_now only with specific MSVC settings (whole program optimization)
by Florian Burkart 12 Dec '11

12 Dec '11

Hi, I am currently struggling with a crash that I find very hard to isolate. Please see attached three classes I am using (the one not included is FlamTimeMillis, but that is basically just my own time class). In any case, LiveTimer works absolutely fine in my unit tests. It works absolutely fine in both debug and regular release versions. However, when compiled under msvc with compile options /Ox /Oi /Ot /GL and linked with /LTCG (e.g. whole program optimization), it crashes. But only in my main program, and not in any test I try to create. But in the main program, it consistently crashes. According to the logs, it crashes between 3 and 4, e.g. the log looks like this: IN: : LiveTimer: RegisterTimedCallback 2011-12-12 07:02:00.000000: Locked mutex. IN: : LiveTimer: Expires from now -22405.5 A: 2011-12-12 07:02:00.000000 B: 2011-12-12 13:15:25.489000 C: -2.24055e+007 IN: : 1 IN: : 2 IN: : 3 This happens on the very first call to RegisterTimedCallback. Judging from it, it looks like it crashes on timer.expires_from_now(boost::posix_time::seconds((long)secondsToElapse)). I checked that I am in the correct LiveTimer, and that LiveTimer still exists. I tried loading the dump file into WinDbg, and I get the following output: XCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 77b68da9 (ntdll!RtlpWaitOnCriticalSection+0x000000bd) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000114 Attempt to write to address 00000114 PROCESS_NAME: Test.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000001 EXCEPTION_PARAMETER2: 00000114 WRITE_ADDRESS: 00000114 FOLLOWUP_IP: Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+4c [c:\program files (x86)\boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp @ 117] 0139784c b001 mov al,1 MOD_LIST: <ANALYSIS/> NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 FAULTING_THREAD: 000029b8 BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE LAST_CONTROL_TRANSFER: from 77b68cb8 to 77b68da9 STACK_TEXT: 0032ec44 77b68cb8 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0xbd 0032ec6c 0139784c 00953408 654f7f27 0032ecf0 ntdll!RtlEnterCriticalSection+0x150 0032ecac 0139e79a 0095015c 0032f93c ffffffff Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+0x4c [c:\program files (x86)\boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp @ 117] 0032ecdc 013d9d20 0095015c 0032ed38 00000000 Test!boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::expires_from_now+0x6a [c:\program files (x86)\boost_1_47_0\boost\asio\detail\deadline_timer_service.hpp @ 159] 0032ecfc 013d948f 0032ed28 654f7e57 0095716c Test!boost::asio::basic_deadline_timer<boost::posix_time::ptime,boost::asio::time_traits<boost::posix_time::ptime>,boost::asio::deadline_timer_service<boost::posix_time::ptime,boost::asio::time_traits<boost::posix_time::ptime> > >::expires_from_now+0x30 [c:\program files (x86)\boost_1_47_0\boost\asio\basic_deadline_timer.hpp @ 411] 0032ede0 013b1840 0032f900 00950188 0094f970 Test!Flam::Live::LiveTimer::EnqueueTimedCallback+0x33f [c:\users\florian\documents\liveenvv1\trunk\flamlib\live\livetimer.cpp @ 55] STACK_COMMAND: ~0s; .ecxr ; kb FAULTING_SOURCE_CODE: 113: // If the service has been shut down we silently ignore the cancellation. 114: if (::InterlockedExchangeAdd(&shutdown_, 0) != 0) 115: return 0; 116: > 117: mutex::scoped_lock lock(dispatch_mutex_); 118: op_queue<win_iocp_operation> ops; 119: std::size_t n = queue.cancel_timer(timer, ops, max_cancelled); 120: post_deferred_completions(ops); 121: return n; 122: } SYMBOL_STACK_INDEX: 2 SYMBOL_NAME: Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+4c The source quoted is from \boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp. Despite the fact that I can't isolate the error, everything I look at points to a problem somewhere within boost asio, or me not using asio correctly. Anyone any suggestions as to where to go from here? Would be much appreciated. What looks a bit suspicious to me (but that might be entirely wrong), is the line "// If the service has been shut down we silently ignore the cancellation.," because the error happens after the return statement linked to that comment was apparently not executed, and the service has actually been shut down. P.S. I know that I don't need to manage the queue myself and could just let asio handle it, however, eventually I would like to manage the queue more (e.g. edit some timers, cancel others, so I'd prefer to stick to a single timer and manage the queue myself).

1 0

is_dereferenceable.hpp fails to compile with Apple Clang 3.0
by István Csanády 12 Dec '11

12 Dec '11

Hi All, I am trying to use boost::iostreams. When I include boost/iostreams/filtering_streambuf.hpp (even if I don't declare any filtering_streambuf variables) I get the following compilation error: is_dereferencable.hpp: Parse Issue: Expected unqualified-id The problem is in this code: template <class T> struct impl { static typename boost::remove_cv<T>::type& x; BOOST_STATIC_CONSTANT( bool , value = sizeof(is_dereferenceable_::check BOOST_PREVENT_MACRO_SUBSTITUTION(BOOST_comma(*x,0))) == 1 ); }; Compiler: Apple Clang 3.0, with -std=c++0x flag Any help would be greatly appreciated. Thanks Istvan

4 4