- Boost - lists.boost.org

[type_traits] Preliminary patch to work around GCC Bug 8503 and a minor feature request
by Tobias Schwinger 23 Jun '05

23 Jun '05

Hi Boosters/John, GCC Bug 8503 ------------ during the Function Types review there was a report about GCC 3.2 warnings "volatile qualified function" (remove_cv on a function). It seems it's http://gcc.gnu.org/bugzilla/show_bug.cgi?8503. According to the GCC-Bugzilla, John's watching it - probably even the reporter. However, it seems it's currently not addressed by TypeTraits, so I wrote a preliminary patch to work around it (see attached file). Thanks to Jody Hadins for helping tracking it. is_aggregate == "is_class_or_union" ------------------------------------ Not that I currently need it -- but shouldn't there be a public one like this, at least for completeness ? Btw. great new documentation! Regards, Tobias Index: boost/type_traits/detail/cv_traits_impl.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/detail/cv_traits_impl.hpp,v retrieving revision 1.3 diff -u -r1.3 cv_traits_impl.hpp --- boost/type_traits/detail/cv_traits_impl.hpp 3 Dec 2003 13:32:56 -0000 1.3 +++ boost/type_traits/detail/cv_traits_impl.hpp 19 Jun 2005 15:06:19 -0000 @@ -12,13 +12,22 @@ #define BOOST_TT_DETAIL_CV_TRAITS_IMPL_HPP_INCLUDED #include "boost/config.hpp" +#include "boost/detail/workaround.hpp" #ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION +// implementation helper: + + +#if BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__,<= 2) +#include "boost/type_traits/detail/yes_no_type.hpp" namespace boost { namespace detail { - -// implementation helper: +namespace type_traits { +#else +namespace boost { +namespace detail { +#endif template <typename T> struct cv_traits_imp {}; @@ -54,6 +63,29 @@ typedef T unqualified_type; }; +#if BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) +// We have to exclude function pointers +// (see http://gcc.gnu.org/bugzilla/show_bug.cgi?8503) +::boost::type_traits::yes_type mini_funcptr_tester(...); +::boost::type_traits::no_type mini_funcptr_tester(const volatile void*); + +} // namespace type_traits + +// Use the implementation above for non function pointers +template <typename T, unsigned Select + = (unsigned)sizeof(boost::detail::type_traits::mini_funcptr_tester((T)0)) > +struct cv_traits_imp : boost::detail::type_traits::cv_traits_imp<T> { }; + +// Functions are never cv-qualified +template <typename T> struct cv_traits_imp<T*,1> +{ + BOOST_STATIC_CONSTANT(bool, is_const = false); + BOOST_STATIC_CONSTANT(bool, is_volatile = false); + typedef T unqualified_type; +}; + +#endif + } // namespace detail } // namespace boost

2 4

DECOMSYS is using Boost
by Klaus Nowikow 23 Jun '05

23 Jun '05

- Name: DECOMSYS::DESIGNER PRO - Company: DECOMSYS (http://www.decomsys.com/) - Product description: DECOMSYS::DESIGNER PRO enables the user to design a highly complex FlexRay (http://www.flexray.com/) communication system, which is going to be the fundament for tomorrow's automotive electronics. - Boost Libraries used: - bind (I use this almost automatically), - dynamic_bitset, - format, - function, - iterators, - mpl (makes some of my colleagues nervous ;-) ), - multi_index, - noncopyable, - operators, - preprocessor (nice for generating data for unit tests) - program_options (for the unit test programs) - ref - regex - serialization - signals - smart_ptr - spirit - timer - variant We are also planning to use Andreas Huber's fsm library (whatever the name will be) and iostreams (together with boost.serialize) once they are officially released. And maybe boost.python. Best regards, Klaus -- Klaus Nowikow DECOMSYS - Dependable Computer Systems Development Engineer Stumpergasse 48/14, A-1060 Wien, Austria Phone: +43 1 59983-31 Fax: +43 1 59983-731 mailto:nowikow@decomsys.com http://www.decomsys.com

1 0

[1.33.0] Release status
by Doug Gregor 22 Jun '05

22 Jun '05

After a rocky week, we're starting to see some real progress in the regression tests. Many of the failures are regression tester configuration issues that we're working out, although there are still a bunch of real regressions there. Let's keep on fixing those bugs, and with any luck will be able to release sooner rather than later. Doug

1 0

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