- Boost-users - lists.boost.org

errors in boost build - 1.5.3 on Linux Mint 15 (Olivia) 64-bit
by asif saeed 20 Jun '13

20 Jun '13

Hi, I am trying to build boost 1.53 using GCC and have got the following errors: ...failed updating 348 targets... ...skipped 72 targets... ...updated 4568 targets... The "failed updating 348 targets..." shows that something has definitely gone wrong. Can any kind soul tell me what has happened? I used the following command after bootstrap: ./b2 --prefix=./ --build-type=complete --stagedir=./stage --layout=versioned --toolset=gcc Help me please. -Best regards, -Asif

2 1

[program_options] Custom Validation for a String Value
by Ryan 19 Jun '13

19 Jun '13

Hello, Is there a way of validating a string type program option before it's stored in the map? add_options() ("arg" , value<std::string>()->default_value("Hi"), "Greeting"); boost::regex pattern("^(Hello | Good Morning | Hi)$"); I've used custom validation for types that program options doesn't recognize. I'd like to check the string before it's stored in the map like the custom validation does for unknown types. I'd rather the error be caught early. Is there a way to use the regex against the program option? Ryan

1 0

Mutex synchronised wrapper class for boost::interprocess shared memory vector of strings
by Riskybiz 19 Jun '13

19 Jun '13

I'm trying to write a wrapper class in C++ to give mutex synchronised interprocess access to a shared memory vector of strings. This is my first foray into boost::interprocess and allocators are proving something of a mystery. Is anyone able to see why on compilation I get the error: error C2512: 'boost::interprocess::allocator::allocator' : no appropriate default constructor available C:\Program Files (x86)\Boost\boost_1_53_0\boost\container\string.hpp #ifndef SHARED_MEMORY_WRAPPER_H//if not defined already #define SHARED_MEMORY_WRAPPER_H//then define it #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/containers/vector.hpp> #include <boost/interprocess/containers/string.hpp> #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/sync/named_mutex.hpp> using namespace boost::interprocess; class SharedMemoryWrapper { public: SharedMemoryWrapper(const std::string &name, bool server) : m_name(name), m_server(server) { if (server) { named_mutex::remove("named_mutex"); shared_memory_object::remove(m_name.c_str()); //Create shared memory managed_shared_memory m_segment(create_only, m_name.c_str(), 10000); //Create allocators CharAllocator charallocator(m_segment.get_segment_manager()); StringAllocator stringallocator(m_segment.get_segment_manager()); //This string is in only in this process (the pointer pointing to the //buffer that will hold the text is not in shared memory). //But the buffer that will hold "this is my text" is allocated from //shared memory MyShmString mystring(charallocator); mystring = "this is my text"; //This vector is fully constructed in shared memory. All pointers //buffers are constructed in the same shared memory segment //This vector can be safely accessed from other processes. MyShmStringVector *sharedSegmentVector = m_segment.construct<MyShmStringVector>("sharedSegmentVector")(stringallocato r); sharedSegmentVector->push_back(mystring); } else { //Open the shared segment managed_shared_memory m_segment(open_only, name.c_str()); //Find the vector using the c-string name and open it MyShmStringVector *sharedSegmentVector = m_segment.find<MyShmStringVector>("sharedSegmentVector").first; } m_mutex = new named_mutex(open_or_create, "named_mutex"); } ~SharedMemoryWrapper() { if (m_server) { named_mutex::remove("named_mutex"); //Destroy the vector from the managed_shared_memory m_segment->destroy_ptr(sharedSegmentVector);//This will free all strings that the vector contains m_segment->destroy<MyShmStringVector>("sharedSegmentVector");//Destroy the vector //Is it necessary to destroy the allocators here? //Remove the managed_shared_memory; this may fail if the memory does not exist or is mapped or opened by another process shared_memory_object::remove(m_name.c_str()); } delete m_mutex; delete m_segment; } //Writer void push(const std::string & in) { scoped_lock<named_mutex> lock(*m_mutex); MyShmString inStr = in.c_str(); sharedSegmentVector->push_back(inStr); } //Reader function yet to be coded. Needs to return a vector containing a subset range of elements from the shared-memory-vector. private: //Typedefs typedef boost::interprocess::allocator<char, managed_shared_memory::segment_manager> CharAllocator; typedef boost::interprocess::basic_string<char, std::char_traits<char>, CharAllocator> MyShmString; typedef boost::interprocess::allocator<MyShmString, managed_shared_memory::segment_manager> StringAllocator; typedef boost::interprocess::vector<MyShmString, StringAllocator> MyShmStringVector; bool m_server; std::string m_name; managed_shared_memory *m_segment; MyShmStringVector *sharedSegmentVector; named_mutex *m_mutex; };//class #endif//header guard With thanks, Riskybiz

