- Boost-users - lists.boost.org

[Boost MPI]Problems with the installation of boost MPI
by Juliet Villanueva 27 Feb '10

27 Feb '10

Hi: I intet mpi program in boots, but when trying to compile a program, tells me that I need libs some one is libboost_mpi-vc90-mt-gd-1_40. lib, which tells me that is not installed, trying MPI boost installing again, I realized, that performs all the library facilities, but skips the installation of boost MPI do not know if someone could tell me step by step which is what I do to boost MPI install, from scratch, because I have almost 3 months trying to install it without success, another of my concerns is if I can install on a Windows XP, Vista, windows 7 and windows server and I have read some pages and tell me that I can only install on windows server This result also gave me hope I can help. Juliet Encuentra las mejores recetas en Yahoo! Cocina. http://mx.mujer.yahoo.com/cocina/

3 2

How to get return value of scoped_try_lock (boost:thread)
by David Kaplan 27 Feb '10

27 Feb '10

How do I know if my scoped_try_lock has been successful? I notice there is a try_lock non-member function, but that's not a scoped trylock is it?

2 3

[filesystem] Using basic_path in char-type generic code
by Adam Badura 27 Feb '10

27 Feb '10

I have a char-type generic function (character type is template argument). I use only char and wchar_t character types with this function and I don't care for other character types. I wanted to use basic_path in that function so that I will get either path or wpath depending on the template argument. But I failed to do that since basic_path has second template argument (Traits) which - as opposed to basic_string - does not default to anything. Even more, there is no (or at least documentation does not mention that) default path_traits template which could be parametrized with the desired character type. Why is it so? How to overcome it (otherwise then writing my own auxiliary type selector)? (I am using version boost 1.39 and will - hopefully, if it will correct compilation errors - switch to 1.43 when it will be released.) Adam Badura

3 3

[Review] ITL review planned to end tomorrow, February 28th
by Hartmut Kaiser 27 Feb '10

27 Feb '10

Hey all, We're almost at the planned end of Joachim Faulhabers ITL review (see the original review announcement here: http://comments.gmane.org/gmane.comp.lib.boost.announce/253) Now would be a good time to submit your reviews. If you need more time, please let me know. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

Re: [Boost-users] boost::asio::read_until w/ boost::function
by marty 27 Feb '10

27 Feb '10

Thanks for your response. I've sidestepped the issue by implementing a workaround. Thus, I'm not desperate to get this working (or upgrade the compiler). However, I've confirmed that this behavior is still present in boost 1.42.0 so perhaps it should be filed as a bug... or at least, docs should warn about 3.4.6 incompatibilities. > AMDG > > marty wrote: > >> Thanks for your input. Unfortunately; no dice. It still doesn't >> compile (below), and the error(also below) provides little insight in >> my relatively inexperienced assessment. I have a feeling that the >> enable_if mechanism is not behaving properly on my particular system. >> > > It isn't the enable_if per se that is causing the problem. > is_match_condition doesn't seem to work > properly. > > >> (the fact that others have successfully compiled this implies that the >> boost::function must have the correct signature to satisfy the >> enable_if....) >> >> >> ----error >> >> /usr/local/include/boost/asio/read_until.hpp:60: error: enumerator >> value for `value' not integer constant >> ../src/temp.cpp: In constructor `MyClass::MyClass()': >> > > The compiler doesn't seem to like the implementation of has_result_type > here. > > >> I'm following up my original post with some actual code an interested >> person might try to compile, as well as the specific errors I'm getting. >> boost 1.41.0, gcc 3.4.6 >> > Can you use a more recent compiler? > > It also /might/ work if you replace has_result_type with > BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type) > and add #include <boost/mpl/has_xxx.hpp>. > > In Christ, > Steven Watanabe >

1 0

1.39 serialisation: buggy warning message for shared_ptr
by Avi Bahra 27 Feb '10

27 Feb '10

When I want to serialise a vector of shared ptrs to concrete types, there are no warnings on gcc/Linux. and program runs correctly. However when I compile on HP-UX, I get the following: .../boost_1_39_0/boost/serialization/export.hpp", line 137: warning #2414-D: delete of pointer to incomplete class BOOST_STATIC_WARNING(boost::is_polymorphic<T>::value); .... It appears that boost shared ptr serialisation has made the assumption that the pointer must be polymorphic! Is this assumption correct ? i.e are we allowed to serialize shared ptrs to concrete types ? To get rid of the message I simply add a virtual member function. It appears in this case that HPUX compiler is more accurate, and I don't understand why this same warning does not appear with gcc. Best regards, Ta, Avi

3 2

Re: [Boost-users] [C++-sig] Boost python exception translation failure on BlueGene/P
by James Amundson 26 Feb '10

26 Feb '10

