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

Stubbing for unit testing, what approach should I use
by Andrew Syrov 10 Oct '03

10 Oct '03

I am looking for set of techniques for isolation testing. As applications are designed with massive number of dependencies between classes and these dependencies end-up in external systems such as databases and OS, it's hard to extract function or part of class for efficient unit test. Basically I need an advice on what coding techniques should be used to allow flexible (generic?) stubbing: - function of a class may need to be tested in isolation from world (members could be global data for the purpose) - class may be tested with stubbed set functions; - data members could be stubbed, so no dependensies on classes which do not participate in test; Please advice. Andrew. _________________________________________________________________ Compare Cable, DSL or Satellite plans: As low as $29.95. https://broadband.msn.com

1 0

Enhancement to shared_pointer to support pointers to contained objects.
by Ricardo Capurro 09 Oct '03

09 Oct '03

Hello, We are really very happy and impressed with boost's smart_pointers, and we found the section "Smart Pointer Programming Techniques" (http://www.boost.org/libs/smart_ptr/sp_techniques.html) in boost smart_pointer documentation very useful, but we are having this problem: We have two classes X and Y, and each object of class X holds an object of class Y, and we need to implement a method in class X to get a shared_ptr<Y> so we can access Y instance inside X, and we need that X objects (that are too referenced by shared_ptr<X>) don't be deleted until all references to the Y object are destroyed. See the problem in this code: class Y {}; class X : public enable_shared_from_this<X> { Y y; public: shared_ptr<Y> ptr_y(); // Oops, how do we do here??? }; Our first approach was "Using a shared_ptr to hold a pointer to a statically allocated object" (http://www.boost.org/libs/smart_ptr/sp_techniques.html#static) but this doesn't work because X objects can be destroyed and we still have pointers to contained Y object, so we try a custom deletor like this: template <typename Z> class delegator_deletor { shared_ptr<Z> ptr; // Internal pointer to father X, wich contains Y public: delegator_deletor( shared_ptr<Z> const & ptrz ) : ptr( ptrz ) {} template <typename T> void operator()( T* ) { ptr.reset(); } // Null deletor, only resets pointer to father X object }; template <typename Z> delegator_deletor<Z> make_delegator_deletor( shared_ptr<Z> ptrz ) { return delegator_deletor<Z>( ptrz ); } class X : public enable_shared_from_this<X> { Y y; public: shared_ptr<Y> ptr_y() { return shared_ptr<Y>( &y, make_delegator_deletor( shared_from_this() ) ); } }; And now the problem was resolved but with one little drawback, we are not sharing the same counter between shared_ptr<X> and shared_ptr<Y>, so start looking boost's code to shange it in a way that it satisfies our needs, and we added this constructor to shared_ptr class: template<class Y,class Z> shared_ptr(Y* y, shared_ptr<Z> const & z): px(z.px ? y : 0), pn( y ? z.pn : detail::shared_count() ) // never throws { detail::sp_enable_shared_from_this(y, y, pn); } then we change X::ptr_y() this way: shared_ptr<Y> X::ptr_y() { return shared_ptr<Y>( &y, shared_from_this() ); } This new constructor instructs to create a shared_ptr<> that uses the same counter that the second's shared_ptr<> parameter, but point's to the first raw pointer paramenter. With this change everithing worked fine. Finally our question is: Is there an easyer way to solve our problem? If the answer is yes we want to know it and if the answer is no we want to know if you can enhace shared_ptr to solve this kind of problem. Thank you very much Ricardo #include <iostream> #include <string> #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> using namespace ::std; using namespace ::boost; #if !defined( SOLUTION1 ) && !defined( SOLUTION2 ) && !defined( SOLUTION3 ) && !defined( SOLUTION4 ) #define SOLUTION3 #endif #if defined( SOLUTION1 ) class null_deleter { public: template <typename T> void operator()( T* ) {} }; #elif defined( SOLUTION2 ) || defined( SOLUTION3 ) template <typename Z> class delegator_deletor { shared_ptr<Z> ptr; public: delegator_deletor( shared_ptr<Z> const & ptrz ) : ptr( ptrz ) { cerr << "delegator_deletor<" << typeid( Z ).name() << ">()" << endl; } template <typename T> void operator()( T* ) { ptr.reset(); cerr << "delegator_deletor<" << typeid( Z ).name() << ">()( " << typeid( T ).name() << "* )" << endl; } }; template <typename Z> delegator_deletor<Z> make_delegator_deletor( shared_ptr<Z> const & ptrz ) { return delegator_deletor<Z>( ptrz ); } #endif class Y : public enable_shared_from_this<Y> { Y( Y const & ); Y& operator=( Y const & ); public: Y() { cerr << "Y::Y()" << endl; } ~Y() { cerr << "Y::~Y()" << endl; } }; class X : public enable_shared_from_this<X> { Y y; int i; X( X const & ); X& operator=( X const & ); public: X() : y(), i( 7 ) { cerr << "X::X()" << endl; } ~X() { cerr << "X::~X()" << endl; } shared_ptr<Y> ptr_y() { #if defined( SOLUTION1 ) return shared_ptr<Y>( &y, null_deleter() ); #elif defined( SOLUTION2 ) return shared_ptr<Y>( &y, make_delegator_deletor( shared_from_this() ) ); #elif defined( SOLUTION3 ) shared_ptr<Y> py; try { py = y.shared_from_this(); } catch ( const bad_weak_ptr& ) { py.reset( &y, make_delegator_deletor( shared_from_this() ) ); } return py; #elif defined( SOLUTION4 ) return shared_ptr<Y>( &y, shared_from_this() ); #endif } shared_ptr<int> ptr_i() { #if defined( SOLUTION1 ) return shared_ptr<int>( &i, null_deleter() ); #elif defined( SOLUTION2 ) || defined( SOLUTION3 ) return shared_ptr<int>( &i, make_delegator_deletor( shared_from_this() ) ); #elif defined( SOLUTION4 ) return shared_ptr<int>( &i, shared_from_this() ); #endif } }; int main( const int, const char** ) { try { cerr << "(1)" << endl; shared_ptr<X> px( new X() ); cerr << "(2)" << endl; shared_ptr<Y> py = px->ptr_y(); cerr << "(3)" << endl; shared_ptr<int> pi = px->ptr_i(); cerr << "(4)" << endl; px.reset(); cerr << "(5)" << endl; py.reset(); cerr << "(6)" << endl; pi.reset(); cerr << "(7)" << endl; } catch ( const exception& e ) { cerr << "Exception caught: " << e.what() << endl; } catch ( ... ) { cerr << "Exception caught ..." << endl; } return 0; }

2 1

Re: [Boost-users] Re: Problem using Boost.thread : Class destructor calledseveral times!
by Huck finn 08 Oct '03

08 Oct '03

Ok, now I see that my object is being copied. But for the lines : FakeClass *item1 = new FakeClass(1);//,item2(2); group.create_thread(*item1); I get : FakeClass #1 says : I'm alive! FakeClass #1 says : Being Copied!! FakeClass #1 says : Being Copied!! FakeClass #1 says : Being Copied!! FakeClass #1 says : I'm being destroyed! FakeClass #1 says : I'm being destroyed! FakeClass #1 says : Being Copied!! FakeClass #1 says : I'm being destroyed! Thread for FakeClass #1 has been started! FakeClass #1 says : I'm being destroyed! main ending... The copy constructor is called 4 times!!! And it is called 3 times before the thread has even started! Is there a way to avoid that ? I was going to use the thread_group to manage the connection to a simple server applications, so that all the threads would hold info about the socket used for connection, etc... And that if the objectdestructor is called, the connection to the socket would be closed... With my object being destroyed 3 times before the thread has started, it gets a bit hard to manage that way... Any clue on how to use the threads so that it would work? thanks, Simon _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/

2 1

Re: compiler warnings...
by David Abrahams 08 Oct '03

08 Oct '03

David Ohlemacher <ohlemacher(a)bbn.com> writes: > Hi all from a boost newbie, > > Given: > Linux RH 8.0 > gcc 3.2 > BOOST_VERSION 103002 > > I created a boost app and it compiles and runs however I am getting > lots of warnings of the form > /usr/lib/boost/boost/iterator_adaptors.hpp:775:43: warning: > "BOOST_MSVC" is not defined. > > What am I not doing correctly? You're using -Wall ;-) We're currently discussing what to do about these warnings on the developers' list. Stay tuned, and until then turn off -Wall or live with the warnings. Sorry, -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 2

compiler warnings...
by David Ohlemacher 08 Oct '03

08 Oct '03

Hi all from a boost newbie, Given: Linux RH 8.0 gcc 3.2 BOOST_VERSION 103002 I created a boost app and it compiles and runs however I am getting lots of warnings of the form /usr/lib/boost/boost/iterator_adaptors.hpp:775:43: warning: "BOOST_MSVC" is not defined. What am I not doing correctly? I have both included and not included <boost/config.hpp> and I read (http://www.boost.org/libs/config/config.htm#header) that I should not include this. Thanks, -d

1 0

mpl + enum + VC = error
by nagual 06 Oct '03

06 Oct '03

Hello, All! I write simple code: =============mpl_enum.cpp============= #include <boost/mpl/range_c.hpp> #include <boost/mpl/for_each.hpp> #include <iostream> enum test_e {ONE, TWO, THREE}; void f(test_e e) { const char* names[] = {"ONE", "TWO", "THREE"}; std::cout<<names[e]<<std::endl; } typedef boost::mpl::range_c< test_e, ONE, static_cast<test_e>(THREE + 1) > range; int main() { boost::mpl::for_each<range>(f); return 0; } =============mpl_enum.cpp============= MSVC 7 (ver 13.00.9466) =============Command Line============== c:\cl /EHsc /GR /Zc:wchar_t /Zc:forScope /nologo mpl_enum.cpp =============Command Line============== =============Output===================== mpl_enum.cpp C:\Lang\Projects\boost\boost\mpl\aux_\integral_wrapper.hpp(78) : error C2440: 'return' : cannot convert from '' to 'test_e' Conversion to enumeration type requires an explicit cast (static_cast, C-style cast or function-style cast) C:\Lang\Projects\boost\boost\mpl\aux_\integral_wrapper.hpp(78) : while compiling class-template member function 'boost::mpl::integral_c<T,N>::operator`T'(void) const' with [ T=test_e, N=ONE ] C:\Lang\Projects\boost\boost\mpl\aux_\range_c\iterator.hpp(34) : see reference to class template instantiation 'boost::mpl::integral_c<T,N>' being compiled with [ T=test_e, N=ONE ] C:\Lang\Projects\boost\boost\mpl\for_each.hpp(70) : see reference to class template instantiation 'boost::mpl::range_c_iterator<N>' being compiled with [ N=boost::mpl::range_c<test_e,ONE,3>::start ] C:\Lang\Projects\boost\boost\mpl\for_each.hpp(101) : see reference to function template instantiation 'void boost::mpl::aux::for_each_impl<done>::execute(Iterator *,last *,transform_op *,void (__cdecl *)(test_e))' being compiled with [ done=false, Iterator=first ] C:\Lang\Projects\boost\boost\mpl\for_each.hpp(111) : see reference to function template instantiation 'void boost::mpl::for_each(F,range *,boost::mpl::identity<T> *)' being compiled with [ F=void (__cdecl *)(test_e), T=boost::mpl::void_ ] mpl_enum.cpp(15) : see reference to function template instantiation 'void boost::mpl::for_each(F,range *)' being compiled with [ F=void (__cdecl *)(test_e) ] =============Output===================== However gcc v3.2.3, icl v 7.1, bcc32 v5.6.4 compile it. (bcc32 show 3 equivalent warning). How use it in MSVC 7?

2 1

remove_pointer
by Leo Landa 05 Oct '03

05 Oct '03

Good day to everyone, I am trying to find a portable enough implementation of remove_pointer (MSVC 6, MSVC 7.1, G++ 2.95.3, G++ 2.96). The "usual" template technique relies on partial template specialization, which MSVC 6.0 does not support. As far as I can tell, Boost's version of remove_pointer is a little bit of a "cheat" - i.e. it becomes predefined only for primitive types. Am I right about that? I'm a bit of a newb in these parts of London ;-) If this is true, then I'm screwed - and I can't convert a generic pointer type to the pointee type. If it is not true, then what is the technique? Leo. P.S. Just in case - I know how to figure out _whether_ the type is a pointer, and now just trying to strip it.

2 2

iterators
by Witz 05 Oct '03

05 Oct '03

Hi, I would like to raise a couple of points about the iterator adaptors. Firstly, is it really necessary to have the predicate as part of the template specification for the filter_iterator? Surely it can be assumed that it will always be convertible to boost::function<bool (const value_type&)> ? Secondly, by allowing the return type of the function used by the transform_iterator to be a reference can we not use it to implement a more generic form of indirect_iterator? The code below gives a flavour of the idea. struct dereference { typedef int result_type; int* data_; dereference(int* data):data_(data){} int operator()(int i) const { return data_[i]; } }; int main() { int data[] = { 1,2,3,4,5,6,7,8 }; int keys[] = { 0,3,1,6,5,4,2,7 }; typedef boost::transform_iterator_generator<dereference, int*>::type indirect_iterator; indirect_iterator i(keys, dereference(data)), i_end(keys+8,dereference(data)); while(i != i_end) std::cout << *i++ << ' '; return 0; } The output is: 1 4 2 7 6 5 3 8 Witz

3 2

boost library build consistency
by Thomas S. Urban 03 Oct '03

03 Oct '03

Is there any definition of how libraries are supposed to build? I've integrated the building of required boost libraries into the build system for our projects. There seems to be some inconsistency in what gets built and where it gets put. In particular, for the thread and regex libs, boost builds both shared and static versions of the libraries and puts them in a bin-stage subdirectory under the library build directory. However, for the filesystem library, only the static library gets built and the bin-stage/ directory is not used. Is there a standard behavior library developers are supposed to follow in this regard? Can I count on the bin-stage/ as a short-named location for the most recent build of any library? Are the boost or boost_filestsystem maintainers interested in the simple fix to the Jamfile to make that library behave like the other two I mentioned? Thanks Scott Urban

3 3

parse error in format library
by Alan Stewart 03 Oct '03

03 Oct '03

I've been successfully using the tokenizer library for some time, and am very grateful for it. The format library looks very userful - I need to convert a bunch of old printf's to ostreams. However, in attempting to compile with gcc 2.96 I'm finding that there are many substitutions that need to be made, such as replacing "char_traits" with "basic_string". I'm using Boost 1.30.0 in production, but have also tried 1.30.2 with the same results. I see that the format library headers include the header file "boost/config.hpp". Is it likely that I have some sort of configuration error? Where do I find information on toolset compatabiliy for specific Boost libraries, since this one does not seem to be compatible with mine? -- D. Alan Stewart Senior Software Developer Layton Graphics, Inc. 155 Woolco Drive Marietta, GA 30065 Voice: 770/973-4312 Fax: 800/367-8192 http://www.layton-graphics.com

2 1