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

boost::asio
by imran sheikh 14 Jul '14

14 Jul '14

hi, I used the following piece of code after following your suggestions. Iam new to boost and even multi-threading When I ran this piece of code on my machine I found that for every run 4 threads are only used out of the pool. As I have 4 cores in my machine. Is it so?? #include<iostream>#include<boost/asio.hpp>#include<boost/thread.hpp>boost::atomic_int thrd_gen(0);voiddowork(inti){thread_local inttid =++thrd_gen;std::cout <<"hello";std::cout <<" thread ID :"<<tid <<"\n";}intmain(){boost::asio::io_service ioservice;boost::thread_group group;boost::optional<boost::asio::io_service::work>work(boost::asio::io_service::work{ioservice});for(size_ti=0;i<boost::thread::hardware_concurrency();i++){group.create_thread(boost::bind(&boost::asio::io_service::run,&ioservice));}std::cout <<"in main thread size="<<group.size()<<std::endl;for(inti =0;i <=5;++i){for(inti=0;i<5;i++){ioservice.post(boost::bind(dowork,10));}boost::this_thread::sleep_for(boost::chrono::milliseconds(600));std::cout <<"waking up\n";}work.reset();// allow threads to exitgroup.join_all();// await proper thread shutdown } Also, my application is time-sensitive and I need to do some time measures. If I use sleep my results will be incorrect. So, please suggest an alternative way to get notified when all the threads finish without using sleep. Thanks for your time on this

2 2

Fw: boost::asio
by imran sheikh 14 Jul '14

14 Jul '14

On Saturday, 12 July 2014 11:10 AM, "boost-users-owner(a)lists.boost.org" <boost-users-owner(a)lists.boost.org> wrote: ----- Forwarded Message ----- To post messages to the Boost Users mailing list, you will need to subscribe this e-mail address via the Boost mailing list web page at: http://lists.boost.org/mailman/listinfo.cgi/boost-users You will need to take this step even if you intend to post only through GMane or some other news gateway. In this case, you may wish to edit your subscription options to turn off mail delivery. On Friday, 11 July 2014 11:00 PM, imran sheikh <s.imran0508(a)yahoo.com> wrote: hi all, i am using boost::asio:: ioservice for the multi-threading in c++. i got stuck ...please see and help. code is like this, discription: > i am creating threadpool using ioservice. > creating threads 100. > in while (which is 5 times)loop at a time i want to post(posting at do work) 5 threads. > then i do work reset and like this.. >i print thread-id also problems:: >threadpool size is 100. > but at a posting time it didn't taking the 5 threads..when i printed a id its same for 5 thread > so its not executing in parallel..why? > i want to post five threads at a time(different threads means thread id is different must)..from threapool..and like this for whole while loop rotation..?????????????????????????? void dowork(int i) { std::cout<<"hello"<<std::endl; cout<<" thread ID :"<<boost::this_thread::get_id(); } int main() { int ch; int i; boost::asio::io_service ioservice; boost::thread_group threadpool; auto_ptr<boost::asio::io_service::work> work(new boost::asio::io_service::work(ioservice)); for(i=0;i<100;i++) { threadpool.create_thread( boost::bind(&boost::asio::io_service::run, &ioservice)); } ch=0; while(ch <= 5) { ch++; cout<<"in main"<<boost::this_thread::get_id()<<endl; for(i=0;i<5;i++) { ioservice.post(boost::bind(dowork,10)); } std::cout<<"size="<<threadpool.size()<<std::endl; work.reset(); ioservice.reset(); ioservice.run(); } } please give me suggestion.i got stuck with it.

2 5

Re: [Boost-users] [coroutine] Is there a max number of coroutines that can be created?
by José 12 Jul '14

12 Jul '14

2 1

1.56.0 beta 1 release candidates available for testing
by Marshall Clow 12 Jul '14

12 Jul '14

Release candidate files for 1.56.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost-1_56_0b1_rc1.7z) = a23e0b5f503c82970c9754dbc8324256 MD5 (boost-1_56_0b1_rc1.tar.bz2) = c6c8486dde4375896f302bdfe1fd3d2f MD5 (boost-1_56_0b1_rc1.tar.gz) = 1042e97a9f354b7187326fa1f9eb313e MD5 (boost-1_56_0b1_rc1.zip) = 984a70feac785d908d8f75ea9d8d2158 Since this is the first post-git release, we are expecting some teething pains with this release. Please test extensively. Thank you. --The release managers

2 1

[uuid] stale 1.55 source/build
by Michael Powell 12 Jul '14