On 02/18/2010 04:24 PM, James Amundson wrote: > Boost Python seems to be failing to catch and translate C++ exceptions > for me on a BlueGene/P installation. I really don't know what to do > next in debugging the problem, so I would appreciate any advice. I have finally solved this problem myself -- I am responding to my own message on these mailing lists in case this information is useful to others. In the end the solution was to add the flag "-dynamic" to the libboost_python link line. Without the flag, boost::python mostly works on BlueGene/P, but exceptions are not caught. With the flag, boost_python passes all tests I have done. I spent some time trying to understand how to tell bjam to add a flag to the boost_python link line, but I gave up after about fifteen minutes. With the CMake build of boost, it was easy: I simply did cmake -DCMAKE_SHARED_LINKER_FLAGS="-dynamic" Overall, I found dealing with the cmake build of boost so much more pleasant than dealing with bjam that I don't understand why the CMake build hasn't taken over the mainstream yet. --Jim Amundson P.S. The original problem report: > I have a simple test module, pyexcept > ------------------------------------------------------------ > #include <boost/python.hpp> > #include <iostream> > #include <stdexcept> > > > void > foo() > { > std::cout << "in foo, about to raise exception\n"; > throw std::runtime_error("runtime_error from foo"); > std::cout << "this should never be seen\n"; > } > > using namespace boost::python; > > BOOST_PYTHON_MODULE(pyexcept) > { > def("foo",foo); > } > ------------------------------------------------------------ > > I test it with the following python script: > ------------------------------------------------------------ > #!/usr/bin/env python > > import pyexcept > > print "about to run pyexcept.foo, catching exception" > try: > pyexcept.foo() > except RuntimeError,e: > print "caught RuntimeError,",e > ------------------------------------------------------------ > > On my Linux machine I see: > ------------------------------------------------------------ > about to run pyexcept.foo, catching exception > in foo, about to raise exception > caught RuntimeError, runtime_error from foo > ------------------------------------------------------------ > > On the BlueGene/P machine I see: > ------------------------------------------------------------ > about to run pyexcept.foo, catching exception > in foo, about to raise exception > terminate called after throwing an instance of 'std::runtime_error' > what(): runtime_error from foo > ------------------------------------------------------------ > > I have (cross-)compiled boost myself using the system's installed > version of the gnu compilers, 4.1.2: > ------------------------------------------------------------ > |login2>mpicxx.gnu --version > powerpc-bgp-linux-g++ (GCC) 4.1.2 (BGP) > ------------------------------------------------------------ > > (The mpicxx.gnu script is a wrapper around the cross-compiling g++.) > Has anyone seen a problem like this? Any ideas as to how to debug it? > > Thanks for any advice. > > --Jim Amundson > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig(a)python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig

3 2

Static link boost library using arm compiler
by Carlos 26 Feb '10

26 Feb '10

Hi I'm some weeks trying to resolve a problem in static linking a boost library. The compiler finds the library but it says that it is incompatible. I already try to compile boost again with arm compiler, use boost 1_33_1 and boost_1_42_0 but with no results. I think it's missing something but I can't find what. ./configure -host=arm-eabi CC=arm-none-linux-gnueabi-gcc CXX=arm-none-linux-gnueabi-g++ CXXFLAGS=-static --with-boost=/usr/local/boost_1_42_0/ configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-eabi-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for arm-eabi-gcc... arm-none-linux-gnueabi-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-none-linux-gnueabi-gcc accepts -g... yes checking for arm-none-linux-gnueabi-gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of arm-none-linux-gnueabi-gcc... gcc3 checking whether we are using the GNU C++ compiler... yes checking whether arm-none-linux-gnueabi-g++ accepts -g... yes checking dependency style of arm-none-linux-gnueabi-g++... gcc3 checking for boostlib >= 1.31... yes checking build system type... i686-pc-linux-gnu checking whether the Boost::Thread library is available... yes checking for exit in -lboost_thread... no checking for exit in -lboost_thread... (cached) no checking for exit in -lboost_thread... (cached) no configure: error: Could not link against boost_thread ! * Config.log:* configure:4066: checking whether the Boost::Thread library is available configure:4098: arm-none-linux-gnueabi-g++ -c -pthread -static -I/usr/local/boost_1_42_0//include conftest.cpp >&5 configure:4098: $? = 0 configure:4113: result: yes configure:4142: checking for exit in -lboost_thread configure:4167: arm-none-linux-gnueabi-gcc -o conftest -g -O2 -I/usr/local/boost_1_42_0//include -L/usr/local/boost_1_42_0//lib conftest.c -lboost_thread >&5 conftest.c:20: warning: conflicting types for built-in function 'exit' /home/carlos/arm/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/local/boost_1_42_0//lib/libboost_thread.so when searching for -lboost_thread /home/carlos/arm/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/local/boost_1_42_0//lib/libboost_thread.a when searching for -lboost_thread /home/carlos/arm/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/carlos/arm/arm-2009q3/bin/../arm-none-linux-gnueabi/libc/usr/lib/libboost_thread.a when searching for -lboost_thread /home/carlos/arm/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /home/carlos/arm/arm-2009q3/bin/../arm-none-linux-gnueabi/libc/usr/lib/libboost_thread.a when searching for -lboost_thread /home/carlos/arm/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lboost_thread collect2: ld returned 1 exit status

4 11

[variant] Variant call forwarding?
by Rutger ter Borg 26 Feb '10

26 Feb '10

Hello, I'm wondering what's the easiest way to enable call forwarding by a variant to contained function objects accepting the same arguments? I.e., variant< F, G > m_funcs; m_funcs = f; m_funcs( a, b, c ); m_funcs = g; m_funcs( a, b, c ); Thanks, Cheers, Rutger

5 10

boost::asio::read_until w/ boost::function
by marty 26 Feb '10

26 Feb '10

I'm having some trouble resolving the call to read_until (see snippet below) Is there some reason I am not be able to use a boost::function as the MatchCondition object? Thanks, ...m _______________ [MyClass.h] class MyClass { ... typedef boost::asio::buffers_iterator<boost::asio::streambuf::const_buffers_type> t_Iterator; typedef std::pair<t_Iterator, bool> t_ConditionPair; boost::asio::serial_port _port; boost::asio::streambuf _readBuffer; t_ConditionPair myCondition(t_Iterator begin, t_Iterator end); void doRead(); ... }; [MyClass.cpp] MyClass::t_ConditionPair myCondition(t_Iterator begin, t_Iterator end) { t_ConditionPair theCondition; theCondition.first = end; theCondition.second = true; return theCondition; } void MyClass::doRead() { ... boost::asio::read_until( _port, _readBuffer, boost::bind( &MyClass::myCondition, this, _1, _2 ) ); ... }

4 4