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

calling a member function of a map iterator
by Alexander Shyrokov 15 Sep '06

15 Sep '06

I have a map<int,c*> and I would like to call a member function of the c* and provide a parameter to it. struct c{void f(char*){}}; typedef std::map<int,c*> TMap; TMap a; std::for_each(a.begin(),a.end(),boost::bind(&c::f,boost::bind(&TMap::value_type::second,_1)),NULL); I get "error C2091: function returns function" This is what I would like to replace with the for_each algorithm: for(TMap::iterator i=a.begin();i!=a.end();++i)(*i)->f(NULL); Thanks. -- Regards, Alexander. http://sjcomp.com

2 5

Re: [Boost-users] Comments / Advice on using Boost Test Library
by Sohail Somani 15 Sep '06

15 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Dave Steffen > > I just wonder: whats the big deal with breaking all the > encapsulation > > rules to do unit tests? > > Do you mean: > "why are people breaking encapsulation rules for unit tests?" > or > "why do people worry about breaking encapsulation rules > for unit tests?" Second one. I was worried for a second there that there was something I hadn't thought about :) Thanks.

1 0

Re: [Boost-users] Comments / Advice on using Boost Test Library
by Sohail Somani 15 Sep '06

15 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Aubrey, Jason > Note1: I've no idea if a formal name for this pattern exists, > if not it > does now :) > Note2: I recognize the security issues with this; however, if > it's truly > an issue I suppose the pImpl (i.e. pointer to implementation) > idiom can > be used in tandom so things are truly private from the client. I just wonder: whats the big deal with breaking all the encapsulation rules to do unit tests?

2 1

bind, and member function with a parameter
by Alexander Shyrokov 15 Sep '06

15 Sep '06

I want to call a member function with a parameter from within an algorithm. http://boost.org/libs/bind/bind.html#with_algorithms gives an example: void animation::advance(int ms); std::vector<animation> anims; std::for_each(anims.begin(), anims.end(), boost::bind(&animation::advance, _1, ms)); I am using boost::lambda:: before _1. I get an error error C2825: 'F::result_type': cannot form a qualified name I am using MS VC7.1 and boost_1_33_1 Any ideas why this does not work? Thanks.

5 13

Comments / Advice on using Boost Test Library
by Dave Steffen 15 Sep '06

15 Sep '06

Hi Folks, We've been happy Boost Test Library customers for over a year now, slowly building up a set of unit tests for a large legacy code base. There's no question that it's Good Stuff. Specifically, everything we do is some variation on a BOOST_AUTO_UNIT_TEST-y sort of thing; the extremely low amount of "typing overhead" is a big part of why so many people are writing unit tests (these unit tests are cheap, as unit tests should be). What I'd like to ask the Boost community about is this: how to go about unit testing private class methods. One answer is "don't; only unit test the public interface", which is fine as far as it goes. However, most of our work is extremely mathematical, so it's not uncommon to see something like class Base { ... public interface, etc ...}; class Derived : public Base { public: ... goodies in here ... private: double HelperFn1(); bool HelperFn2(int, double, KalmanFilter&); }; where HelperFn1 and HelperFn2 are extremely non-trivial mathematical operations. Yes, exercising the public interface will signal mistakes in the helper functions, but can't do much to poke at them in depth, or help pinpoint exactly what chunk of math isn't right. What we want is to be able to write unit tests that poke and prod such private member functions directly. Another answer is "give your class a friend "tester" class, that uses its frienship to give the unit tests access to the class' guts". We've been doing that for about a year now; not the most elegant, but an effective solution. Unfortunately, it doesn't work for the thing I wrote this afternoon; I'll skip the details. Another horrible, but effective, possibility is to #define private public #include "ClassToTest.h" ... (only in the unit test suites!) and muck about in the class's guts directly. This is the only way I know of to get into the rather complicated template-class-heirarchy-interface-wrapper thing that I just built. What kinds of techniques are you all using out there? Thanks very much for any comments! ---------------------------------------------------------------------- Dave Steffen, Ph.D. Software Engineer IV Disobey this command! Numerica Corporation ph (970) 419-8343 x27 fax (970) 223-6797 - Douglas Hofstadter dgsteffen(a)numerica.us

5 4

Re: [Boost-users] Writing a more readable code
by Nat Goodspeed 15 Sep '06