12 Jul '14

Hello, I'm not 100% positive, I downloaded stale source and/or binary build of boost 1.55, supposedly, but I am finding that tickets which were reported to have been included in that version are not in the build. I'll retrace my steps to find where that build came from, but I seriously question whether this build included the latest 1.55 code. i.e. uuid fixes, which I am finding are still happening in the download: Error 1 error C4996: 'std::_Swap_ranges': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' c:\program files (x86)\microsoft visual studio 12.0\vc\include\algorithm 925 1 xml and with reported fixes: https://svn.boost.org/trac/boost/attachment/ticket/9503/uuid.hpp This is not in the code that I have. i.e. typedef uint8_t value_type; typedef uint8_t& reference; typedef uint8_t const& const_reference; typedef uint8_t* iterator; typedef uint8_t const* const_iterator; typedef std::size_t size_type; typedef std::ptrdiff_t difference_type; versus: typedef uint8_t value_type; typedef std::array<value_type, static_size> data_type; typedef data_type::size_type size_type; typedef data_type::difference_type difference_type; typedef data_type::iterator iterator; typedef data_type::const_iterator const_iterator; typedef data_type::reference reference; typedef data_type::const_reference const_reference; in the reported patch. In two attempts to 1) build from source myself, 2) download read-built binaries, both have stale versions of source, without the reported patches. This is not the first time I've encountered such an issue, with the first being failure to build from source several weeks ago now at least. What with the Git submodule advances, could it be Git submodule(s) were not updated or something along those lines? Any thoughts? Recommendations where to find a reliable 1.55 build? Thank you... Best regards, Michael Powell

2 3

Re: [Boost-users] [coroutine] Is there a max number of coroutines that can be created?
by José 11 Jul '14

11 Jul '14

2 1

[coroutine] Is there a max number of coroutines that can be created?
by José 11 Jul '14

11 Jul '14

3 2

[logging] Setting log level works if set_filter called from main, but not if called from a function in a static library
by Hickman, Steve (AdvTech) 10 Jul '14

10 Jul '14

To make setting the log level at runtime easy, I created the following routine: -----Utiliites.hpp namespace Utilities { void setLogLevel(const std::string &level); }; ------Utilities.cpp ----- #include "Utilities.hpp" #include <boost/log/core.hpp> #include <boost/log/expressions.hpp> namespace logging = boost::log; #define SET_IF_LOG_LEVEL(lvlVar, levelVal) \ if (lvlVar.compare( #levelVal ) == 0) \ { \ logging::core::get()->set_filter \ ( \ logging::trivial::severity >= logging::trivial:: ## levelVal \ ); \ } void Utilities::setLogLevel(const std::string &level) { // default is debug std::string lvl = (level.length() > 0)?level:"debug"; Utilities::lowerCase(lvl); // just to make sure we're consistent if (lvl.compare("disabled") == 0) boost::log::core::get()->set_logging_enabled(false); SET_IF_LOG_LEVEL(lvl,trace); SET_IF_LOG_LEVEL(lvl,debug); SET_IF_LOG_LEVEL(lvl,info); SET_IF_LOG_LEVEL(lvl,warning); SET_IF_LOG_LEVEL(lvl,error); SET_IF_LOG_LEVEL(lvl,fatal); } -------------------main.cpp ------------------------------ #include <boost/log/core.hpp> #include <boost/log/expressions.hpp> namespace logging = boost::log; int main(int argc, char** argv) { if (argc > 1) { Utilities::setLogLevel(argv[1]); } //logging::core::get()->set_filter // ( // logging::trivial::severity >= logging::trivial::debug // ); BOOST_LOG_TRIVIAL(trace) << "Utilities unit test main starting " << std::endl; } ------------------------ Utilities.cpp is compiled as part of a static library that is linked to my main routine. If I call this function from my main routine, it appears to have no effect. I still get every logging message no matter what level I attempt to set. However, if I call logging::core::get()->set_filter() from my main routine (passing an appropriate level) it works as expected. I'm not certain what's happening here. Is it possible that logging::core::get() isn't actually dealing with a singleton? That the pointer returned by get() when called from my library is not the same as the pointer returned by the same call in my main routine? And, regardless of what is happening, how do I fix this? I'm using Visual Studio 2012 building Debug Win32 console application. Running on Windows 7 64bit. Steve Hickman System Architect, Flight Deck of the Future 480-236-8367

1 0

[log] , [smart_ptr] global logger declaration issues tons of warnings
by Valerii Valeev 10 Jul '14

10 Jul '14

