June 2013 - 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

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

Boost.Test on Windows x64
by User 8583 02 Jul '13

02 Jul '13

Hello, I am trying to use Boost.Test 1.53 on a Windows 7 x64 platform and VS2012. I compiled the libraries using .\b2 variant=release link=static threading=multi runtime-link=shared toolset=msvc-11.0 address-model=64 Linking the libraries with my (x64) test program produces the following error: libboost_unit_test_framework-vc110-mt-gd-1_53.lib(unit_test_suite.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' I am surprised as I have used the boost serialization library compiled with the same command line in x64 programs without such error. Any help appreciated, Bob

3 8

Problem in building the BGL Python 0.95 on Windows
by lizy10b 01 Jul '13

01 Jul '13

Hi there, I have got the latest BGL-Python 0.95 from svn (thanks to John), but I can't build it. My environment: Windows 7 x64, Python 2.66 x86, MPICH2 1.32 x86, VS2010 I have tried the following steps: 1. The boost 1.53 source code distribution dir (newly extracted from the zip package) is E:\boost_1_53_0, the BGL Python 0.95 source code dir is E:\bgl-python_svn_095 2. Add a new environment variable, name: BOOST_ROOT, value: E:\boost_1_53_0 3. Append the boost 1.53 source code distribution dir (E:\boost_1_53_0) to the environment variable "PATH" to expose later built bjam.exe file. 4. Add some lines to the file user-config.jam (E:\boost_1_53_0\tools\build\v2\user-config.jam) import toolset : using ; using python : 2.6 : "C:\\Python266" : "C:\\Python266\\include" : "C:\\Python266\\libs" ; using mpi : : <find-static-library>mpi <library-path>"D:\\Program Files (x86)\\MPICH2\\lib" <include>"D:\\Program Files (x86)\\MPICH2\\include" : "\"D:\\Program Files (x86)\\MPICH2\\mpiexec\"" ; 5. Open the vs2010 commandline window (Visual Studio Command Prompt 2010) 6. Navigate to boost 1.53 source code distribution dir to build the bjam.exe: type bootstrap.bat 7. Then navigate to the BGL-Python-0.95 source code dir and type bjam --prefix=E:\boost_1_53_0\release32 stage toolset=msvc-10.0 variant=release link=static address-model=32 architecture=x86 threading=multi runtime-link=shared install The outputs are: Jamfile.v2:198: in load-aux rule python.get-python-interpreter unknown in module Jamfile</E:/bgl-python_svn_ 095> E:/boost_1_53_0/tools/build/v2/build\project.jam:323: in load-jamfile E:/boost_1_53_0/tools/build/v2/build\project.jam:62: in load E:/boost_1_53_0/tools/build/v2/build\project.jam:168: in project.find E:/boost_1_53_0/tools/build/v2\build-system.jam:570: in load E:\boost_1_53_0\tools\build\v2/kernel\modules.jam:283: in import E:\boost_1_53_0\tools\build\v2/kernel/bootstrap.jam:142: in boost-build E:\boost_1_53_0\boost-build.jam:17: in module scope E:\bgl-python_svn_095> and the building process stopped. So what is the problem? Thanks. Zhiyu Li

2 3

[program_options] copy option_description from one options_description to another
by Ghyslain Leclerc 30 Jun '13

30 Jun '13

Hello. First post here. Not a programmer by trade, but a medical physicist, so my apologies if my question seems too much of a newbie question. And hopefully, my programing jargon won’t be too bad. I have searched on Google and played with my code all day yesterday and I have not found the answer to my problem, so I thought I would try the mailing list. We have a number of small command line utilities (approx. 10) that we are developing for our clinic. We want to try and make a base class that would contain all our usual program options in it and would allow customization for our various little programs. Thus, I need to store a options_description object with our usual options and a function in the class to add options to the stored object. That way, the interfaces would be more homogeneous and we would not need to recode all the logic of option handling for every application and maintain them all. Simply create a derived class and add a few options_description to it. Then use that class for our application. My first approach was to store a options_description object directly, but I can't seem to assign to it. So if I want to reset the object to a completely new one, for instance in a special case where the usual options don't make any sense, I run into problems. I switched to holding a pointer to it (tr1 shared_ptr). That allows me to easily change the object all together if I need to. In either case (pointer or object), my actual problem comes when I want to add options to a options_description. I can easily use the add function : myOptionsDescriptionObject.add( theOtherOptionsDescriptionObject ); but that adds empty lines in the output format and creates artificial grouping of options, which I would like to avoid if possible. That being said, given the current state of our code, I will implement this version now as this is the "best" solution that works. The way I am trying to get around that is to extract for each option_description contained in the options_description object the name, the description and the value_semantic and then use these three extracted values with the add_options() function like so: muOptionsDescriptionObject.add_options()( other.options()->name(), other.options()->semantic().get(), other.options()->description() ); Works perfectly for name and description, but fails for value_semantic. It compiles, but generates a "The program has unexpectedly finished." message. My hypothesis for what is happening is that I am using the .get() to extract the raw pointer from the shared_ptr returned, but the shared_ptr somehow deletes the memory and my pointer becomes invalid. Here is a short version of what I came up with. The problem is probably in the implementation of the function addGenOpts(). Can anybody help with this? Sorry if this is a ridiculous question or if my post makes no sense. English is not my first language. In advance, thanks. Ghyslain --------------------------- namespace bpo = boost::program_options; class BaseCli { public: BaseCli(); virtual ~BaseCli() {} void parseCmdLineOpts( int argc, const char* argv[] ); void parseCfgFileOpts(); void run(); bool checkPresent( const std::string& optionStrg ); const bpo::options_description& genOpts( ); void addGenOpts( const bpo::options_description& opts ); void setGenOpts( const bpo::options_description& opts ); private: bpo::variables_map optionsMap_; std::tr1::shared_ptr< bpo::options_description > genOpts_; //virtual void runNoInteraction_() = 0; //virtual void runWithInteraction_() = 0; }; void BaseCli::addGenOpts( const bpo::options_description& opts ) { using std::vector; using std::string; // Loop through every option in opts for( auto optIter = opts.options().begin(); optIter != opts.options().end(); ++optIter ) { ... CODE REMOVED TO SAVE SPACE ... ... SIMPLE STRING MANIPULATION STUFF ... // Combine names into program_options option string string combinedName( longName ); if ( !shortName.empty() ) { combinedName += string( "," ) + shortName; } genOpts_->add_options()( combinedName.c_str(), (*optIter)->semantic().get(), (*optIter)->description().c_str() ); } } ---------------------------

2 1

Asio and Spirit
by LeMay.Steve 30 Jun '13

30 Jun '13

Can anyone point me to a modern example or description of using Asio with Spirit to parse and asynchronous stream. I keep finding articles that say this can't be done, or at least not easily (but the comments date back to 2007). SGL

3 3

Herb Sutter on C++ Standardization and Visual Studio
by LeMay.Steve 30 Jun '13

30 Jun '13

Herb Sutter on C++ Standardization at Microsoft. http://channel9.msdn.com/Events/Build/2013/2-306 SGL

3 2

future<>.then and promises
by Tobias Furuholm 30 Jun '13

30 Jun '13

I am trying out future<>.then and I am seeing some results that confuses me. I have tried to illustrate this with a few examples. The first example is using a promise together with future<>.then. It generates no output: boost::promise<int> promise; boost::future<int> fut = promise.get_future(); promise.set_value(123); fut.then([](boost::future<int>& f) { std::cout << "The value is: " << f.get() << std::endl; return f.get(); }); boost::chrono::milliseconds duration(1000); boost::this_thread::sleep_for(duration); Why is fut.then not triggered? (assigning fut.then to another future makes no difference) By adding a launch policy I get the output "The value is: 123" which is the output I would expect from all my examples: boost::promise<int> promise; boost::future<int> fut = promise.get_future(); promise.set_value(123); fut.then(boost::launch::async, [](boost::future<int>& f) { std::cout << "The value is: " << f.get() << std::endl; return f.get(); }); boost::chrono::milliseconds duration(1000); boost::this_thread::sleep_for(duration); To make this more real, let's move promise.set_value to after .then boost::promise<int> promise; boost::future<int> fut = promise.get_future(); fut.then(boost::launch::async, [](boost::future<int>& f) { std::cout << "The value is: " << f.get() << std::endl; return f.get(); }); promise.set_value(123); boost::chrono::milliseconds duration(1000); boost::this_thread::sleep_for(duration); This program outputs nothing and never terminates. But when I assign the result of fut.then to another future I get the expected output once again: boost::promise<int> promise; boost::future<int> fut = promise.get_future(); boost::future<int> fut2 = fut.then(boost::launch::async, [](boost::future<int>& f) { std::cout << "The value is: " << f.get() << std::endl; return f.get(); }); promise.set_value(123); boost::chrono::milliseconds duration(1000); boost::this_thread::sleep_for(duration); Finally, as I bonus I add an example where I use async to generate a future instead. boost::future<int> fut = boost::async([]() { return 123; }); fut.then([](boost::future<int>& f) { std::cout << "The value is: " << f.get() << std::endl; return f.get(); }); boost::chrono::milliseconds duration(1000); boost::this_thread::sleep_for(duration); This generates the output "The value is: " (without 123). Once again, by assigning the result of fut.then to another future I get the expected output. I use boost 1.54 beta 1 with clang 3.2 on Linux and. /Tobias

3 7

Re: [Boost-users] Accessing memory in shared segments
by Andy Falanga (afalanga) 28 Jun '13

28 Jun '13

>From: Andy Falanga (afalanga) >Sent: Thursday, June 27, 2013 7:42 AM >To: 'boost-users(a)lists.boost.org' >Subject: Accessing memory in shared segments > >Hi, > >I have some code which shares data with shared memory. To that end, I'm using >boost::interprocess:managed_shared_memory. Without respect to scope and functions, what I have is >roughly: > >boost::interprocess::managed_shared_memory sharedMem(boost::interprocess::create_only, > "SharedMemory", 4096); > >//later on >u_int8_t* dataSegment = sharedMemory.construct<u_int8_t>("data")[5](0); >char* string1 = sharedMemory.construct<char>("String 1")[50]('\0'); >// other stuff > >// placing stuff in the data segment >for(int i(0); i < 5; i++) dataSegment[i] = anEarlierArray[i]; > > >// then, in other process read the data Segment >char ary[5]; >for(int i(0); i< 5; i++) ary[i] = dataSegment.first[i]; > > >For whatever reason I couldn't simply access through dataSegment[n] notation. The weirdest thing is, >the data is being read back to me in the reverse order that it should be. For example, if >[0x2,0x4,0x7,0x1] is written I read it back as [0x1,0x7,0x4,x02] even though I'm writing and reading >in the same order. Why is this? What is it I'm missing about using shared memory? Problem solved: it was between the keyboard and the chair. Further debugging showed that the data wasn't being written in reverse (it made no sense that it would have been) but rather was a result of some HID libraries I'm using under the hood. Posting this in case someone hits on this message while looking through the archives. Andy

1 0

[beta] 1.54 for ARM
by Michael Powell 28 Jun '13

28 Jun '13

Hello, I haven't actually built 1.54 for ARM yet, although I have successfully built and am using 1.53 for ARM today. Is it that much different from 1.53? And/or has someone already built it for ARM to give a little beta feedback? If I can manufacture some time this weekend I may give that a go regardless. Thank you... Regards, Michael Powell

1 0