2 1

[statechart] [spirit] OSI delimited message framing
by Michael Powell 19 Jun '13

19 Jun '13

Hello, I need to design a delimited message framing for TCP/IP sockets, probably using Asio to facilitate transport. Then build an OSI layer 7 application vernier to handle framing. I've dabbled a bit with Spirit and cooked up a couple of "simple" micro grammars throughout the code base. In a sense, I could see a delimited message framing strategy being a grammar of sorts, but this seems somewhat complex for a grammar to handle when you consider the overhead of verifying pass/fail (message or not a message), plus extracting the message within the delimiters. Or, more likely approach the problem with statechart in mind. I've dealt with framed messages in the past more like this. One state is the escape byte, which can be followed by SOM, EOM, or another true-escape-byte (intended message byte). Plus other fields like message type, sub-type, how to handle payload, arguments, and so forth. Anyone else dealt with things like this before? With Spirit? With Statechart? Regards, Michael Powell

5 5

Re: [Boost-users] Boost-users Digest, Vol 3479, Issue 1
by Damien Kick 19 Jun '13

19 Jun '13

Date: Mon, 17 Jun 2013 23:03:16 +0000 (UTC) From: legalize+jeeves(a)mail.xmission.com<mailto:legalize+jeeves@mail.xmission.com> (Richard) To: boost-users(a)lists.boost.org<mailto:boost-users@lists.boost.org> Subject: Re: [Boost-users] [Test]: Problem with simple Boost.Test Message-ID: <kpo4jk$2ih$2(a)ger.gmane.org<mailto:kpo4jk$2ih$2@ger.gmane.org>> [Please do not mail me a copy of your followup] boost-users(a)lists.boost.org<mailto:boost-users@lists.boost.org> spake the secret code <7364AB234369D348AE1CEBC1A86132DBAD32EA(a)SVLITMX02.shoretel.com<http://SVLITMX02.shoretel.com>> thusly: $ ${CXX} -c --std=c++0x -g -I${TARGET}/include cma.cpp -o cma.o $ ${CXX} --std=c++0x -g cma.o ${TARGET}/lib/libboost_test_exec_monitor.a \ ${TARGET}/lib/libboost_unit_test_framework.dylib -o cma Why are you linking against boost_test_exec_monitor? I've never needed to do that. boost_unit_test_framework should be enough. Interesting. Because I'm finding the following: $ ${CXX} -c --std=c++0x -g -I${TARGET}/include cma.cpp -o cma.o $ ${CXX} --std=c++0x -g cma.o ${TARGET}/lib/libboost_unit_test_framework.dylib -o cma Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status $ But that is also what I'm finding with the system GCC and the Fink install of Boost 1.46, and so that behavior isn't unique my attempt to build/use a Boost with GCC 4.8.0 using --std=c++0x. $ g++ -c -g -I/sw/include cma.cpp -o cma.o $ g++ -g -L/sw/lib cma.o -lboost_unit_test_framework-mt Undefined symbols for architecture x86_64: "_main", referenced from: start in crt1.10.6.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status $ g++ --version i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ fink list --tab boost1.46 Information about 7237 packages read in 1 seconds. i boost1.46.1.cmake 1.46.1-2 Boost C++ Libraries i boost1.46.1.cmake-shlibs 1.46.1-2 Boost C++ Libraries $ ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.

1 0

[asio] Serial and TCP I/O
by Michael Powell 19 Jun '13

19 Jun '13

Hello, I have an application that I'd like to leverage some common code if at all possible (and/or necessary), using concepts of client/server, reader/writer, and so on. Probably also TCP/IP and/or Serial, although I gather Asio has a serial class ready to go out of the box? Serial is pretty much a "no brainer", can be a server, but to talk to devices in our use case, always the client, can be either reader or writer or both. The key question here is, do we need a separate io_service for serial as well as for TCP? Regards, Michael Powell

2 1

What is the status of the BGL-Python Bindings project
by lizy10b 19 Jun '13

19 Jun '13

