February 2006 - Boost - lists.preview.boost.org

[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

decltype, LVALUE_TYPEOF, and binding a reference
by Arkadiy Vertleyb 12 Feb '06

12 Feb '06

Hi all. The primary purpose of decltype, according to the decltype/auto proposal, seems to be to assist in creation forwarding functions, something like: template<class F> decltype(F()()) forward(F f) { return f(); } For example, if f is declared to return const rvalue: const x f(); using the real decltype (in the future, of course) would result in: const x forward(const x(*)()) { return f(); } Which is, of course, what we expect in this case. Since LVALUE_TYPEOF has a problem distinguishing const x from const x&, using it in the above case would result in: const x& forward(const x(*)()) { ^^^^^^^ return f(); } Now, my question is: isn't this fine? The same rule (extending the lifetime of const reference) that prevented LVALUE_TYPEOF from working correctly, seems to now ensure that it is fine to use this "incorrect" result. Another example of (it seems) the same thing is the treatment of "volatile" by Microsoft compilers (both 7.1 and 8.0). It seems to be fine to write: volatile x vf(); volatile x& vr = vf(); provided x is a UDT, and has a copy-constructor accepting [const] volatile x&. (I don't know if this is a compiler bug, or the lifetime is also extended. I also don't know if this standard-compliant.) Needless to say, LVALUE_TYPEOF(vf()) yields volatile x& instead of expected volatile x (my local version, after adding the treatment for volatiles). If x is not a UDT, the above binding doesn't work, but LVALUE_TYPEOF(vf()), guided by the same exact mechanism, would also yield just x. Let's generalize a bit. When writing a forwarding function, shouldn't we, instead of asking: what is the exact return type of the wrapped function? just ask: what is the type to which the result of the wrapped function can be bound without loosing functionality [on this particular compiler]? It seems to me that using the simple mechanism of binding a reference yelds the results that are at least as good (for this particulat purpose, of course) as those that the real decltype could provide... But maybe I am missing something? Regards, Arkadiy

4 6

Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin
by JOAQUIN LOPEZ MU?Z 12 Feb '06

12 Feb '06

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Febrero 11, 2006 10:26 pm Asunto: Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin > JOAQUIN LOPEZ MU?Z wrote: [...] > > > > #include <boost/serialization/nvp.hpp> > > // rest of serialization headers which must not trigger autolink > > #include <...> > > > > // declare some function of the serialization > > // lib (which shouldn't be linked) > > > > int some_f(); > > > > int main() > > { > > // use the function in whatever manner > > int x=some_f(); > > } > > > > Now, if autolink does not get activated, the > > program should fail as some_f is not linked in. > > So, in your Jamfile just mark this as a link-fail: > > > > [ link-fail auto_link_not_invoked.cpp ] > > > I didn't know about link-fail - but I'm still missing something here. > > If I refer to a function that is declared in one of my headers - then > auto-linking will be triggered. It doesn't matter whether this > reference occurs by taking its address or by invoking it by name. > I'm afraid I don't agree here --linkers are not that smart, in fact autolinking is triggered by the appropriate #pragmas only, when you include some header that have those. It doesn't have anything to do with whether the symbols of the lib are used or not. What I propose is that you declare some symbol of the lib *without* using the associate header, which would trigger autolinking. For instance (I haven't actually tested this): // all the serialization headers which mustn't trigger autolink #include <....> // unregister_void_casts is defined by the serialization lib. namespace boost { namespace serialization { class BOOST_SERIALIZATION_DECL(BOOST_PP_EMPTY()) extended_type_info; void BOOST_SERIALIZATION_DECL(BOOST_PP_EMPTY()) unregister_void_casts(extended_type_info *eti); } /* serialization */ } /* boost */ int main() { using namespace boost::serialization; typedef void BOOST_SERIALIZATION_DECL(BOOST_PP_EMPTY()) (* unregister_void_casts_type)(extended_type_info *); unregister_void_casts_type pf=&unregister_void_casts; return 0; } Only when the serialization lib is linked in can this program build OK --so, when autolinking has not been spuriously activated the expected outcome is link failure. > Now I "think" bjam sets up a path to the directory that contains > my pre-built boost libraries - so the reference will be found > and and the program will link. Its not clear to me that I can > suppress this and guarentee that the link will fail. > My comment above applies: autolinking is a #pragma thing, nothing to do with linker finding dangling symbol references --unless I'm grossly mistaken :) Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0