- Boost - lists.boost.org

[circular-buffer] Missing images.
by Daniel James 06 Oct '13

06 Oct '13

Hi, I made a change to try to fix some broken links in the circular buffer documentation: https://svn.boost.org/trac/boost/changeset/86174/ You can see the broken links in the inspect report: http://boost.cowic.de/rc/docs-inspect-trunk.html#doc Although hopefully in a couple of hours they'll be gone. But there are still a couple of links to images which I can't find: 'circular_buffer.png' and 'space_optimized.png', did someone forget to check them in? It's probably best not to check them in at 'libs/circular_buffer/doc/html/images', but instead at something like 'libs/circular_buffer/doc/images', that way the images are kept separate from generated documentation. I'll help get the image links right, as it's more tricky than it should be. thanks, Daniel

1 0

[regression] Beagle Bone Black
by Jim Bell 05 Oct '13

05 Oct '13

For anyone interested, Boost regression tests fare pretty well on the $45 Beagle Bone Black (beaglebone.org) Stop by the release regression matrix and check it out (http://www.boost.org/development/tests/release/developer/summary.html) And while you're over there, investigate & fix a regression test failure on your platform: submit a patch and make the matrix a greener place! (See http://www.boost.org/development/bugs.html.) Cheers! -Jim

1 0

[log] logger linking problem
by Tadeusz Jordan 05 Oct '13

05 Oct '13

Hi everyone, I have been using Boost for some time now and really like it. Unfortunately, recently I have bumped into a linker issue when trying to use boost::log, was wondering if anyone has seen this before, or has any insights … thank you very much. The problem is described in the below post. http://stackoverflow.com/questions/18881602/boost-logger-linking-issue -- Sincerely, Tadeusz Jordan Software Engineer at The Broad Institute of MIT and Harvard MS Candidate in CS at Northeastern University This email message and any attachments are confidential and may be privileged. It is intended only for the individual or individuals to whom it is addressed and may not be saved, copied, printed, disclosed or otherwise used by anyone else. If you are not the intended recipient, kindly notify the sender and delete this email and any attachments immediately.

3 11

Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?
by Sergey Zhuravlev 05 Oct '13

05 Oct '13

Signature type int(int, const std::string) can be used as parameter for some compiletime algorithm. For example, algorithm that generate new signature type with optimal transfer arguments int (int, const std::string&) or generate signature with all argument references int (int&, const std::string&) Can't use type_traits, function_types at that cases, because const be omitted. This will lead to compiletime error, if function with first signature call function with second signature and use arguments from function with first signature for this call. Signature type void(int, const std::string) can use as types tuple for some compiletime algorithm. Can't use type_traits, function_types, at that case, because const be lost. Signature type void(int, const std::string) can use as parentheses dropper for "types list", e.g. for macro parameter. (int, const std::string) => int, const std::string. Can't use type_traits, function_types, at that case, because const be lost. I think default behavior is correct, but need parameter for change this behavior. At least function_types.

6 16

lots of warning with gcc-4.8.1 + boost-1.54.0
by Neal Becker 04 Oct '13

04 Oct '13

Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19)

8 9

[log] MSVC 9 build hangs
by Andrey Semashev 04 Oct '13

04 Oct '13

Hi, Many test results for Boost.Log on teeks99-03b-win2008-64on64 [1] show that the build aborts due to timeout. From the test setup description (2 GiB of RAM, 2 CPUs, 4 build jobs) it seems that the problem could be in the insufficient system resources. 4 jobs building Boost.Log can easily exceed 2 gigs of RAM, especially considering some of the memory is reserved by OS and other programs. If there isn't any swap, the build may be just aborting, and if there is, it's probably performing dead slow. And 2 cores might also be too limiting. Could the tester take a look what is happening on that setup? If it's not a resource problem, then I would appreciate any information on the problem. [1] http://www.boost.org/development/tests/trunk/developer/log.html

3 27

[ASIO] Safely shut down timer thread in boost::asio::io_service in Windows DLL
by Bo Peng 03 Oct '13

03 Oct '13

