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

[ptr_container]copy from one to other with iterator
by Thomas Matelich 24 Aug '05

24 Aug '05

I'm looking at ptr_vector to replace our wrapper around vector<shared_ptr>. How do I correctly write the following: ptr_vector<T> a; ptr_vector<T> b; ... b.push_back(a.begin()); I've tried plain iterators, dereferencing, *iter.base(), etc. I guess I could reinterpret_cast<T*>(*iter.base()). Is there a better way? Also, theres a typo in the docs. The examples page talks about using allocate_clone, and I'm pretty sure its supposed to be new_clone (If not, theres a typo in the tutorial). Thanks, Tom

3 8

Re: [Boost-users] [BULK] Re: [BULK] Re: [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Wednesday, August 24, 2005 12:15 PM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [BULK] Re: [BULK] Re: > [Test] Asserting a failure > Importance: Low > > > > On second thought, why not just modify BOOST_REQUIRE? > > What do you propose to modify? > > One could use BOOST_REQUIRE *instead* of assert() or > BOOST_ASSERT. But if > they prefer keep using BOOST_ASSERT I could provide a handler. Well theres no problem using BOOST_ASSERT unless they use it in their code for different reasons. For example they might use it to log in production versions of the application... I guess its not such a big deal if boost test defines its own handler if enable assert handler is not defined. I don't even remember where this thread started :)

1 0

Re: [Boost-users] [BULK] Re: [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Sohail Somani > Hmm. That's an idea. I could probably do this within > > Boost.Test so users > > wouldn't need to bother: > > > > test_tools.hpp: > > > > #if !defined(BOOST_TEST_NO_ASSERT_HANDLER) > > > > namespace boost { > > inline void assertion_failed(char const * expr, char const * > > function, char > > const * file, long line) > > { > > ... > > } > > } > > > > #endif > > > > This way by default I will always supply definition for the > > function, unless > > user is willing to suply different one. > > I imagine that would work unless they already use boost > assert and define it in their own code for logging purposes. > Perhaps something along the lines of boost assert for boost test? On second thought, why not just modify BOOST_REQUIRE?

2 1

Re: [Boost-users] [BULK] Re: [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Wednesday, August 24, 2005 11:50 AM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [BULK] Re: [Test] Asserting > a failure > Importance: Low > > > > > Try replacing your asserts with BOOST_ASSERT which can be a passive > > assert depending on how you use it. > > > > http://www.boost.org/libs/utility/assert.html > > Hmm. That's an idea. I could probably do this within > Boost.Test so users > wouldn't need to bother: > > test_tools.hpp: > > #if !defined(BOOST_TEST_NO_ASSERT_HANDLER) > > namespace boost { > inline void assertion_failed(char const * expr, char const * > function, char > const * file, long line) > { > ... > } > } > > #endif > > This way by default I will always supply definition for the > function, unless > user is willing to suply different one. I imagine that would work unless they already use boost assert and define it in their own code for logging purposes. Perhaps something along the lines of boost assert for boost test?

1 0

Re: [Boost-users] [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Wednesday, August 24, 2005 9:51 AM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [Test] Asserting a failure > Importance: Low > > > > cannot find one. All I see are macros that assert > successes, and those > > that > > assert exceptions. But my particular function does not > throw, it simply > > "assert()"s. > > I do not know reliable/portable way to intercept an assert > invocation. So > you are on your own here. If you know any hooks to do the > job, I am open to > suggestions. Try replacing your asserts with BOOST_ASSERT which can be a passive assert depending on how you use it. http://www.boost.org/libs/utility/assert.html

2 1

Re: [Boost-users] [1.33][ptr_container] bug in erase() in associative containers?
by JOAQUIN LOPEZ MU?Z 24 Aug '05

24 Aug '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.aau.dk> Fecha: Miércoles, Agosto 24, 2005 6:05 pm Asunto: Re: [Boost-users] [1.33][ptr_container] bug inerase() inassociativecontainers? > > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote in message > news:1553a314f2df.14f2df1553a3@tid.es... > > > size_type erase( const key_type& x ) // nothrow > > > { > > > BOOST_ASSERT( !this->empty() ); > > Why the BOOST_ASSERT? Do you require that the container > be non-empty for erase to be callable? Am I missing something? > > >>>>>> > > Hm...I couldn't find anything on this in the standard. Can you > locate the > description for map<K,V>::erase( const K&) ? > In 23.1.2 [lib.associative.reqmts], the table has an entry for the expression "a.erase(k)" saying: "erases all the elements in the container with key equivalent to k. returns the number of erased elements." No precondition is stated that "a" should be nonempty, neither in the table itself nor in the general requisites for the table (23.1.2/7), hence "a" is allowed to be empty. I've taken a closer look at your code and think there are some more of these overzealous asserts: * The following in associative_ptr_container.hpp iterator erase( iterator first, iterator last ) // nothrow { BOOST_ASSERT( !this->empty() ); requires again that the container be nonempty. There's no such precondition in the std for the expression "a.erase(q1,q2)": the only requisite in 23.1.2/7 is that [q1, q2) be a valid range, which is compatible with "a" being empty if q1==q2==a.end() (see 24.1/7, see also DR151 which addresses an issue with the original erroneous requirement that q1 be dereferenceable). * Same problem as above in reversible_ptr_container.hpp. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [Boost-users] [bjam] [v1] How to copy the generated binaries from a dependent project?
by Ames Andreas 24 Aug '05

24 Aug '05

Hi, many thanks for your help. Rene Rivera wrote: > Hm, for 1.33 I see a "stage" target in the signals/build/Jamfile. You are right. What doesn't fit my use case is that, at least I believe so, I can't specify the destination directory there. It always copies the binaries to toplevel/stage/lib. My statement was misleading here, sorry. > Similarly for BBv1 it's: > > stage my_stage > : <dll>@boost/libs/signals/build/boost_signals > <lib>@boost/libs/signals/build/boost_signals > ; > > It requires that you add definition of "boost" to your Jamrules file: > > project boost : _path_to_boost_ ; Aah, that's exactly what I needed to get started. With a bit of additional boilerplate it does what I want. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com

1 0

[Test] Asserting a failure
by Mike 24 Aug '05

24 Aug '05

Hi. Is there a way inside a test case using the Unit Testing Framework to specify that a particular function call ought to fail? For example, I have a function that asserts when passed invalid input. In my test case I want to pass it an invalid parameter and check that the assert is triggered. I'm looking for a macro called BOOST_CHECK_FAILURE (or something like that), but cannot find one. All I see are macros that assert successes, and those that assert exceptions. But my particular function does not throw, it simply "assert()"s. Any ideas? Thanks, Mike

2 1

Re: [Boost-users] [bjam] [v1] How to copy the generated binaries from a dependent project?
by Ames Andreas 24 Aug '05

24 Aug '05

Hi, Vladimir Prus wrote: > I know your message talks about V1, but with V2 this is a simple as: > > install install-boost-libs-you-want > : <path-to-boost>/libs/signals/build//boost_signals > : <location>some-directory > ; > > for multiple variants: > > install install-boost-libs-you-want > : <path-to-boost>/libs/signals/build//boost_signals/<variant>release > <path-to-boost>/libs/signals/build//boost_signals/<variant>debug > : <location>some-directory > ; Thanks for the hint. I have tried it out with the Boost.Buildv2 that ships with 1.33.0 but unfortunately there were some problems: 1) examples/echo doesn't build at all 2) boost toplevel doesn't build because of an issue in iostreams 3) boost/libs/signals builds only a single subvariant and I couldn't figure out how to build all the others 4) contrary to v1 when I build in a subproject (like signals) v2 seems to always complain about missing python, ICU etc. Unless these are grave failures on my part (I've followed the documentation on boost.org which seems to be a bit outdated) I will presumably stay with v1 and more so because Rene Rivera provided me the clue I needed to get going. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com

1 0

[1.33][ptr_container] bug in erase() in associative containers?
by Malte Clasen 24 Aug '05

24 Aug '05

Hi, the erase() method (defined in associative_ptr_container.hpp, line 104) seems a bit strange: size_type erase( const key_type& x ) // nothrow { BOOST_ASSERT( !this->empty() ); iterator i = find( x ); // nothrow if( i == this->end() ) // nothrow return 0; // nothrow this->remove( i ); // nothrow return this->c_private().erase( i.base() ); // nothrow } http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/ptr_container/detai… My compiler (vc++7.1) complained about the unknown find() when I called erase() on ptr_map. "find" is not declared neither in this class nor in its base class. The closest valid call I could think of would be this->c_private().find( x ) . But there seems to be a nicer solution: size_type erase( const key_type& x ) // nothrow { BOOST_ASSERT( !this->empty() ); return this->c_private().erase( x ); // nothrow } This compiles fine and does just what I want it to do, even nothrow is guaranteed (I checked the vc++ reference for std::map). Now I wonder why erase() is implemented differently in Boost 1.33. Is there anything I overlooked? Btw, is there a rationale for the declaration of insert()? std::pair<iterator,bool> insert( key_type& k, value_type x ); http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/ptr_container/ptr_m… Passing key_type by non-const reference caused some unaesthetic constructs in my code because return values (temporaries) cannot be used directly. Malte

2 2