- Boost - lists.boost.org

Re: [boost] [serialization] new STATIC_ASSERTION_FAILURE
by Marcin Tustin 23 Jun '05

23 Jun '05

> -----Original Message----- > From: Vladimir Prus [mailto:ghost@cs.msu.su] > Sent: 23 June 2005 06:20 > To: boost(a)lists.boost.org > Subject: Re: [boost] [serialization] new STATIC_ASSERTION_FAILURE > > Robert Ramey wrote: > > > Vladimir Prus wrote: > >> 2. Could base_object.hpp be fixed either by including the > appropriate > >> header, or in some other way. > > > > I believe this will also be correct by following the above rule. > > How? Clearly, if I include base_object.hpp in a header, I > cannot obey the above rule. Ok leaving just: > > #include <boost/serialization/access.hpp> > #include <boost/serialization/split_member.hpp> > #include <boost/serialization/base_object.hpp> > > in my header, and using the mandated includes order in .cpp > file, I still get the same error. > > What should we do next? I put the archive headers in my stdafx.h, which is a header included as the first include in every file. This ensures that the archive headers are included before the any serialization headers.

2 1

Re: [boost] Adobe Reader is using Boost
by Brian Braatz 23 Jun '05

23 Jun '05

> -----Original Message----- > On Behalf Of John Maddock > > I think we could have all guessed this anyway, but if you take a look in > the > "Patent and Legal Notices" for Adobe Reader 7, you'll find actually find a > *lot* of Open Source licences, among them being the BSL and a lot of very > familiar names. I guess that puts Boost technology (albeit indirectly) on > almost every desktop. > > Just thought you might be interested, > > John. [Brian Braatz Writes:] <bad humor> New boost slogan: "Two chickens in every pot, and a compiled meta-program on every desktop" </bad humor>

1 0

Re: [boost] McAfee is using Boost
by Brian Braatz 23 Jun '05

23 Jun '05

> On Behalf Of David Abrahams > "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> writes: > > > It is polite to ask, and perhaps politeness is wiser than legal basis. > > If an email is not answered, it could be surmised that they don't care; > > otherwise, their preferences should be obvious. > > > > <http://www.adobe.com/aboutadobe/pressroom/prcontacts.jsp> > > 1. Adobe and McAfee are not related, are they? > > 2. It's not worth anyone else's time to ask, IMO. Are you > volunteering your own time? > > 3. I'd just say "go ahead," but I know how these things work in > companies. The question to the PR department triggers a discussion > with the legal department and they both decide it would be safer > for the company if their use of open source software were not > publicized. The job of PR and legal is to limit the company's > exposure to risk, so once something shows up on their radar it > becomes something for the company to worry about. On the other > hand, if the question never arrives, it never becomes a problem. > > Let's not make a big production out of this. > [Brian Braatz Writes:] my 2 cents: We discovered this by public knowledge that THEY provided. case closed :) If it helps, think of it this way. The "role" of the "Who's using boost" page is to "report" on who is using boost. If a TV reporter could talk about it (based on public knowledge) then we should also be able to report on it. :)

1 0

Re: [boost] Boost.config not recognize threading support enabled?
by BRIDGES Dick 23 Jun '05

23 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On > Behalf Of John Maddock > Sent: Wednesday, June 22, 2005 4:02 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost.config not recognize threading support enabled? > > > - BOOST_HAS_PTHREADS is defined in posix_features.hpp after <unistd.h> > > is included. I had hoped this was a good thing. ;) > > Yes. <snip> > Yes: for some compilers (including gcc on some platforms), just because the > platform has pthreads, and advertises it's presence in unistd.h, this does > *not* mean that the C++ compiler can generate thread aware/safe code unless > special measures are taken (a special command line option usually, for > example -mthreads on cygwin), or not at all in some cases (gcc on SGI Irix > for example). C++ compiles have to take special care when generating > exception handling and / or RTTI code that may involve hidden globals, in > order for them to be thread safe. This is not the case for C compiles, and > remember that unistd.h is a C header! > <snip> > Failing everything else, I think the way to handle this is with something > like this in libstdcpp3.hpp: > > #if defined(macro-that-identifies-linux-on-arm) && > defined(_GLIBCPP_HAVE_GTHR_DEFAULT) > #define BOOST_HAS_THREADS > #endif [Dick] My primary reservation about this approach is based upon my assumption that the "macro-that-identifies-linux-on-arm" would be an attribute of the compiler. I still can't get used to the idea that multi-threaded or single-threaded is compiled into the gcc cross-compiler itself, while little-endian and big-endian are command line switches. %>[ The multiplicity of targets and threading models might require a number of such tests that would be difficult to manage. > Any closer? [Dick] I'm of two minds about the following suggestion: it's either a kludge or introduces a certain pleasing symmetry. ;) Since BOOST_DISABLE_THREADS is used to unconditionally disable threads, the user-wielded imperative BOOST_ENABLE_THREADS (tested at the same place in suffix.hpp) would [almost] unconditionally define BOOST_HAS_THREADS - subject only to the existing verification that the threading API has been identified and is recognized. For compilers that do not provide detectable compile-time indications that threading is enabled, this seems to me to be a fairly straight-forward and minimally invasive adaptation. Although this puts the onus on the user, it does have the advantage of being independent of the target and potentially stable. > John. > [Dick] Regards, Dick

2 1

[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