Hi there, I would like to know what is the status of the BGL-Python Bindings project? The Boost 1.53 document says that "The Python bindings for the BGL are now part of a separate project" and links to http://www.osl.iu.edu/~dgregor/bgl-python/ On that page I find that the latest version is 0.9 which was released in 2005. So it means the BGL-Python Binding project is not on going? Is the BGL-Python Bindings 0.9 compatible to Boost 1.53 ? Or any other ways to use Boost graph functionalities in python? Thanks Zhiyu Li 2013-06-19 lizy10b

3 7

[build] Problem building using Intel C++ compiler
by Jason 18 Jun '13

18 Jun '13

I'm trying to build v1.53 using the Intel C++ compiler and am having some problems. I'm issuing the following commands: ./bootstrap.sh --with-toolset=intel-linux ./b2 toolset=intel-linux Upon executing the second command, I get the following error: error: intel-linux initialization: parameter 'version' inconsistent error: no value was specified in earlier initialization error: an explicit value is specified now This appears to be similar to a mailing list thread regarding v1.39, archived here: https://groups.google.com/forum/#!topic/boost-list/gu9wf3cr15Y It appears that there is a workaround listed there (and a corresponding Trac ticket #3165) that involves hand-manipulation of bjam configuration files, but it seems like this is something that should work out of the box if Intel C++ is a supported toolset. Is there any chance that this would be fixed in the future? Jason -- View this message in context: http://boost.2283326.n4.nabble.com/build-Problem-building-using-Intel-C-com… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[BGL] null_vertex()
by Andreas Fabri 18 Jun '13

18 Jun '13

Hello, I am wondering what the function boost::graph_traits<G>::null_vertex() http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/Graph.html is for, and why there is no equivalent function null_edge() best regards, andreas -- Andreas Fabri, PhD Chief Officer, GeometryFactory Editor, The CGAL Project phone: +33.492.954.912 skype: andreas.fabri

2 2

[Test]: Problem with simple Boost.Test
by Damien Kick 17 Jun '13

17 Jun '13

I'm trying to get what I think should be a simple example of Boost.Test (Boost 1.53) to work but I'm getting a segmentation fault, having used other of the Boost libraries from the same build/install of 1.53 without any problems. Am I doing anything obviously wrong? Thanks in advance for any help. $ cat test/cma.cpp #define BOOST_TEST_MODULE cma #include <boost/test/unit_test.hpp> #include <iostream> #include <ostream> BOOST_AUTO_TEST_CASE(sanity) { std::clog << "Test the world!\n"; } $ make check [100%] Building CXX object CMakeFiles/test-cma.dir/test/cma.cpp.o Linking CXX executable test-cma [100%] Built target test-cma [100%] Built target check $ env DYLD_LIBRARY_PATH=${TARGET}/lib ./test-cma Running 1 test case... Test the world! Segmentation fault: 11 $ Here are some more details. I'm trying this on Mac with GCC. $ uname -a Darwin Damien-Kicks-MacBook-Pro.local 12.4.0 Darwin Kernel Version 12.4.0: \ Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 $ ${CXX} --version g++ (GCC) 4.8.0 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I've compiled my build/install of Boost 1.53 with --std=c++0x. Again, I've used other libraries from this same build/install (DateTime, Filesystem, Random, Regex, Serialization, System, Thread), so I don't think that the problem is my use of --std=c++0x in and of itself. $ ${CXX} -c --std=c++0x -g -I${TARGET}/include cma.cpp -o cma.o $ ${CXX} --std=c++0x -g cma.o ${TARGET}/lib/libboost_test_exec_monitor.a \ ${TARGET}/lib/libboost_unit_test_framework.dylib -o cma $ env DYLD_LIBRARY_PATH=${TARGET}/lib ./cma Running 1 test case... Test the world! Segmentation fault: 11 $ If I run this under GDB (gdb) run Starting program: cma Reading symbols for shared libraries ++++.............................. done Running 1 test case... Test the world! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 boost::unit_test::framework::get (id=65536, t=tut_case) at \ impl/framework.ipp:388 388 if( (res->p_type & t) == 0 ) (gdb) bt #0 boost::unit_test::framework::get (id=65536, t=tut_case) at \ impl/framework.ipp:388 #1 0x0000000100134805 in boost::unit_test::traverse_test_tree \ (suite=@0x100403f10, V=@0x7fff5fbff470) at framework.hpp:73 Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) print res $1 = ('boost::unit_test::test_unit' *) 0x0 (gdb) ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.

2 1