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

[multi_index] emplace support
by Brian Wood 06 Jul '13

06 Jul '13

I'm wondering about emplace support in multi_index. Any news on that is of interest. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 2

Re: [Boost-users] Do correct instructions for MinGW install exist?
by lizy10b 06 Jul '13

06 Jul '13

Hi Kirk Joppy, I have got most of the 1.53 libraries built with MinGW, though some of them do not work correctly till now. I would like to share with you the following steps I did. 1. Add the bin folder of MinGW to your windows environment variable "PATH". 2. Open a the new commandline window, and type "bootstrap.bat mingw" in the boost souce root dir to build the b2.exe and bjam.exe. 3. Type "b2 toolset=gcc --prefix=G:\boost_1_53_0\my-build' to build the libraries. Hope it works. cheers. Zhiyu Li 2013-07-02 lizy10b 发件人： Kirk Joppy 发送时间： 2013-07-02 12:12:50 收件人： boost 抄送：主题： [Boost-users] Do correct instructions for MinGW install exist? Dear Boost users, I have recently been trying to install boost 1.53 for use with MinGW. I followed the instructions here http://www.boost.org/doc/libs/1_53_0/more/getting_started/windows.html#prep… to the letter with resulting failure. I then noticed that when running b2 install --prefix=G:\boost_1_53_0\my-build from G:\boost_1_53_0\tools\build\v2 as per the instructions, the first few lines of output read warning: No toolsets are configured warning: Configuring default toolset "msvc" warning: If the defrault is wrong, your build may not work correctly warning: Use the "toolset=xxxxx" option to override our guess warning: For more configuration options, please consult <webpage> I have consulted the recommended web page and I think I have gotten a working install. However, given that the instructions as written are incorrect I would like to ask 1. Is there a correct, definitive source of instructions for installing boost (with MinGW)? 2. Should the documentation be corrected? I think this error is important given that the section I was working from is specifically indicated to pertain to non-MSVC builds. 3. I have found several conflicting sources of information regarding how to build boost for use with static linking. StackOverflow, for example, has several posts about this, none of which agree with each other. Is there are definitive, correct source of this information? If not I suppose I will post to this mailing list asking about it. Thank you for your consideration. Regards, kjoppy _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

8 19

[MSM] Problem with passing event as a reference to base event class
by samriti katoch 05 Jul '13

05 Jul '13

