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

[variant] passing visitors to apply_visitor()
by Yuval Ronen 23 Jun '05

23 Jun '05

Hi. When I want to apply a visitor to a variant, I currently have 2 choices: boost::apply_visitor( my_visitor(), my_variant ); and my_visitor mv; my_variant.apply_visitor( mv ); A tempting 3rd choice of my_variant.apply_visitor( my_visitor() ); doesn't work because the variant::apply_visitor member function accept a const visitor ref, which means it can't be a temporary object. Moreover, the first option (boost::apply_visitor freestanding function) also has a problem - it only accepts non-const variants. I'm not really sure, but I guess that all these limitation are originated from the desire to pass the visitor by ref, and it's not always possible to provide both const-ref and non-const-ref overloads. My question is: why by reference and not by value? I see visitors as a kind of function objects, and I think that's how it was meant to be seen. Function objects are usually passed by value, so why should visitors be any different? I couldn't find anything relevant to this in the docs. Passing by value will allow the much more appealing syntax I presented as the 3rd option, and it will remove the limitation from the freestanding function. Makes sense or complete nonsense? Thanks, Yuval

1 0

[Boost-bugs] [ boost-Bugs-1226292 ] Spelling of Edmonds-Karp-Algorithm
by SourceForge.net 23 Jun '05

23 Jun '05

Bugs item #1226292, was opened at 2005-06-23 07:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1226292&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: Spelling of Edmonds-Karp-Algorithm Initial Comment: Hi, I know it has been asked on the boost list before, but not answered: any chance to change all occurences of "edmunds_karp" into "edmonds_karp"? I am pretty sure Jack Edmonds would appreciate it ... Its just much easier to find if spelled correctly. Regards, Matthias (peinhardt AT zib.de) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1226292&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

como build problems
by Robert Ramey 23 Jun '05

23 Jun '05

Some time ago my bjam/comeau set up ceased to function. I get messages like: C++ prelinker: executing: c:\Program Files\como433\bin\como --vc71 -e5 --no_vers ion --no_prelink_verbose --display_error_number --long_long --diag_suppress= 9,21 ,161,748,940,962 -D__STL_LONG_LONG -DNDEBUG -DNDEBUG -DBOOST_LIB_DIAGNOSTIC= 1 -- a -DBOOST_COMO_STRICT=1 --inlining -D_WIN32 -DBOOST_SP_DISABLE_THREADS --exc epti ons -DBOOST_DISABLE_WIN32 --wchar_t -I..\..\..\bin\boost\libs\serialization\ buil d -Ic:\Program Files\como433\libcomo c:\Program Files\como433\libcomo\cnames -IC :\BoostMainCVS -IC:\BoostMainCVS -IC:\BoostMainCVS -o ..\..\..\bin\boost\libs\se rialization\build\libboost_serialization.lib\como-4_3_3-vc7_1\release\binary _oar chive.obj -c ../src/binary_oarchive.cpp 'c:\Program' is not recognized as an internal or external command, operable program or batch file. My como path variable is set: COMO_PATH="c:\\Program Files\\como433" I also tried COMO_PATH="c:/Program Files/como433" but it made no differenc I didn't change anything as far as I know. Does anyone have any suggestions? Robert Ramey

6 11

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