15 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of me22 > Sent: Friday, September 15, 2006 2:55 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Writing a more readable code > > use an iterator adapter that returns base_itr->second when > dereferenced. I hear that it's simple to make one with > Boost.Iterator. > > You'd then just do > std::for_each( seconder(a.begin()), seconder(a.end()), boost::bind(f,_1) > ); [Nat] The need to adapt each of a.begin() and a.end() bothers me. (I've dealt with similar but more complex situations.) Is there a nice way to combine Boost.Iterator adaptors with Boost.Range to express this less redundantly?

1 0

Re: [Boost-users] Comments / Advice on using Boost Test Library
by Sohail Somani 15 Sep '06

15 Sep '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Dave Steffen > > This is permissable in unit tests, I would think. > > Yes, this is one of the alternate approaches I've been considering. > We've got the "Bad" and the "Ugly". I'm still hoping the "Good" is > out there somewhere... :-) I'm pretty sure those are the only approaches, but I'd be glad to find a more obvious way that isn't intrusive.

1 0

Re: [Boost-users] [serialization] serialization of pointers toprimitive types?
by JOAQUIN LOPEZ MU?Z 15 Sep '06

15 Sep '06

Hi Volodya ----- Mensaje original ----- De: Vladimir Prus <ghost(a)cs.msu.su> Fecha: Viernes, Septiembre 15, 2006 6:19 pm Asunto: Re: [Boost-users] [serialization] serialization of pointers toprimitive types? > Joaquín Mª López Muñoz wrote: > > > The following test program: > > > > #include <boost/archive/text_oarchive.hpp> > > #include <sstream> > > > > int main() > > { > > int x=0; > > int* const px=&x; > > std::ostringstream oss; > > boost::archive::text_oarchive oa(oss); > > oa<<px; > > > > return 0; > > } > .... > > I've checked the same snippet against Boost 1.33.1, CVS HEAD and > > RC_1_34_0, using other primitive types like std::string, same > > problem always. Same problem also for the loading counterpart. > > When the pointed-to type is not primitive, though, everything > > works fine, regardless of whether the type has intrusive or non > > intrusive serialization support. > > > > I am sure I'm doing something really stupid here, but I've been > > banging my head against this several hours. Some clue greatly > > appreciated. > > This never worked, I think. The problem is that if you're saving > pointers,you need to check if you've already saved that pointer, > so that on loading, > you don't get two pointers to to ints, as opposed to two pointers > to a > single int, as it should be. > > This "tracking" requires runtime map, and I believe Robert decided > thatmaintaining such map for primitive type can be too expensive. > I'm not sure > how valid that point it, not how many hidden stones there are in > enablingprimitive types to be tracked. I know primitive types are not tracked, but I take that to mean that multiple pointers to the same object will result in duplicated copies in the archive, *not* that serializing a pointer will result in a compile error. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[shmem] leaving shared objects in memory
by Pataki Szilard 15 Sep '06

15 Sep '06

Hello! Can anybody tell me how can I make the shared memory segment (together with the objects constructed in it) remain in memory AFTER the process which created it terminates? E.g. Proc1 creates the segment and the objects in it. Proc2 accesses the segment and operates on the shared objects. Proc1 might get killed and I don't want this event to affect in any way Proc2. Thanks and regards, Szilard

2 1

shared_ptr without rtti
by Michael Marcin 15 Sep '06

15 Sep '06

Using WinARM version 20060606 (gcc 4.1.1) compiling with -fno-rtti gives: 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp: In member function 'virtual void* boost::detail::sp_counted_impl_pd<P, D>::get_deleter(const std::type_info&)': 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp(150): error: cannot use typeid with -fno-rtti 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp: In member function 'virtual void* boost::detail::sp_counted_impl_pda<P, D, A>::get_deleter(const std::type_info&)': 1>..\..\sdk\boost\inc/boost/detail/sp_counted_impl.hpp(220): error: cannot use typeid with -fno-rtti 1>..\..\sdk\boost\inc/boost/shared_ptr.hpp: In function 'D* boost::get_deleter(const boost::shared_ptr<U>&)': 1>..\..\sdk\boost\inc/boost/shared_ptr.hpp(540): error: cannot use typeid with -fno-rtti I thought typeid can work at compile-time without rtti (seems to for msvc8) but I guess not. Any ideas? -- Michael Marcin Method Solutions, Programmer

2 4