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

Problems with MPI and PBGL
by siva teja 11 May '13

11 May '13

> > > Hi friends, > > I am working on delta stepping algorithm. Recently I came across > "Parallel Boost Library" but when I tried to call distributed > delta-stepping, from /libs/graph_parallel/test as, "mpiCC > -I/usr/lib/openmpi/include/ distributed_shortest_paths_test.cpp ", it is > reporting, > > distributed_shortest_paths_test.cpp:(.text+0x5892): undefined reference to > `boost::mpi::communicator::communicator()' > distributed_shortest_paths_test.cpp:(.text+0x58a8): undefined reference to > `boost::graph::distributed::mpi_process_group::mpi_process_group(boost::mpi::communicator)' > distributed_shortest_paths_test.cpp:(.text+0x5a00): undefined reference to > `boost::graph::distributed::mpi_process_group::~mpi_process_group()' > distributed_shortest_paths_test.cpp:(.text+0x5a17): undefined reference to > `boost::graph::distributed::mpi_process_group::~mpi_process_group()' > /tmp/ccP7trmD.o: In function `test_main(int, char**)': > distributed_shortest_paths_test.cpp:(.text+0x5ca7): undefined reference to > `boost::mpi::environment::environment(int&, char**&, bool)' > distributed_shortest_paths_test.cpp:(.text+0x5d60): undefined reference to > `boost::mpi::environment::~environment()' > distributed_shortest_paths_test.cpp:(.text+0x5d7c): undefined reference to > `boost::mpi::environment::~environment()' > /tmp/ccP7trmD.o: In function > `__static_initialization_and_destruction_0(int, int)': > distributed_shortest_paths_test.cpp:(.text+0x5e84): undefined reference to > `boost::system::generic_category()' > distributed_shortest_paths_test.cpp:(.text+0x5e90): undefined reference to > `boost::system::generic_category()' > distributed_shortest_paths_test.cpp:(.text+0x5e9c): undefined reference to > `boost::system::system_category() > ... > ... > .. > .. > > I am not able to compile any of the parallel graph examples. I tested MPI > with some mpi examples from boost website<http://www.boost.org/doc/libs/1_43_0/doc/html/mpi/getting_started.html#mpi.…>and they worked fine. I guess the problem is with linking MPI. I would be > grateful if you could help me out of this situation. > > > > Thanking you, > Siva teja. > > > >

2 3

Re: [Boost-users] Boost-users Digest, Vol 3442, Issue 1
by Dan Searles 11 May '13

11 May '13

>>> Hello, >>> >>> the code here doesn't compile: >>> >>> #include <boost/mpl/string.hpp> >>> #include <iostream> >>> >>> namespace mpl = boost::mpl; >>> >>> typedef mpl::string<'h','e','l','l','o',' ','w','o','r','l','d'>::type >>> my_hello; >>> >>> int main() >>> { >>> std::cout << mpl::c_str<my_hello>::value << '\n'; >>> std::cout << BOOST_MPL_LIMIT_STRING_SIZE << '\n'; >>> } >>> >>> As usual, the example from docs works. The error is: ><snip> >> >> I'm surprised multi-character character constants are being used at all in Boost, they >> are not supposed to be portable: >> >> http://stackoverflow.com/questions/6944730/multiple-characters-in-a-charact… > >Boost has never shied away from non-portable constructs. However, it >*does* wrap non-portable constructs in config macros to ensure a >consistent cross-platform experience, which is what mpl::string does >with multichar literals. Does the wrapping include handling 'qwer' on platforms where int is not 4 bytes? It may, I don't have a way to test it. > >> If you only want to use single character constants, you could place the following #define before any includes: >> > >#define BOOST_MPL_LIMIT_STRING_SIZE (32*4) >> >> That would allow up to 32, provided your compiler supports it (yet another portability issue).>> > >That would increase the compile time and decrease readability for no >benefit, IMO. Opinions may differ on the readability of: typedef mpl::string<'hell','o wo','rld'> ...... vs: typedef mpl::string<'h','e','l','l','o',' ','w','o','r','l','d'>..... But increasing compile time would be bad. That's why I'm asking if it would be possible for there to be an mpl::string<> that takes BOOST_MPL_LIMIT_STRING_SIZE 'char's? [It looks like 'x' started being a char in C++11, so it may be complicated supporting prior versions] > >> Since in C++, the type of 'x' is char, it should be possible to create another overload of >> mpl::string<> that takes BOOST_MPL_LIMIT_STRING_SIZE 'char's, which would work >> the way most people would expect.. > >How do you think most people expect it to work? My opinion is that most programmers would expect BOOST_MPL_LIMIT_STRING_SIZE single character constants to work. I know that multi-character constants are not always portable, so I try not to use them, even if a particular instance may be portable. > >-- >Eric Niebler >Boost.org >http://www.boost.org Dan Searles

