- Boost - lists.boost.org

Re: [boost] Nested Boost Binds
by Sergey Lukin 13 Feb '06

13 Feb '06

Peter Dimov replied: > > t.async_wait(boost::bind(Component::Method1, &y, 10, boost::bind > > (DPC::Print1, &x, 2), &t)); > > You need to prevent the inner bind from being treated as a subexpression of > the outer bind. Either assign it to a function<>: > > boost::function<void()> f = boost::bind( DPC::Print1, &x, 2 ); > t.async_wait( boost::bind( Component::Method1, &y, 10, f ) ); > or use boost::protect, as explained at the end of > > http://boost.org/libs/bind/bind.html#nested_binds I tried both suggested solutions but still have the same errors boost::function<void(int)> f = boost::bind( DPC::Print1, &x, 2 ); t.async_wait( boost::bind( Component::Method1, &y, 10, f, &t ) ); or t.async_wait( boost::bind( Component::Method1, &y, 10, boost::protect(f), &t ) ); It seems like boost::protect does not not affect this expression at all. Maybe I'm doing something wrong. Thank you in advance, Sergey

3 4

[website] When will the new website be ready?
by Rene Rivera 13 Feb '06

13 Feb '06

David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: > >> In the new website structure and functioning it would be >> possible to do exactly what meta-comm does but directly on the >> website. > > Wonderful. I really like what I've seen of that so far. Do you have > an ETA for that new website structure, BTW? (ducks and covers) LOL; Loads, aims, shoots... request for help. It would go much faster if I had help in translating the existing content to the new site. And of course help in any new content. I just finished a new set of tweaks to the style from all the recent feedback I could remember. And also fixed the docs charset problem. With that, much of the detailed style work is done. Just a few small things to do. But I think it's ready for other people to help in adding content. So here's the request... If people want to volunteer, it only needs access to CVS, a text editor, and HTMLtidy. If you are intereted contact me. And for those that don't know, the new site design is at <http://boost.redshift-software.com/>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

9 15

[testing] QCC causing huge numbers of failures
by David Abrahams 13 Feb '06

13 Feb '06

It looks like QCC got added to the regression system and now I am getting huge regression reports with the Python library failing every test. I'm going to ramble here, because I don't really know what or who to lash out at ;). So apologies in advance if it seems like I'm firing indiscriminately. I hope we can ultimately make things better. With all due gratitude to Doug for setting it up, I have a hard time not concluding that there's something wrong with the regression nanny system. The psychological impact seems misdirected. I think the goal is that a sudden crop of failures showing up in my mailbox should be seen as a problem I need to address. Too often, though, there's nothing I can do about such failures and they get ignored. In this case, it's just really annoying. These aren't regressions because Boost.Python never worked with QNX in the past. Why am I getting these reports? Shouldn't whoever enabled these tests have done something to ensure that they wouldn't cause this to happen to "innocent" developers? -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 5

vc6/7 for 1.34?
by David Abrahams 13 Feb '06

13 Feb '06

Is anyone planning to start running tests on these compilers? If not we will have effectively dropped support for them for 1.34. Since I am opposed to dropping support without giving one release worth of warning, I am prepared to start running the tests if necessary. I'd like to have the remove_xxx function hacks put in if possible, *before* support gets dropped. Maybe, to cover people that have to target oddball embedded processors running WinCE and can't pay to have G++ customized, we ought to get the vc6-supporting parts of Boost running as well as possible before we drop support. That would imply one more release cycle to take advantage of remove_xxx working before that happens. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[bjam] New location!
by Rene Rivera 13 Feb '06

13 Feb '06

With the new release I've moved the location of the bjam source to: root/tools/jam/src This is to make it follow the usual Boost structure. It also hopefully removes the confusion between Boost.Build and Boost.Jam. I've adjusted all the various references to jam_src I could find. But for those that rely on the old location please change your references ASAP. My plan is to delete from CVS the jam_src location in about 48 hours. NOTE: I haven't been able to commit the root/configure script changes because there seems to be a stale CVS lock from Daniel Wallin at the root. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 2

[bjam] Boost Jam 3.1.12 release.
by Rene Rivera 12 Feb '06

12 Feb '06

Like the subject says, Boost Jam 3.1.12 is available on the SourceForge release system: <https://sourceforge.net/project/showfiles.php?group_id=7586&package_id=7294…>. This should be the bjam used for the next Boost release. Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