Hi folks, As you might already know, Windows DLL has quite some limitation about what you can do during its loading and unloading. For example, you can't 'join' a thread when unloading a DLL. The consequence of doing that, from my opinion, is quite serious: it will hang the process in a dead lock. I have a Windows DLL, which uses boost::asio::deadline_timer. I found that deadline_timer::async_wait creates a timer thread as a private member of io_service. This thread won't be shut down even if all the timers are cancelled. In the destructor of io_service, 'join' will be called on the thread. In some exceptional situation, users might exit their main function before destructs the io_service inside my DLL, so the destructor is called during the unloading of the DLL, which hangs their process. The following code demonstrates this issue. action.h and action.cpp are the code for the dll, main.cpp are the code for the application which uses the dll. action.h: #pragma once #ifndef _WIN32_WINNT #define _WIN32_WINNT 0x0501 #endif extern "C" __declspec(dllexport) void start(); extern "C" __declspec(dllexport) void stop(); action.cpp: #include "action.h" #include <boost/asio.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/thread.hpp> class Action { public: Action() : ios_(), timer_(ios_, boost::posix_time::seconds(1)), worker_() { } void start() { worker_.reset(new boost::thread(boost::bind(&Action::startEntry, this))); } void stop() { if (worker_) { ios_.post(boost::bind(&Action::stopEntry, this)); worker_->join(); worker_.reset(); } } private: void startEntry() { timer_.async_wait(boost::bind(&Action::timerHandler, this, _1)); ios_.run(); } void stopEntry() { timer_.cancel(); } void timerHandler(const boost::system::error_code& e) { if(e == boost::asio::error::operation_aborted) { std::cout << "Finished." << std::endl; } else { std::cout << "Triggered." << std::endl; timer_.expires_from_now(boost::posix_time::seconds(1)); timer_.async_wait(boost::bind(&Action::timerHandler, this, _1)); } } boost::asio::io_service ios_; boost::asio::deadline_timer timer_; boost::shared_ptr<boost::thread> worker_; }; boost::shared_ptr<Action> action; void start() { action.reset(new Action); action->start(); } void stop() { if (action) { action->stop(); action.reset(); } } main.cpp: #include <iostream> #include <windows.h> int main() { typedef void (__cdecl *PROC)(); HINSTANCE hInstLib = LoadLibrary(TEXT("dll.dll")); if (hInstLib == NULL) { std::cout << "Failed to load dll" << std::endl; return 1; } PROC startProc = reinterpret_cast<PROC>(GetProcAddress(hInstLib, "start")); if (startProc == NULL) { std::cout << "Failed to load start function" << std::endl; return 1; } PROC stopProc = reinterpret_cast<PROC>(GetProcAddress(hInstLib, "stop")); if (startProc == NULL) { std::cout << "Failed to load stop function" << std::endl; return 1; } startProc(); std::cout << "Press any key to exit..." << std::endl; getchar(); //stopProc(); FreeLibrary(hInstLib); return 0; } As you can see, stopProc() is commented out to simulate that the user doesn't have the chance to call the clean up function of my DLL. What I am wondering is, is it possible to shut down the thread whenever there isn't any timer outstanding. Or if I had access to the handle of this thread, I could call TerminateThread, which is allowed even during dll unloading. Regards, Bo

2 2

[graph] ranges used by boost.graph not compatible with c++11 range-based-for
by Nathan Ridge 03 Oct '13

03 Oct '13

>> Sadly, I don't think there s a way of turn an std::pair of iterators into >> a range-based-for-compliant range (see [1]). > > correct me if I'm missing something, but when performing ADL the > namespaces of the template parameters > are in the set of associated namespaces. So, one could simply overload > begin/end in the namespace where > the iterator types are defined ... You're right, a per-namespace solution is possible. I don't think it can be done in general, though (i.e. for all std::pairs of iterators in one stroke). I'm not familiar with BGL - are the iterator types in question defined in a namespace under the library's control, or could they be user-provided types (in which the case the user would have to put the begin()/end() in their own namespace)? Regards, Nate

2 1

[graph] ranges used by boost.graph not compatible with c++11 range-based-for
by Gabriel Redner 03 Oct '13

03 Oct '13

I noticed today that code of this form does not compile: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Node, Edge> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...} The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for. It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this? -Gabe [1] http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/IncidenceGraph.html

4 4

Heads up: 1.55.0 deadlines approaching
by Marshall Clow 02 Oct '13

02 Oct '13

See the calendar at: http://www.boost.org/development/index.html September 16: 1.55.0 Closed for new libs and breaking changes September 23: 1.55.0 Closed, except bug fixes and doc changes September 30: 1.55.0 Closed, except by permission October 7: 1.55.0 Beta release -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

6 10