Hello, global logger declaration as follows BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT(mylog_master, boost::log::sources::severity_logger<boost::log::trivial::severity_level>); issues a lots of warnings (see below) pointing to some smart_ptr code. If anyone could advice - does it look like my problem or something else – it would be greatly appreciated. Cheers, Valerii. Warning text: In file included from /usr/local/boost-1.55.0/include/boost/smart_ptr/make_shared_object.hpp:17, from /usr/local/boost-1.55.0/include/boost/log/sources/global_logger_storage.hpp:21, from /usr/local/boost-1.55.0/include/boost/log/common.hpp:24, from mylog.cpp:10: /usr/local/boost-1.55.0/include/boost/smart_ptr/detail/sp_forward.hpp: In function ‘T&& boost::detail::sp_forward(T&) [with T = const char*]’: /usr/local/boost-1.55.0/include/boost/smart_ptr/make_shared_object.hpp:218: instantiated from ‘typename boost::detail::sp_if_not_array<T>::type boost::make_shared(Arg1&&, Args&& ...) [with T = boost::log::v2s_mt_posix::sources::aux::logger_holder<boost::log::v2s_mt_posix::sources::severity_logger<boost::log::v2s_mt_posix::trivial::severity_level> >, Arg1 = const char*, Args = unsigned int, mylog_master::logger_type]’ /usr/local/boost-1.55.0/include/boost/log/sources/global_logger_storage.hpp:141: instantiated from ‘static boost::shared_ptr<boost::log::v2s_mt_posix::sources::aux::logger_holder_base> boost::log::v2s_mt_posix::sources::aux::logger_singleton<TagT>::construct_logger() [with TagT = mylog_master]’ /usr/local/boost-1.55.0/include/boost/log/sources/global_logger_storage.hpp:121: instantiated from ‘static void boost::log::v2s_mt_posix::sources::aux::logger_singleton<TagT>::init_instance() [with TagT = mylog_master]’ /usr/local/boost-1.55.0/include/boost/log/detail/singleton.hpp:45: instantiated from ‘static StorageT& boost::log::v2s_mt_posix::aux::lazy_singleton<DerivedT, StorageT>::get() [with DerivedT = boost::log::v2s_mt_posix::sources::aux::logger_singleton<mylog_master>, StorageT = boost::shared_ptr<boost::log::v2s_mt_posix::sources::aux::logger_holder<boost::log::v2s_mt_posix::sources::severity_logger<boost::log::v2s_mt_posix::trivial::severity_level> > >]’ /usr/local/boost-1.55.0/include/boost/log/sources/global_logger_storage.hpp:112: instantiated from ‘static typename TagT::logger_type& boost::log::v2s_mt_posix::sources::aux::logger_singleton<TagT>::get() [with TagT = mylog_master]’ ../../include/myproject/mylog.hpp:20: instantiated from here /usr/local/boost-1.55.0/include/boost/smart_ptr/detail/sp_forward.hpp:30: warning: returning reference to temporary mylog.hpp:20 is the line where global logger is declared: BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT(mylog_master, boost::log::sources::severity_logger<boost::log::trivial::severity_level>); And my platform / compiler: $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)

1 0

Limitations of BOOST_COROUTINES_V2 (pass by reference)
by Mueller-Roemer, Johannes Sebastian 09 Jul '14

09 Jul '14

Hi, aside from the fact that the new coroutines are - apparently intentionally - only unidirectional now (currently not much of an issue for me), I noticed that it is apparently no longer possible to yield values by reference as shown in the following example: #include <fstream> #include <string> #include <iostream> #include <boost/coroutine/all.hpp> using type = std::string; auto lines_from_file(char const * fname) -> boost::coroutines::coroutine<type>::pull_type { using namespace boost::coroutines; return coroutine<type>::pull_type{ [fname](coroutine<type>::push_type& yield) { std::string line; std::ifstream stream(fname); while(stream) std::getline(stream, line), yield(line); }, attributes(fpu_not_preserved) }; } int main(int, char**) { auto lines = lines_from_file("test.txt"); unsigned count = 0; for(auto& line : lines) std::cout << std::setw(4) << ++count << ": " << line << "\n"; } If one changes type to std::string const & the example no longer compiles. If I use the old BOOST_COROUTINES_V1 API boost::coroutines::coroutine<std::string const &()> works just fine. Is this limitation also intentional (why?) or is this an unintentional regression? Regards Johannes S. Mueller-Roemer -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer(a)igd.fraunhofer.de | www.igd.fraunhofer.de

4 9