- Boost-users - lists.boost.org

RE: [Boost-Users] Unary predicate for shared_ptr == 'real' pointe r?
by Mark Storer 11 Apr '03

11 Apr '03

The whole "new int" thing seems a little odd, but that's an artifact of creating example code. What do your co-workers say? I feel like I'm missing something here. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

1 0

RE: [Boost-Users] Unary predicate for shared_ptr == 'real' pointe r?
by Tom Matelich 11 Apr '03

11 Apr '03

> From: dick.bridges(a)tais.com [mailto:dick.bridges@tais.com] > Sent: Friday, April 11, 2003 11:54 AM > > This is probably more of a C++ than an boost question but, since it > involves shared_ptr, I thought I'd try it here first. I've > got a vector of > shared_ptrS (e.g., vector<shared_ptr<T> > v;) and I need to > find the entry > given the 'real' pointer to the underlying T. Looping thru > the vector like > this: > > <snippet> > for( vector<shared_ptr<T>::iterator itr = v.begin(); itr != > v.end(); itr++) > { > if( itr->get() == real_this){...} > } > </snippet> > > works but seems klunky. I should be able to use [find_if( > v.begin(), v.end > (), ???)] but I can't work out the predicate. Any help or > "pointers" ;) > will be greatly appreciated. > Here's how I like to do it, though my co-workers sometimes complain: #include "boost/shared_ptr.hpp" #include "boost/bind.hpp" #include <vector> #include <iostream> int main() { typedef std::vector<boost::shared_ptr<int> > V; V vec; int* foo = new int; vec.push_back(boost::shared_ptr<int>(foo)); V::iterator iter = std::find_if(vec.begin(), vec.end(), boost::bind(std::equal_to<int*>(), boost::bind(&boost::shared_ptr<int>::get, _1), foo)); if(iter != vec.end()) std::cout << "Life is good" << std::endl; //don't delete foo!!! return 0; } Tom ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

Unary predicate for shared_ptr == 'real' pointer?
by dick.bridges＠tais.com 11 Apr '03

11 Apr '03

This is probably more of a C++ than an boost question but, since it involves shared_ptr, I thought I'd try it here first. I've got a vector of shared_ptrS (e.g., vector<shared_ptr<T> > v;) and I need to find the entry given the 'real' pointer to the underlying T. Looping thru the vector like this: <snippet> for( vector<shared_ptr<T>::iterator itr = v.begin(); itr != v.end(); itr++) { if( itr->get() == real_this){...} } </snippet> works but seems klunky. I should be able to use [find_if( v.begin(), v.end (), ???)] but I can't work out the predicate. Any help or "pointers" ;) will be greatly appreciated. TIA

1 0

RE: [Boost-Users] Boost random's min < max assert
by Glen Knowles 11 Apr '03

11 Apr '03

From: Jens Maurer >> Uniform int contains an assert if min < max. If I ask for a random between 1 >> and 1 I'm expecting a 1, not an assert. Is there some reason this was deemed >> inappropriate? > >When I wrote that code, I never thought somebody would want to generate >a constant 1 as a random number. I agree that this looks non-orthogonal >on first sight. I'll look into it. In my specific case I have a number of objects determined at run time and am randomly picking a number between one and the number of objects in order to select one. The workaround is to simply test for one before the call, but the assert was unexpected. Thanks, Glen [Non-text portions of this message have been removed]

1 0

RE: [Boost-Users] Problem with boost::pool_alloc
by scleary＠jerviswebb.com 11 Apr '03

11 Apr '03

> -----Original Message----- > From: Ilya Chvetsov(work) [mailto:chvetsov@kdlab.com] > > Hi! > I try to use boost::pool_alloc with STLport-4.5-0119 snapshot. > STLPort call pool_alloc::allocate(const size_type n) with n = 0. > STLPort naitive allocator returns in such case NULL, but pool_alloc > tries return memory. Hmmm... You seem to have uncovered a corner case, not covered by the Standard requirements. I will change the pool_allocator (and fast_pool_allocator) to be able to handle this by returning NULL. > Method simple_segregated_storage<SizeType>::try_malloc_n( > void * & start, size_type n, const size_type partition_size) has > problem too if parameter n is 0. Problem is in while condition: > while (--n != 0)... This is correct; (n > 0) is a precondition for that function. -Steve

1 0

RE: [Boost-Users] Problems with iterator_adaptors
by Ben Hutchings 11 Apr '03

11 Apr '03

Olaf Petzold wrote: > I try to write a cyclic Iterator using boost::iterator_adaptors. > Unfortunally, the advance function doesn't work for negative distances > correct: > template<class Iterator> > class cycle_iterator_policies > { > public: > cycle_iterator_policies(const Iterator& begin, const Iterator& end) > : m_begin( begin ), m_end( end ) > { > assert( m_begin != m_end ); > } > .... > template<class IteratorAdaptor, class DifferenceType> > void advance( IteratorAdaptor& x, DifferenceType n ) { > n %= std::distance( m_begin, m_end ); <snip> The problem is that the result of % and / (and by implication %= and /=) is implementation defined if either operand is negative. Most implementations round the quotient towards zero and produce a remainder with the same sign as the quotient. Evidently you want to have a non-negative remainder always. The simplest solution, I think, is: DifferenceType length = std::distance( m_begin, m_end ); n %= length; if (n < 0) n += length;

