- Boost-users - lists.boost.org

[tests] Signals not well covered in unit tests (in contrast to exceptions)?
by Jens Seidel 27 Jul '07

27 Jul '07

Hi, I have the following problem with a C++ project on Linux using the Boost.test framework: I use the "resource acquisition is initialization" technique to ensure that all resources I allocate are properly released. That's why I have helper classes with a resource allocation in the constructor and deallocation in the destructor. One example of such a helper class is an indentation for my logging code: LOG("blabla"); { LogIndendation indent; // start indentation of output LOG("a message"); divide_by_zero(); LOG("a further message"); } // reset indentation LOG("blabla"); The output is normally: blabla a message a further message blabla Please note that divide_by_zero (which perform an integer division by zero) causes a SIGFPE fatal arithmetic error and the signal handler of Boost.test detects this. Nevertheless the destructor of LogIndendation is *not* called and all further tests I have create wrong indented output (which I compare with the expected output as another test too). So I get: test1 blabla a message unknown location(0): fatal error in "Test1": signal: SIGFPE (arithmetic exception) test2 blabla If I do not generate a signal but throw an exception instead, the destructor is called so this is fine. (Please note that g++ does normally not call a destructor with such a technique if the exception is not catched at all (probably because all resources are expected to be cleaned up, once the process terminates???), but Boost.test catchs all exceptions - good.) I also tried to write my own SIGFPE signal handler which just throws an exception. But this handler is not called, probably it's overwritten by Boost's one. Probably Boost doesn't call the previous handler because it normally terminates the application. But maybe it's possible for Boost to save the initial handler in main() and later to compare the current handler with the initial one. If they are equal handle signals as usual (output an error) otherwise do nothing and call the previous handler? Has anyone a good solution for me, or is there a problem with Boost.test and signals? How to solve this? Jens

1 0

boost 1.34.1 build.bat
by chun ping wang 27 Jul '07

27 Jul '07

For some reason i can no longer specify the toolset to use ...when i run build.bat mingw on my windows machine.. it defaults to msvc. Inside user-config.jam I have using mingw : : C://Dev-Cpp//bin//gcc ; but it keeps using msvc build.

3 3

Any update on a form of boost::threads getting into the C++ 0x standard?
by Graham Reitz 26 Jul '07

26 Jul '07

Our group has had a lot of success with boost::threads and grown comfortable with its use. Thanks, Graham

8 11

Boost with XCode 2.4.1
by Scott Froberg 26 Jul '07

26 Jul '07

Hi All, I'm very new around here. Is anyone using Boost with Apple's XCode 2.4.1? I'm having some trouble with adding the libraries correctly. Thanks, Scott ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

5 4

[Lambda] Trouble using istreambuf_iterators
by Scott Meyers 26 Jul '07

26 Jul '07

The following code using Lambda with vector iterators compiles without complaint: vector<char> v; find_if(v.begin(), v.end(), _1 == 'x'); Ditto for this code, which uses istream_iterators: istream_iterator<char> b1(cin); istream_iterator<char> e1; find_if(b1, e1, _1 == 'x'); But the same code with istreambuf_iterators gets rejected: istreambuf_iterator<char> b2(cin); istreambuf_iterator<char> e2; find_if(b2, e2, _1 == 'x'); Error messages from VC8 and gcc 4.1.1 are below. Am I doing something wrong, is there a bug in Lambda regarding istreambuf_iterators, or is this a restriction that I didn't see documented somewhere? Thanks, Scott VC8 says: lambda.cpp D:\Apps\Microsoft Visual Studio 8\VC\INCLUDE\algorithm(87) : error C2664: 'bool boost::lambda::lambda_functor<T>::operator ()<char>( A &) const' : cannot convert parameter 1 from 'char' to 'char &' [Instantiation traceback omitted] gcc 4.1.1. says: stl_algo.h:188: error: no match for call to '( boost::lambda::lambda_functor< boost::lambda::lambda_functor_base< boost::lambda::relational_action<boost::lambda::equal_action> , boost::tuples::tuple< boost::lambda::lambda_functor< boost::lambda::placeholder<1> >, const char > > > ) (char)' stl_algo.h: In function 'istreambuf_iterator<char, char_traits<char> > __find_if( istreambuf_iterator<char, char_traits<char> > , istreambuf_iterator<char, char_traits<char> > , boost::lambda::lambda_functor< boost::lambda::lambda_functor_base< boost::lambda::relational_action<boost::lambda::equal_action> , boost::tuples::tuple< boost::lambda::lambda_functor< boost::lambda::placeholder<1> >, const char > > >, input_iterator_tag )': [Instantiation traceback omitted]