1 0

Re: [boost] vc6/7 for 1.34?
by JOAQUIN LOPEZ MU?Z 12 Feb '06

12 Feb '06

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Febrero 12, 2006 5:59 pm Asunto: [boost] vc6/7 for 1.34? > > Is anyone planning to start running tests on these compilers? If not > we will have effectively dropped support for them for 1.34. Since I > am opposed to dropping support without giving one release worth of > warning, I am prepared to start running the tests if necessary. Please do so. It was my understanding that metacom tests were going to include vc 6.5/7.0 (see http://lists.boost.org/Archives/boost/2006/01/99844.php) but for some reason they're not finally there. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[call traits] BCB workaround and updated version check
by AlisdairM 12 Feb '06

12 Feb '06

The following patch solves the bad array type being picked up in the call_traits tests, leaving one test unsolved. It also confirms the workarounds are still needed for BCB2006. Note the minor case of switching order of T and const. This is due to a bug I only fully appreciated today. depending on order of add_const and add_ref, BCB will deduce 2 *different* types. int const & int & const The latter does not sound like a 'real' type to me, so I suggest always placing const before the type, rather than after, when dealing with template type-parameters - unless we have cases where this makes a real difference for conforming compilers. Rest of the patch should be straightforward. AlisdairM cvs diff -u -wb -- boost\detail\call_traits.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/detail/call_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/call_traits.hpp,v retrieving revision 1.15 diff -u -w -b -r1.15 call_traits.hpp --- boost/detail/call_traits.hpp 12 Aug 2005 19:06:10 -0000 1.15 +++ boost/detail/call_traits.hpp 12 Feb 2006 13:23:16 -0000 @@ -58,7 +58,7 @@ template <typename T, bool b1> struct ct_imp<T, true, b1> { - typedef T const param_type; + typedef const T param_type; }; } @@ -92,7 +92,7 @@ typedef T& param_type; // hh removed const }; -#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x570 ) ) +#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x581 ) ) // these are illegal specialisations; cv-qualifies applied to // references have no effect according to [8.3.2p1], // C++ Builder requires them though as it treats cv-qualified @@ -121,6 +121,15 @@ typedef const T& const_reference; typedef T& param_type; // hh removed const }; + +template <typename T> +struct call_traits< T * > +{ + typedef T * value_type; + typedef T * & reference; + typedef T * const & const_reference; + typedef T * const param_type; // hh removed const +}; #endif #if !defined(BOOST_NO_ARRAY_TYPE_SPECIALIZATIONS) template <typename T, std::size_t N> -- AlisdairM

2 2

[call traits] expected errors not detected for BCB
by AlisdairM 12 Feb '06

12 Feb '06

The call_traits test expects 2 errors from BCB, yet is counting none. Hence the failing test-case. When I look at the output, I still see 2 failing tests. What I can't work out is how these tests are supposed to increment the failed test count. And that makes me wonder if a platform expecting 0 failures started failing, would it show up? -- AlisdairM

2 1

bcp: towards a library dependency list
by John Maddock 12 Feb '06

12 Feb '06

I've just committed some changes to bcp that give it a shortened list option: bcp --list-short truncates the list so you just see directory names where appropriate, for example: bcp --list-short shared_ptr.hpp Gives the dependency list: boost/assert.hpp boost/checked_delete.hpp boost/config.hpp boost/config boost/current_function.hpp boost/detail boost/mpl boost/non_type.hpp boost/preprocessor boost/shared_ptr.hpp boost/static_assert.hpp boost/throw_exception.hpp boost/type.hpp boost/type_traits boost/version.hpp which is reasonably nice and compact :-) Now, here's the question: what did the folks who were asking for this functionality actually want to use the information for? I should stress that it's overkill for extracting subsets of Boost, because many libraries will depend on just one or two files inside boost/mpl or boost/preprocessor, so using the list for that purpose will result in an even "thicker" dependency than copying with bcp already produces. It's possible to contract the above list even further: for example by contracting to library names where possible, so for example contracting all of: boost/regex.hpp boost/regex libs/regex to just "regex" However there would still be a lot of Boost headers that can't automatically be assigned to any library name, so it's not clear to me how much use this would be? If folks can give me an idea of what they were looking to use a dependency list for it'll help me decide whether to stop here or to continue trying to contract the list further. John.

8 9