Hi, I have noticed a strange problem with event processing with msm. My events derive publicly from a base events struct like this: struct BaseEvent { virtual ~BaseEvent() {} }; struct ConcreteEvent : public BaseEvent {}; I my FSM i have a transition defined for ConcreteEvent, When I do this : void foo(const BuddyEvent& event) { fsm->process_event(event); // event is of type ConcreteEvent } The fsm fires a no_transition , and I see a message saying no transition for ConcreteEvent in state X (state X has a valid transition for ConcreteEvent) However this succeeds: void foo(const BuddyEvent& event) { fsm->process_event(ConcreteEvent(0); } I am using boost-1.49 and the boost msm library that comes bundled with this. So my question is, why is msm not able to generate a valid transition for a concrete event passed as a reference to its base tyoe. Thanks!

2 1

Any special differences between unix and windows source code packages?
by lizy10b 05 Jul '13

05 Jul '13

Hi there, I would like to know are there any differences (other than compression types) between the unix platform source code package (.tar.bz2, tar.gz) and windows platform ones (.7z, .zip) ? PlatformFile unixboost_1_54_0.tar.bz2 boost_1_54_0.tar.gz windowsboost_1_54_0.7z boost_1_54_0.zip Thanks. Zhiyu Li 2013-07-02 lizy10b

5 5

mapped_file::close()
by Millman, Mark 04 Jul '13

04 Jul '13

In Windows using VisualStudio 10 I've created a mapped_file as char * OpenRW(std::string filePath ) { <<fragment >> mfp = new boost::iostreams::mapped_file_params(filePath); mfp->mode = boost::iostreams::mapped_file::readwrite; mfp->new_file_size = size; mfp->offset = 0; mf = new boost::iostreams::mapped_file(*mfp); return mf->data(); } I later close the file void Close() { <<fragment>> mf->close(); delete mfp; delete mf; } And then want to reopen it { char* fileName = filePath.c_str(); int test = _open(fileName,_O_BINARY|_O_RDWR); } but test is returned -1 -- note that I am able to open the file _O_RDONLY. If I close the application and restart it, then I can read the file _O_RDWR (i.e. test is returned with a valid handle) Is this a bug or am I doing something wrong? Thanks Mark

1 0

undefined reference to Thread ( Newbie )
by Sahil Sachdeva 04 Jul '13

04 Jul '13

Hello all, I am trying to compile and use the Boost 1.54 libraries and have run into a dead end. I compiled and installed the libraries like mentioned in the documentation: ./bootstrap.sh./b2 install I even tried a complete reinstall using: ./bootstrap.sh./b2 threading=multi install I have linked using -lboost_thread and -L<path to boost>/bin.v2/libs. boost_system is also linked in the same manner. i am still getting the following linker errors: undefined reference to boost::thread::start_thread_noexcept() undefined reference to boost::thread::join_noexcept() I am using gcc 4.6.3 on Ubuntu 12.04 in eclipse. Does anyone know how i can fix this? Best, Sahil

2 1

[Boost.Math special functions] Critical error in zeta.hpp, Boost 1.54.0
by Rainer Deyke 04 Jul '13

04 Jul '13

I'm getting compile errors when including "boost/math/special_functions/zeta.hpp" (which in turn is included indirectly by "boost/random.hpp"). This is in the recently released "boost_1_54_0.tar.bz2" under Linux Mint 16 for amd64, gcc 4.7.3. Minimal test case: #include "boost/math/special_functions/zeta.hpp" int main() {} Exact error message: In file included from source/eldwood/test/zeta.cpp:1:0: intermediate/usr_x86_64-pc-linux-gnu/include/boost/math/special_functions/zeta.hpp: In function ‘T boost::math::detail::zeta_imp(T, T, const Policy&, const Tag&)’: intermediate/usr_x86_64-pc-linux-gnu/include/boost/math/special_functions/zeta.hpp:877:24: error: ‘log_root_two_pi’ is not a member of ‘boost::math::constants’ intermediate/usr_x86_64-pc-linux-gnu/include/boost/math/special_functions/zeta.hpp:877:52: error: expected primary-expression before ‘,’ token intermediate/usr_x86_64-pc-linux-gnu/include/boost/math/special_functions/zeta.hpp:877:60: error: expected primary-expression before ‘>’ token intermediate/usr_x86_64-pc-linux-gnu/include/boost/math/special_functions/zeta.hpp:877:62: error: expected primary-expression before ‘)’ token The same error also manifests under clang. -- Rainer Deyke (rainerd(a)eldwood.com)

3 2

Boost 1.54.0: bootstrap build fails for MinGW/MSYS
by Josue Andrade Gomes 04 Jul '13

04 Jul '13

Hi, Bjam build is failing for me on MinGW/MSYS. ================================================================================ Boost 1.54.0: $ cd boost_1_54_0/tools/build/v2/engine $ ./build.sh mingw ### ### Using 'mingw' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -DNT -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathsys.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execnt.c filent.c ./bootstrap/jam0 -f build.jam --toolset=mingw --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=mingw --toolset-root= don't know how to make modules/set.c don't know how to make modules/path.c don't know how to make modules/regex.c don't know how to make modules/property-set.c don't know how to make modules/sequence.c don't know how to make modules/order.c ...found 126 targets... ...updating 1 target... ...can't find 6 targets... ...can't make 2 targets... failed to write command file! ================================================================================ Boost 1.53.0: $ cd boost_1_53_0/tools/build/v2/engine $ ./build.sh mingw ### ### Using 'mingw' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -DNT -o bootstrap/jam0 command.c compile.c constants.c debug.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execnt.c filent.c ./bootstrap/jam0 -f build.jam --toolset=mingw --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=mingw --toolset-root= ...found 50 targets... ...updating 3 targets... [MKDIR] bin.ntx86 [COMPILE] bin.ntx86\b2.exe [COPY] bin.ntx86\bjam.exe ...updated 3 targets... Any idea? Thanks & regards josue -- Josue Andrade Gomes josuegomes.com

2 2

async processing issues
by SRD 04 Jul '13

04 Jul '13

Having a tough time learning ASIO. I'm trying to have one thread constantly listen for new file monitoring events (mthread) while another thread processes one task at a time (wthread). Somehow I'm still losing events that don't get placed on the task_queue and it would seem that once an event is lost, the file_handler callback for the dir_monitor stops working thereafter for good. So I'm having a few issues with my solution. If I comment out the sleep() method below, then for some reason the first two lines that have to do with the dir_monitor immediately after the while loop quickly eat through all available memory and the program will soon crash within a minute or two. Leaving the sleep in keeps things stable, or maybe it just eats away so slowly I don't notice it. Leaving sleep() in also has the problem of *I think* causing missed file events. The f_handler() function posts tasks that I create within the dir_monitor callback back to the main thread via the io_service.post(), but if its asleep, will it be able to place objects on the main processes task_queue? I think thats one point where I'm going wrong. If anyone sees where I'm going wrong, any help much appreciated. --- static queue<TaskObj *> task_queue; boost::asio::io_service io_service; void queue_task(TaskObj *task) { // pass task back to main thread. task_queue.push(task); } void f_handler(const boost::system::error_code &ec, const boost::asio::dir_monitor_event &ev) { TaskObj task = new TaskObj(...); // create task and place on queue by posting to main process io_service.post(boost::bind(queue_task, task)); } int main(...) { boost::asio::io_service work_service; boost::asio::dir_monitor dm(io_service); dm.async_monitor(f_handler); // dir_monitor thread boost::thread mthread = boost::thread(boost::bind(&boost::asio::io_service::run, boost::ref(io_service))); // setup work to prevent premature exit shared_ptr<boost::asio::io_service::work> work(new boost::asio::io_service::work(work_service)); // worker thread boost::thread wthread(boost::bind(&boost::asio::io_service::run, boost::ref(work_service))); wthread.detach(); while (true) { io_service.reset(); dm.async_monitor(f_handler); // losing all available memory from above two lines without the sleep() below // get first task off of queue and process in worker thread task = task_queue.front(); // functor executed in seperate thread work_service.post(boost::bind(&TaskObj::do_it, task)); sleep(3); }

2 4

Confused with Depth-First-Search method, forward or cross edge found on a undirected graph ?
by lizy10b 03 Jul '13

03 Jul '13

Hi there I have a problem with the DFS method (Boost 1.53). I found when invoking the DFS method on a undirected graph, the "forward_or_cross_edge" was called more than one times. But as the document says "In an undirected graph this method is never called". http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/DFSVisitor.html I performed the test based on the file_dependencies.cpp example (examples/file_dependencies.cpp; http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/file_dependency_example…) 1) Change the graph type from "bidirectionalS" to "undirected". 2)Implement all the 8 DFS vistor "event methods" (Initialize Vertex, Start Vertex, Discover Vertex, Examine Edge, Tree Edge, Back Edge, Forward or Cross Edge, Finish Vertex) in the cycle_detector struct to print the vertex names, edge sources and targets. 3)comment out some code at the begining of the example cpp files as the topological_sort method raise exception upon the undirected graph. The results: the forward_or_cross_edge method was called five times. initialize_vertex: dax.h initialize_vertex: yow.h initialize_vertex: boz.h initialize_vertex: zow.h initialize_vertex: foo.cpp initialize_vertex: foo.o initialize_vertex: bar.cpp initialize_vertex: bar.o initialize_vertex: libfoobar.a initialize_vertex: zig.cpp initialize_vertex: zig.o initialize_vertex: zag.cpp initialize_vertex: zag.o initialize_vertex: libzigzag.a initialize_vertex: killerapp start_vertex: dax.h discover_vertex: dax.h examine_edge: dax.h --> foo.cpp tree_edge: dax.h --> foo.cpp discover_vertex: foo.cpp examine_edge: foo.cpp --> dax.h back_edge: foo.cpp --> dax.h examine_edge: foo.cpp --> zow.h tree_edge: foo.cpp --> zow.h discover_vertex: zow.h examine_edge: zow.h --> foo.cpp back_edge: zow.h --> foo.cpp finish_vertex: zow.h examine_edge: foo.cpp --> foo.o tree_edge: foo.cpp --> foo.o discover_vertex: foo.o examine_edge: foo.o --> foo.cpp back_edge: foo.o --> foo.cpp examine_edge: foo.o --> libfoobar.a tree_edge: foo.o --> libfoobar.a discover_vertex: libfoobar.a examine_edge: libfoobar.a --> foo.o back_edge: libfoobar.a --> foo.o examine_edge: libfoobar.a --> bar.o tree_edge: libfoobar.a --> bar.o discover_vertex: bar.o examine_edge: bar.o --> bar.cpp tree_edge: bar.o --> bar.cpp discover_vertex: bar.cpp examine_edge: bar.cpp --> dax.h back_edge: bar.cpp --> dax.h examine_edge: bar.cpp --> yow.h tree_edge: bar.cpp --> yow.h discover_vertex: yow.h examine_edge: yow.h --> dax.h back_edge: yow.h --> dax.h examine_edge: yow.h --> bar.cpp back_edge: yow.h --> bar.cpp examine_edge: yow.h --> zag.cpp tree_edge: yow.h --> zag.cpp discover_vertex: zag.cpp examine_edge: zag.cpp --> yow.h back_edge: zag.cpp --> yow.h examine_edge: zag.cpp --> boz.h tree_edge: zag.cpp --> boz.h discover_vertex: boz.h examine_edge: boz.h --> bar.cpp back_edge: boz.h --> bar.cpp examine_edge: boz.h --> zig.cpp tree_edge: boz.h --> zig.cpp discover_vertex: zig.cpp examine_edge: zig.cpp --> boz.h back_edge: zig.cpp --> boz.h examine_edge: zig.cpp --> zig.o tree_edge: zig.cpp --> zig.o discover_vertex: zig.o examine_edge: zig.o --> zig.cpp back_edge: zig.o --> zig.cpp examine_edge: zig.o --> libzigzag.a tree_edge: zig.o --> libzigzag.a discover_vertex: libzigzag.a examine_edge: libzigzag.a --> libfoobar.a back_edge: libzigzag.a --> libfoobar.a examine_edge: libzigzag.a --> zig.o back_edge: libzigzag.a --> zig.o examine_edge: libzigzag.a --> zag.o tree_edge: libzigzag.a --> zag.o discover_vertex: zag.o examine_edge: zag.o --> zag.cpp back_edge: zag.o --> zag.cpp examine_edge: zag.o --> libzigzag.a back_edge: zag.o --> libzigzag.a finish_vertex: zag.o examine_edge: libzigzag.a --> killerapp tree_edge: libzigzag.a --> killerapp discover_vertex: killerapp examine_edge: killerapp --> libzigzag.a back_edge: killerapp --> libzigzag.a finish_vertex: killerapp finish_vertex: libzigzag.a finish_vertex: zig.o finish_vertex: zig.cpp examine_edge: boz.h --> zag.cpp back_edge: boz.h --> zag.cpp finish_vertex: boz.h examine_edge: zag.cpp --> zag.o forward_or_cross_edge: zag.cpp --> zag.o !!!!!! finish_vertex: zag.cpp finish_vertex: yow.h examine_edge: bar.cpp --> boz.h forward_or_cross_edge: bar.cpp --> boz.h !!!!!! examine_edge: bar.cpp --> bar.o back_edge: bar.cpp --> bar.o finish_vertex: bar.cpp examine_edge: bar.o --> libfoobar.a back_edge: bar.o --> libfoobar.a finish_vertex: bar.o examine_edge: libfoobar.a --> libzigzag.a forward_or_cross_edge: libfoobar.a --> libzigzag.a !!!!!! finish_vertex: libfoobar.a finish_vertex: foo.o finish_vertex: foo.cpp examine_edge: dax.h --> bar.cpp forward_or_cross_edge: dax.h --> bar.cpp !!!!!! examine_edge: dax.h --> yow.h forward_or_cross_edge: dax.h --> yow.h !!!!!! finish_vertex: dax.h What is the problem? Thanks. Zhiyu 2013-06-24 lizy10b

3 23