4 11

Tuple use/overuse?
by Graham Reitz 26 Jul '07

26 Jul '07

I have been finding that the boost::tuple library is so convenient that I am concerned I may be overusing it. For example, in situations where I might use a struct I am tend to prefer a tuple. Where is a good place to draw the line in situations like this? Or is this the intent to use it as often as possible? Thanks much, Graham

6 14

[mpl] BOOST_MPL_AUX_LAMBDA_SUPPORT for classes without nested ::type
by Joaquín Mª López Muñoz 26 Jul '07

26 Jul '07

Hello, The following program does compile fine on a conformant compiler: #include <boost/mpl/apply.hpp> #include <boost/mpl/aux_/lambda_support.hpp> #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp> using namespace boost; using namespace boost::mpl; template<typename T> struct foo { BOOST_MPL_AUX_LAMBDA_SUPPORT(1,foo,(T)) }; template<typename T> struct bar { typedef T type; BOOST_MPL_AUX_LAMBDA_SUPPORT(1,bar,(T)) }; typedef apply1<foo<_1>,int>::type t1; typedef apply1<bar<_1>,int>::type t2; BOOST_MPL_ASSERT((is_same<t1,foo<int> >)); BOOST_MPL_ASSERT((is_same<t2,int>)); int main(){return 0;} Note that foo<_1> applied to int resolves to foo<int> whereas bar<_1> resolves to int, which is correct because the former class does not have a nested ::type while the latter does. This is documented in the MPL reference at: http://www.boost.org/libs/mpl/doc/refmanual/quote.html Now, if I compile the same program with a defective compiler (MSVC 6.0) not supporting PTS, I've got the following: ...\boost\boost\mpl\aux_\preprocessed\msvc60\apply_wrap.hpp(77) : error C2039: 'type' : is not a member of 'result_<int>' ...\boost\mpl\aux_\preprocessed\msvc60\bind.hpp(184) : see reference to class template instantiation 'boost::mpl::apply_wrap1<class foo_rebind,int>' being compiled whereas the code associated with bar<> works OK. So, it seems like BOOST_MPL_AUX_LAMBDA_SUPPORT does not provide lambda support for classes without nested ::type: 1. Is this so by design and/or documented somewhere? 2. If not, could it be fixed? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Compile probelms
by alex＠gorex.com.hk 26 Jul '07

26 Jul '07

Hi, I need help on compile Boost.Python. I keep having an error "cannot open file boost_python-vc80-mt-gd-1_34.lib" when I issue a commond bjam -sTOOLS=vc-8_0. I searched some notes from web and I added "import python" or "using python" already. However the problem still exists. anyone can advise?

2 1

Re: [Boost-users] [thread] comparison with Intel Threading BuildingBlocks
by Ovanes Markarian 26 Jul '07

26 Jul '07

On Wed, July 25, 2007 15:54, Andrew Holden wrote: > Toon Knapen wrote: >> I just received (again) some doc on the Intel Threading >> Building Blocks >> (TBB) (http://www.threadingbuildingblocks.org/) >> >> I was wondering how the boost.thread developers/supporters >> would compare TBB with boost.thread (btw: the book of James >> Reinders on TBB mentions boost.thread) ? > > The two libraries are meant to solve different problems. Boost.thread > handles situations where the programmer wishes to explicitly manage > threads, often giving each thread a distinct task to perform. It would > be useful for situations like worker threads in a GUI program. It is > also useful I/O-bound threads, which would cause TBB to waste a > processor core. > > TBB, on the other hand, is useful for situations in which you have a > parallelizable task to perform, and you would rather not worry about > threading details, like a parallel for loop. Do you mean that TBB is more like a "future" which might be added to the upcoming tr2? >[...] With Kind Regards, Ovanes Markarian

3 2

program_options error class
by ALiX 26 Jul '07

26 Jul '07

In the latest implementation of boost (1.34), the error class in boost::program_options is defined as a subclass of std::logic_error. This is, however, not stated in the documentation. In the documentation the class error is described as if it has no superclass from which it inherits. In my programs, can I safely rely on the fact that error inherits from std::logic_error, and so comfortably use the what() function to extract the error messages? Might this change in later implementations? Kind regards, /ALiX

2 3