1 0

Re: thread lib using workshop CC on solaris
by Christopher Currie 11 Apr '03

11 Apr '03

I tried to send this earlier using the newsgroup, but it seems to have been dropped on the floor. Sorry for the duplicate if it shows up. The latest version of boost has some support for some versions of this compiler. The appropriate jamfile is "sunpro-tools.jam" (Sunpro is an old name for this compiler.) Thus: cd $BOOST_ROOT/libs/thread/build bjam -sTOOLS=sunpro That said, your mileage may vary on this compiler. I have found that it is notoriously buggy, especially wrt templates, and boost code will often cause it heartache in obscure ways. My results have found: * Up-to-date patches for the compiler and the operating system are a must. Find them here: http://access1.sun.com/sundev/index.html * Both versions of this compiler that I have tested have issues with Boost.TypeTraits, generating loads of spurious "Anacronism" warnings wrt the typename keyword being absent or present. Unfortunately, sun has not provided a flag to silence these warnings, and adding typename to the locations it complains about breaks other compilers, notably g++. * Both versions of this compiler will have problems linking some Boost unit tests, due to odd template RTTI issues. Adding -sBUILD="<cxxflags>-instances=static" will sometimes fix this problem. I don't recommend making this flag a default, because of the code bloat that entails. * Sun CC 5.4 ( Workshop/Forte Developer/SunOne Studio 7 ) will successfully build Boost.Threads. * Sun CC 5.3 update 2 ( W/FD/SOS 6u2 ) will only build Boost.Threads in release mode. This compiler generates assertions when attempting to compile the debug libraries. * I have not tested any versions earlier than Workshop 6 update 2. "jenny_qzhang" <jenny_qzhang(a)yahoo.com> wrote in message news:b722dr+7f4@eGroups.com... > Hi, All > > I am working on porting an application from MSVC to solaris > workshop(the applicatoin is using boost thread lib). I could not > locate the makefile or jam file for this compiler. Is there anybody > did the same thing before? > > If you finially made it, can you share your experience, makefile > with me? Actually I tried to write a makefile myself, but it reported > a lot of errors related to template parameters :(. > > > Thanks very much! > > Qiu

1 0

Problems with iterator_adaptors
by Olaf Petzold 11 Apr '03

11 Apr '03

Hello, I try to write a cyclic Iterator using boost::iterator_adaptors. Unfortunally, the advance function doesn't work for negative distances correct: template<class Iterator> class cycle_iterator_policies { public: cycle_iterator_policies(const Iterator& begin, const Iterator& end) : m_begin( begin ), m_end( end ) { assert( m_begin != m_end ); } .... template<class IteratorAdaptor, class DifferenceType> void advance( IteratorAdaptor& x, DifferenceType n ) { n %= std::distance( m_begin, m_end ); DifferenceType rest = std::distance( x.base(), m_end ); if( n < rest ) std::advance( x.base(), n ); else std::advance( x.base() = m_begin, n - rest ); } .... private: Iterator m_begin; Iterator m_end; }; It seems to be an algorithmic problem for me. How can I corrected it? Thanks Olaf

1 0

Signals and noncopyable
by svanechel 11 Apr '03

11 Apr '03

Hi, Is there a reason why siganls aren't copyable? As far as I can tell signal base derives from noncopyable, but it references its implementation using shared_ptr. So I'm guessing in theory a signal is perfectly copyable. I must admit I came to this conclusion by briefly looking at the code, so I might be completely wrong. I want to store signals into a vector of function<void()>'s, together with bound arguments, to capture events and replay them later. Something similar to (simplified): class recorder { public: // this is the handler for some event // it is connected to another signal void some_event( int i) { events_.push_back( bind( ev, i ) ); } void replay() { vector< function<void()> >::const_iterator itr = events_.begin(); while ( itr != events_.end() ) { (*itr)(); ++itr; } } signal<void(int)> ev; private: vector< function<void()> > events_; }; recorder rec; // connect the recorder to the signals is uses ... // now replay the events rec.ev.connect( some_handler ); rec.replay(); The example above may no be entirely correct since I'm coding this directly without running it through a compiler, but I hope the intent is clear. If I remove the derivation from noncopyable from signal_base, a sigal can be assigned to a function, although I haven't tested it yet to see if it actually works (currently I do not have something I can start testing with). Is it safe to remove the noncopyable base class? If so can it be done in the next release of the boost distribution as well? Thanks in advance, Sven Van Echelpoel

1 0

Problem with boost::pool_alloc
by Ilya Chvetsov(work) 11 Apr '03

11 Apr '03

Hi! I try to use boost::pool_alloc with STLport-4.5-0119 snapshot. STLPort call pool_alloc::allocate(const size_type n) with n = 0. STLPort naitive allocator returns in such case NULL, but pool_alloc tries return memory. Method simple_segregated_storage<SizeType>::try_malloc_n( void * & start, size_type n, const size_type partition_size) has problem too if parameter n is 0. Problem is in while condition: while (--n != 0)... This simple program demonstrates a problem: #include <boost/pool/poolfwd.hpp> #include <boost/pool/pool_alloc.hpp> typedef boost::pool_allocator<int> alloc_t; int main(int argc, char* argv[]) { alloc_t alloc; alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); alloc.allocate(0); return 0; } How can I solve this problem? Thanks -Ilya

1 0