- Boost - lists.boost.org

Jamfile.v2 failing for several doc directories
by Larry Evans 24 Jul '04

24 Jul '04

How do I avoid the following errors? <------------- cd /home/evansl/prog_dev/boost-cvs/boost/libs/variant/doc/ bjam --v2 /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/tools/boostbook.jam:322: in construct warning: rulename $(base-target).depends expands to empty string /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:1025: in object(boostbook-target-class)(a)1.generate /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:546: in generate-really /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:519: in object(main-target)(a)1.generate /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build/targets.jam:203: in object(project-target)(a)11.generate /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/build-system.jam:160: in load /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/kernel/modules.jam:259: in import /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/kernel/bootstrap.jam:120: in boost-build /home/evansl/prog_dev/boost-cvs/boost/boost-build.jam:12: in module scope /home/evansl/prog_dev/boost-cvs/boost/tools/build/v2/tools/boostbook.jam:326: in construct warning: rulename $(target).set-path expands to empty string >---------------- TIA. Larry

1 2

[assign] list_inserter regression for CW8
by Rene Rivera 24 Jul '04

24 Jul '04

The failure on this test is caused by CW8's inability to do a function_template -> function_pointer -> template_type translation automatically. The workaround is to help it along by introducing a cast for the function_template -> function_pointer translation: =================================================================== RCS file: /cvsroot/boost/boost/libs/assign/test/list_inserter.cpp,v retrieving revision 1.2 diff -u -r1.2 list_inserter.cpp --- list_inserter.cpp 21 Jul 2004 11:36:10 -0000 1.2 +++ list_inserter.cpp 24 Jul 2004 15:44:55 -0000 @@ -53,7 +53,7 @@ using namespace boost::assign; vector<int> v; - make_list_inserter( &function_ptr<int> )( 5 ),3; + make_list_inserter( (void (*)(int))&function_ptr<int> )( 5 ),3; make_list_inserter( functor() )( 4 ),2; make_list_inserter( bind( &vector<int>::push_back, &v, _1 ) )( 6 ),4; BOOST_CHECK_EQUAL( v.size(), 2u ); =================================================================== That makes this test pass for CW8, and vc7.1, and mingw. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 24 Jul '04

24 Jul '04

Dave, The only workaround I have is to surround the static assertion with guards: #if !defined (__HP_aCC) BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) #endif The assumption is that if "advance" is called, the compiler errors eventually anyway so this change should be harmless (and lets aC++ compile the code). I had to do the same for "decrement" and "distance_to" member functions. Is this workaround okay? I probably should check this in only after 1.32 release in any case. -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, July 22, 2004 10:36 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U $SBCSI$" <jd2419(a)sbc.com> writes: > The problem is that since my_int2 is not a random access iterator, class > iterator_adaptor's member function "advance" would not compile because > of the static assertion below trying to convert > random_access_traversal_tag to bidirectional_traversal_tag > (my_traversal). It should never be instantiated, because it should never be called. This is a compiler bug. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

boost/test/detail/algorithm.hpp: request for promotion and/or fast review
by Gennadiy Rozental 24 Jul '04

24 Jul '04

Hi, I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory): template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2 ); template <class InputIter1, class InputIter2, class Predicate> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2, Predicate pred ); template<class ForwardIterator1, class ForwardIterator2> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class ForwardIterator1, class ForwardIterator2, class Predicate> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ) template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); Implementation together with doxigen docs is here: http://tinyurl.com/35pfj Test is here: http://tinyurl.com/yvlgu If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace. Gennadiy.

7 13

help with iterator_value and BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION
by Thorsten Ottosen 24 Jul '04

24 Jul '04

Hi, The boost.iterator docs says On compilers that don't support partial specialization, such as Microsoft Visual C++ 6.0 or 7.0, you may need to manually invoke BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION on the value_type of pointers that are passed to these metafunctions. Can anyone show how this must be used. I have no idea on how to apply this workaround. Thanks Thorsten

3 4

Re: typeof: lvalue preserving
by Arkadiy Vertleyb 24 Jul '04

24 Jul '04

Giovanni Bajo wrote: >Arkadiy Vertleyb wrote: > > > One more addition to the typeof library is a macro, that, unlike > > BOOST_TYPEOF(), which removes top-level consts and references, > > attempts to be closer to the decltype, by preserving lvalue-ness of > > its argument: > > > > BOOST_TYPEOF_PRESERVE_LVALUE(expr) > > > > I do admit that the name is quite clumzy :( > > BOOST_DECLTYPE? Well, unfortunately, it's not exactly decltype :( In particular: int i; const int ci = 0; decltype BOOST_TYPEOF_PRESERVE_LVALUE -------- ---------------------------- i int int& ci const int const int& etc. It is calculated by binding a T& to the expression. If it can't be bound the type is the same as one returned by BOOST_TYPEOF. If it can, it's either reference or const reference, depending on the constness of T. Any suggestions how to make it closer to the real decltype? Arkadiy

4 11

[Boost.Test] bug
by David Abrahams 24 Jul '04

24 Jul '04

This is with mingw-2.0 c:\boost\libs\test\build\../src/test_tools.cpp:37: `wcscmp' is already declared in this scope #if defined( __GNUC__ ) && defined( BOOST_NO_CWCHAR ) namespace std { using ::wcscmp; } <===================== here #endif -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 13

What is it with boost and tinyurl?
by Miro Jurisic 24 Jul '04

24 Jul '04

It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good. Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me. Example: Useless: <http://tinyurl.com/4ghk7> Useful: <http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pr… _options.html> ("Don't need to click if you are not interested in win32 regression of program options.") Useless: <http://tinyurl.com/yrotd> Useful: <http://lists.boost.org/MailArchives/boost/msg61026.php> ("Herein I refer to a previous thread on this mailing list.") Both of those examples were recently posted to the mailing list, and in both cases there was not enough context in the surrounding text for me to determine what the URL was about (without having to read several messages in the thread). I could name at least two other reasons for why tinyurl is not a great idea: first, it means that tinyurl.com can track my web access; second, if tinyurl is down, I am screwed. Neither of those two is as important to me as the reason I outlined above, though. Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets. If someone wants to convince me that tinyurl provides a valuable service to the community, I am listening. If not, I kindly request that those people who are in the habit of using tinyurl reconsider it. Thanks, meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

16 24

Re:[boost] Re: Re: typeof: lvalue preserving
by Robert Ramey 23 Jul '04

23 Jul '04

Arkadiy Vertleyb wrote: >"Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote >> ...I think spirit and lambda already have their own type deduction >> schemes, making it easy to implement there. >I am unaware of such schemes. You might check serialization as well. See extended_type_info.hpp and export.hpp Robert Ramey

2 1

RE: [boost] Re: BOOST_FOREACH and break
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

> There is a hidden variable in BOOST_FOREACH that tracks this > information, but it is scoped, so you can't get at it. (And > rightly so; > the scoping of hidden control variables is what makes BOOST_FOREACH > well-behaved.) BTW, while we are on topic. Your implementation uses code like this struct any_t {...}; template<typename T> struct static_any_t : any_t {...} template<typename T> static_any_t<T> foo(...); If( any_t const& ref = foo() ) { // here you are using ref } Is it indeed allowed in standard and ref is valid reference to temp? Gennadiy.

2 1