1 0

Re: [Boost-users] mpl::c_str<mpl::string<>> compile error
by Dan Searles 11 May '13

11 May '13

>Hello, > >the code here doesn't compile: > >#include <boost/mpl/string.hpp> >#include <iostream> > >namespace mpl = boost::mpl; > >typedef mpl::string<'h','e','l','l','o',' ','w','o','r','l','d'>::type >my_hello; > >int main() >{ > std::cout << mpl::c_str<my_hello>::value << '\n'; > std::cout << BOOST_MPL_LIMIT_STRING_SIZE << '\n'; >} > >As usual, the example from docs works. The error is: > >$ LANG=en g++ t.cpp -o t && ./t >t.cpp:6:64: error: wrong number of template arguments (11, should be 8) >/usr/local/include/boost/mpl/string.hpp:102:12: error: provided for >'template<int C0, int C1, int C2, int C3, int C4, int C5, int C6, int >C7> struct boost::mpl::string' >t.cpp:6:72: error: expected initializer before 'my_hello' >t.cpp: In function 'int main()': >t.cpp:10:26: error: 'my_hello' was not declared in this scope >t.cpp:10:34: error: template argument 1 is invalid > >why does it complain about wrong number of template arguments? >BOOST_MPL_LIMIT_STRING_SIZE is 32? > >$ svn info >... >Path: . >URL: http://svn.boost.org/svn/boost/trunk >Repository Root: http://svn.boost.org/svn/boost >Repository UUID: b8fc166d-592f-0410-95f2-cb63ce0dd405 >Revision: 83988 >... >$ LANG=en g++ --version >g++ (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) >... > >Thanks, >Olaf I'm surprised multi-character character constants are being used at all in Boost, they are not supposed to be portable: http://stackoverflow.com/questions/6944730/multiple-characters-in-a-charact… If you only want to use single character constants, you could place the following #define before any includes: #define BOOST_MPL_LIMIT_STRING_SIZE (32*4) That would allow up to 32, provided your compiler supports it (yet another portability issue). Since in C++, the type of 'x' is char, it should be possible to create another overload of mpl::string<> that takes BOOST_MPL_LIMIT_STRING_SIZE 'char's, which would work the way most people would expect. Dan Searles

2 1

boost::disable_interruption problem
by Mohammad Daei 10 May '13

10 May '13

Hi. I'm trying to use boost package in Eclipse platform. In this line of code: boost::this_thread::disable_interruption di; Although boost-1.41.0-17 is installed and I have included boost/thread.hpp in the code, I receive the this error: undefined reference to 'boost::this_thread::disable_interruption::disable_interruption() I'm using CentOS 6 and gcc compiler. Anyone knows what's causing this problem?

4 7

Boost Serialization now results in a compiler error - I have a fix, but I'm still unsure as to the cause
by Lasse Laursen 10 May '13

10 May '13

Dear boosters, I work with Cinder, creating an audio mixing app. Having recently reached a milestone, I've upgraded from Vs2010 to Vs2012 as well as to the latest Cinder (0.8.5) which also upgraded boost to 1.53. While porting some code over that uses Serialization, I suddenly provoked the following compiler error: error C4308: negative integral constant converted to unsigned type pointing me at the following code in in the boost print.hpp: template <class T> struct print : mpl::identity<T> #if defined(__MWERKS__) , aux::print_base #endif { #if defined(BOOST_MSVC) enum { n = sizeof(T) + -1 }; #elif defined(__MWERKS__) void f(int); #else enum { n = # if defined(__EDG_VERSION__) aux::dependent_unsigned<T>::value > -1 # else sizeof(T) > -1 # endif }; #endif }; It's specifically the 'enum { n = sizeof(T) + -1 };' which triggers the error. I simplified my code, and it seems to occur regardless of what I do when I use the << operator to serialize the simple object I'm working with. Googling the issue turned up someone else in the same boat who received the same message as a warning, rather than a distinct *error*. The advice given was among other things to issue the following macro: (http://lists.boost.org/boost-users/2010/05/59103.php) BOOST_CLASS_TRACKING(mySimpleObject, boost::serialization::track_never) My question is simply if someone else has experienced something similar after upgrading to vs2012 or perhaps knows what is causing it? Given that I've not touched my code, and it seems to me that simply upgrading provoked this issue, I'm leaning towards assuming it's a recent computability issue between boost and msvc? Regards, Gazoo

