June 2005 - Boost - lists.preview.boost.org

Proposal: boost.tuple +=
by Vadim Alexandrov 22 Jun '05

22 Jun '05

Hi, I am using boost::tuple to accumulate results of computations. I think, supplying operator += (-=) as operator += for each member will be nice. Example: tuple< int, string> abc( 3, "abc" ), de( 2, "de"); abc += de; assert( abc.get<0>() == 5 ); assert( abc.get<1>() == "abcde" );

1 0

[Signals] Recursive callback design questions, including socket multiplexor implementation example
by Cliff Green 22 Jun '05

22 Jun '05

I have a socket multiplexor library, with a fundamental design question relating to Boost.Signals. My current implementation is flawed, and I'm considering replacing the flawed code with Boost.Signals (that is, when the performance and multi-threading issues have been addressed). Consider the following pseudo-code (ignores lots of details and is obviously not compilable - however, I do have real working code similar to this example): class Msg { ... }; class SocketStream { void sendMsg(Msg); // ... }; class Multiplexor; // forward declaration typedef boost:function<void (Msg&, Multiplexor&, SocketStream&)> IncomingMsgCallback; class Multiplexor { void registerIncomingMsgCallback (IncomingMsgCallback); void unregisterIncomingMsgCallback (IncomingMsgCallback); // ... }; A Multiplexor object has a container of callback "IncomingMsgCallback") objects which are invoked whenever an incoming message is received on a socket stream. Within the callback, a "context" is provided (reference to the enclosing Multiplexor object) for performance and ease of use. (Even if this particular callback interface did not provide a Multiplexor context, nothing would prevent the application from storing one in the callback object itself.) From within the callback invocation, additional callback objects may be registered or unregistered. (This is actually a fairly common use case - the registration of callback functionality implements application state machines, which are transitioned based on incoming messages.) The design issue is that modifying the callback container from within the callback invocation (i.e. calling "registerIncomingMsgCallback") requires some tricky guarding and managing of the internal callback container. In effect, register and unregister requests are placed on a queue, and then applied when events (messages) are not causing the callbacks to be invoked. I've found that I've duplicated this code in multiple places (primarily because there are multiple types of callbacks - e.g. incoming msg callbacks, outgoing msg callbacks, connection monitoring callbacks, periodic invocation callbacks, etc). This is Not Good, and not yet) generic. Does Boost.Signals directly address this type of use case? I've read the tutorial and examples many times, and it's still not clear to me if it does (that may be due to my understanding versus the documentation itself). Is the trackable functionality meant to address this type of use? If not, has this kind of usage been considered as relevant or desirable for Signals? I'm willing to help enhance, within the constraints of my available time. If Boost.Signals should not support this type of usage (i.e. modifying the signal, indirectly, from within a connected slot), is it worthwhile to create a generic container to support this functionality? Or are my assumptions and approaches way off base, and I should be considering other alternatives? (I haven't described every possibility that I considered during design ...) Thoughts and comments are greatly appreciated! Cliff

2 1

Re: [boost] shared_ptr question
by Martin Bonner 22 Jun '05

22 Jun '05

----Original Message---- From: H. van Niekerk [mailto:h.v.niekerk@hccnet.nl] Sent: 20 June 2005 19:22 To: boost(a)lists.boost.org Subject: [boost] shared_ptr question > Hi, > > I'm rather new to shared_ptr and I'm not very experienced in > programmer > with C++ but have to do it anyway. > My problem is this: I have 3 .cpp files, e.g. Master.cpp, Client.cpp > and Satellite.cpp. > > Originally, Master.cpp is the only .cpp file, and uses auto_ptr to > enable writing and reading from an interface. Like this: > > { > .... > auto_ptr<FtInterface> fti (ftGetIfFromFactory(device, > connection)); > fti->getIfInfo(ii); > IfOutputs out; // to set interface outputs (ctor clears > // everything to 0) > IfInputs inp; // to be read from interface > fti->writeAndReadAllData(out, inp); > ... > } > > This works well with every action taking place in this file. Now, as > said I have those 3 .cpp files. Master.cpp sends an argument to > Client.cpp and Client.cpp sends it to Satellite.cpp. Satellite.cpp > reads > from the interface, and sends it back via Client.cpp to Master.cpp. I > can't use auto_ptr with this and from the Boost-documentation I can't > figure out exactly how to use shared_ptr for this. Can somebody please > help me out? > > I hope I explained my problem clear enough. I'm afraid you didn't. Could you write some sample (pseudo-) code just using raw C pointers and not worrying about memory leaks? Then we can probably work out how to rewrite using smart pointers. Incidentally, I don't think the presence of three .cpp files is directly relevent. I suspect that the relevent factor is that you have three *functions*, and your problem is passing the data between them. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

5 12

Broken link to boost/thread/barrier.hpp on www.boost.org
by Peter Simons 22 Jun '05

22 Jun '05

If you follow the link to "barrier.hpp" on the page http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads/ref… ..., then you'll be directed to http://www.boost.org/regression-logs/cs-win32_metacomm/boost/thread/barrier… ..., and that page doesn't exist. Peter

1 0

[mpl][tru64cxx] set still failing
by Joaquín Mª López Muñoz 22 Jun '05

22 Jun '05

Hello again, Despite recent changes by Dave Abrahams, mpl::set is still failing in tru64cxx as shown in the last regression cycle: http://tinyurl.com/9qzuh (Dave's works weren't intended to tackle this issue anyway, so this comes as no surprise.) The reason for the regression lies in recent changes to the associated toolset jam setting strict_ansi mode compilation. The offending code is: BOOST_STATIC_CONSTANT(bool, value = ( sizeof( BOOST_MPL_AUX_OVERLOAD_CALL_IS_MASKED( Set , BOOST_MPL_AUX_STATIC_CAST(aux::type_wrapper<T>*, 0) ) ) == sizeof(aux::no_tag) ) ); and the error message goes like "NULL reference is not allowed". Digging deeper, I'm pretty sure the problem has to do with tru64cxx not accepting selected implementation of BOOST_MPL_AUX_PTR_TO_REF in boost/mpl/aux_/ptr_to_ref.hpp when the pointer passed is null. There are two alternative implementations of this macro: 1. (MSVC, EDG) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ *BOOST_MPL_AUX_STATIC_CAST(X*, 0) \ /**/ 2. (remaining compilers) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ aux::ptr_to_ref(BOOST_MPL_AUX_STATIC_CAST(X*, 0)) \ /**/ tru64cxx, which is EDG-based, uses #1; it used to work OK, but when strict_ansi mode was selected, the compiler didn't like #1 anymore. So my questions are: A. Is there any reason why EDG is forced to use implementation #1? The CVS history doesn't shed much light about this. B. If A is unavoidable, can we macro-detect strict ansi mode so as to divert EDG+strict_ansi to implementation #2? C. If B has negative answer, could we at least eliminate the null pointer in boost/mpl/aux_/ptr_to_ref.hpp (by using a dummy make_ptr function, perhaps)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[boost.lambda] Function invocation via lambda
by Falcon 22 Jun '05

22 Jun '05

Sorry if this has been asked before (I couldn't find anything, or else I wasn't using the right searches)... How does one create a lambda function that invokes its parameter? For example, for use with std::for_each: std::vector<boost::function0<void> > Methods; std::for_each(Methods.begin(), Methods.end(), *???*) Peregrine Falcon

2 2

boost building question
by H 22 Jun '05

22 Jun '05

Hi, In the Jamfile help it says: --builddir=DIR Build in this location instead of building within the distribution tree. Recomended! Does this mean the build is not the same as the install, i.e. while building, files are being stored somewhere and removed after final installation? Thank you, H.

2 2

[lexical_cast] specializing
by Maxim Yegorushkin 22 Jun '05

22 Jun '05

I'd like to be able to specialize lexical_cast for certain source->target conversions. With its current design I see no possibility to do that as function templates can not be partially specialized. Are the any plans to change that? -- Maxim Yegorushkin

3 6

Re: [boost] Boost::regex match prefix problem
by A. Johan 22 Jun '05

22 Jun '05

Thanks John! Will try the cvs then. Cheers. Alfonso Johan Soft Switch Sdn. Bhd. Kuala Lumpur, Malaysia http://www.softswitch.com.my -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.10/25 - Release Date: 21/06/2005

1 0

[filesystem 1.32.0] bug in name checking for win32 native paths
by Russell Hind 22 Jun '05

22 Jun '05

I have two paths, both set to c:\ and if I concatenate them using operator /, I get a resultant path of c:\c:\ which is invalid, but the namechecking doesn't throw an execption. e.g. void test(void) { boost::filesystem::path p("C:\\", boost::filesystem::native); boost::filesystem::path p2(p); p2 = p2 / p; } p2 results as "c:/c:/" (the internal representation). Cheers Russell

2 1