1 0

Redefining new, to detect memory leaks, causes issues in boost
by Lasse Laursen 10 May '13

10 May '13

Hellos, I recently upgraded to vs2012 and am making liberal use of its leak detection described here: http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx However, I'm running into a spot of trouble. I rely on the C++ style new commands to allocate memory and as such, I make use of redefining this call in order to get a specific file and line, at the end of my programs execution, to where I allocated memory which is leaking. It's super effective! According to the link above, the new command is to be redefined thusly: #ifdef _DEBUG #ifndef DBG_NEW #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ ) #define new DBG_NEW #endif #endif // _DEBUG However, boost no likey. I get a syntax error in 'initializer.hpp' at the following line (122) of code: new(dest) value_T( boost::detail::variant::move(operand) ); ... saying it no longer knows what 'dest' is. A bit puzzling to be honest. I'm no C++ artisan, so I'm a bit stumped as to how I should elegantly avoid this issue. I really don't need boost to use this redefined new, as I'm sure it's as leak proof as can be, but I'm not sure if it's possible to somehow define my way out of that jam? Or perhaps change the definition so that the line no longer results in a syntax error. Any ideas? Regards, Lasse

3 4

Access violation while deleting ssl socket
by Martinell, Dan F 10 May '13

10 May '13

I just upgraded the boost libraries from 1.43 to 1.53 and switched from a 32bit build to a 64bit build. The code worked fine before the upgrade but in 1.53 I am getting an out of access violation while trying to delete the sslSocket. Here is a sample of the code: ssl::stream<ip::tcp::socket>* sslSocket = (ssl::stream<ip::tcp::socket>*) NULL; sslSocket = new ssl::stream<ip::tcp::socket>(io_service, ctx); sslSocket->lowest_layer().connect(*endpoint_iterator, error); sslSocket->handshake(ssl::stream_base::client); sslSocket->shutdown(); delete sslSocket; //This throws the exception I also tried doing this and several variations of it but I still have the same issue: sslSocket->lowest_layer().cancel(); sslSocket->lowest_layer().shutdown(boost::asio::ip::tcp::socket::shutdown_both,EC); sslSocket->lowest_layer().close(); delete sslSocket; I read through the documentation and the examples but didn't see anything that describes how to do this properly. Does anyone know why this wouldn't work or the proper way to close the SSL connection? I can provide more of the code if that would be helpful. Thanks, Dan Martinell Application Security Boeing Information Security cell: 425-283-6712

1 0

UDP: socket::open does not take an endpoint
by Chris Stankevitz 08 May '13

08 May '13

Hello, boost::asio::ip::udp::socket offers two ways to open: a) pass io_service and endpoint to the socket::socket b) pass io_service to socket::socket, then call socket::open === The UDP async server example uses method (a): boost::asio::ip::udp::socket Socket( IoService, boost::asio::ip::udp::endpoint(boost::asio::ip::udp::v4(), 13)); === Question 1: Why doesn't boost UDP allow me to use method (b) with an endpoint? For example, this is impossible: boost::asio::ip::udp::socket Socket(IoService); Socket.open(boost::asio::ip::udp::endpoint(boost::asio::ip::udp::v4(), 13)); // error: open does not take a boost::asio::ip::udp::endpoint === Question 2: How can I modify the UDP async server example to use method (b)? Thank you, Chris

2 3

Interprocess : appending data
by Oodini 08 May '13

08 May '13

Hello, I create a shared_memory_object, truncate it to set its size, and then create a mapped_region. I would like to know it would be possible to append new data, by applying a new truncation. Also, is it possible to have a second name pointing in the same memory, but with an offset ? Thanks.

2 3

weird problem with mutexes on boost::interprocess
by Hernán Leoni 08 May '13

08 May '13

It seems we found a weird bug with boost interprocess, some internal problem on the scoped_lock is generating a deadlock. A simple correct usage like void foo() { scoped_lock<t_mutex> lock(amutex); ..... } is producing the deadlock when running 100 concurrent processes after changing to void foo() { amutex.lock(); ..... amutex.unlock(); } the problem disappeared the code on scoped_lock looks correct, and works just fine with a lower load, so, I guess this is something coming from the compiler, which is gcc 4.4.7 under linux did anyone get similar problems? thanks

1 0