February 2004 - Boost - lists.boost.org

Lambda patch to enable *_1 for smart pointers
by Peter Dimov 25 Feb '04

25 Feb '04

I've taken the liberty to apply the following patch to boost/lambda/detail/operator_return_type_traits.hpp: *** 19,24 **** --- 19,26 ---- #include "boost/lambda/detail/is_instance_of.hpp" #include "boost/type_traits/same_traits.hpp" + #include "boost/indirect_reference.hpp" + #include <cstddef> // needed for the ptrdiff_t #include <iosfwd> // for istream and ostream *************** *** 221,227 **** // A is a nonreference type template <class A> struct contentsof_type { ! typedef typename std::iterator_traits<A>::reference type; }; // this is since the nullary () in lambda_functor is always instantiated --- 223,229 ---- // A is a nonreference type template <class A> struct contentsof_type { ! typedef typename boost::indirect_reference<A>::type type; }; // this is since the nullary () in lambda_functor is always instantiated This (hopefully) makes *_1 work for smart pointers. Feel free to revert the patch if it breaks something; I don't have a full regression test system set up. -- Peter Dimov http://www.pdimov.com

2 1

Announce: Metrowerks Pro 9 Windows Now Shipping
by Howard Hinnant 25 Feb '04

25 Feb '04

If the kind moderators allow this through I promise not to send such blatantly commercial announcements to the boost developers list again (at least for awhile :-) ). <commercial> Here is contact info which can also be found at our website www.metrowerks.com: info(a)metrowerks.com US Mail: Metrowerks Sales Metrowerks 9801 Metric Blvd. Austin, TX 78758 Telephone: Toll Free: 800-377-5416 International: +1 512 997 4700 Fax: +1 512 997 4901 I'm personally very proud of many of the Pro 9 features which include pseudo move semantics for vector. For example you might want to try running the following demo under CodeWarrior and your 2nd favorite compiler (optimize for speed): #include <string> #include <set> #include <iostream> #include <time.h> #include <vector> int main() { std::string s(20, ' '); std::multiset<std::string> ms; for (int i = 0; i < 100; ++i) ms.insert(s); std::vector<std::multiset<std::string> > v(10000, ms); clock_t t = clock(); v.erase(v.begin()); t = clock() - t; std::cout << (double)t/CLOCKS_PER_SEC << '\n'; } Assuming your clock() function has sufficient resolution to produce reasonable results on your platform you might be interested in the results. Of course this should be old hat to Mac users (Pro 9/Mac has been out for months). Fwiw, here's what I'm getting on my Mac: [G4:~/Documents/Development/JunkMac] hinnant% ./helloworld 0.01 // CodeWarrior Pro 9 [G4:~/Documents/Development/JunkMac] hinnant% g++ -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) [G4:~/Documents/Development/JunkMac] hinnant% g++ -O4 HelloWorld.cp [G4:~/Documents/Development/JunkMac] hinnant% ./a.out 1.08 </commercial> -Howard

3 2

1.31.0 regressions
by David Abrahams 24 Feb '04

24 Feb '04

IIUC, we've already found some regressions with 1.31.0, having to do with the graph library and MSVC6. These regressions affect the Python lib also, and the problems show up in the regression test results. It's very disappointing to me that even though the Python library was being tested continuously, we let the release go out anyway. We ought to ask ourselves how this happened and see if there's something we can do to prevent it in the future. My guess is that inspecting regression results by hand isn't good enough, and we need an automated system like the BuildBot. We also ought to be thinking about releasing 1.31.1 ASAP. -- Dave Abrahams Boost Consulting www.boost-consulting.com

25 105

Lambda patch to make it recognize a nested ::result_type
by Peter Dimov 24 Feb '04

24 Feb '04

The following patch to boost/lambda/detail/return_type_traits.hpp enables it to extract the return type information from a nested ::result_type typedef instead of insisting on a sig<> template. This is useful since all standard function objects in <functional> and many user-defined function objects (including those produced by boost::mem_fn) have result_type but no sig<>. I have not commited the patch yet, even though it seems to work fine for me, since it alters the Lambda behavior in the case where a function object defines both result_type and sig<>. Currently, sig<> is used. With the patch, result_type would override sig<>. All function objects known to man that have both do define sig<> to return the same type as result_type; nevertheless, I'd like confirmation from the maintainers first, before I commit. Thanks for listening; patch follows: *** 17,22 **** --- 17,24 ---- #ifndef BOOST_LAMBDA_RETURN_TYPE_TRAITS_HPP #define BOOST_LAMBDA_RETURN_TYPE_TRAITS_HPP + #include "boost/mpl/aux_/has_xxx.hpp" + #include <cstddef> // needed for the ptrdiff_t namespace boost { *************** *** 239,244 **** --- 241,265 ---- typedef Ret type; }; + // ::result_type support + + namespace detail + { + + BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type) + + template<class F> struct get_result_type + { + typedef typename F::result_type type; + }; + + template<class F, class A> struct get_sig + { + typedef typename function_adaptor<F>::template sig<A>::type type; + }; + + } // namespace detail + // Ret is detail::unspecified, so try to deduce return type template<int I, class Args> struct return_type_N<function_action<I, detail::unspecified>, Args > { *************** *** 251,257 **** public: // pass the function to function_adaptor, and get the return type from // that ! typedef typename function_adaptor<plain_Func>::template sig<Args>::type type; }; --- 272,282 ---- public: // pass the function to function_adaptor, and get the return type from // that ! typedef typename detail::IF< ! detail::has_result_type<plain_Func>::value, ! detail::get_result_type<plain_Func>, ! detail::get_sig<plain_Func, Args> ! >::RET::type type; }; -- Peter Dimov http://www.pdimov.com

2 1

vc71 - tokenizer not working with static runtime and unicode?
by Bronek Kozicki 24 Feb '04

24 Feb '04

Following problem has been reported on boost users list. If following code is compiled with compiler option /MD (dynamically link to runtime library) it works, but when compiled without it (statically linked to runtime), it produces no output. >>>> code begin #include <string> #include <iostream> #include <boost/tokenizer.hpp> int main() { typedef boost::tokenizer<boost::char_separator<std::wstring::value_type>, std::wstring::const_iterator, std::wstring> MyTokenizer; const boost::char_separator<std::wstring::value_type> sep(L"a"); MyTokenizer token(std::wstring(L"abacadaeafag"), sep); for (MyTokenizer::const_iterator it = token.begin(); it != token.end(); ++it) std::wcout << *it << std::endl; } >>>> code end I suppose there might be some problem with vc71 static runtime library, but maybe you have other explanation? B.

5 9

Re: Intel 8.0 on Windows now passes all Boost regression tests
by Michael Stevens 24 Feb '04

24 Feb '04

[boost] Intel 8.0 on Windows now passes all Boost regression tests > A bug fix version of Intel 8.0 for Windows has been posted on their web > site. This new version passes all Boost regression tests. See > http://boost.sourceforge.net/regression-logs/ > Congratulations to Intel, and thanks for fixing several bugs which were > causing Boost tests to fail! Oh this is definitely very good. Time I downloaded the Linux version. There are some false positives however. uBLAS test3,4,5 should fail really. They have a couple of missing typenames with gcc-3.4 correctly picks up. The patches for this should be merged into Boost CVS very soon. I wonder if the Intel compiler can be configured to be a little more strict. The more good compilers that can pick up code that is non standard conforming the better. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

4 3

random_device
by Richard Peters 24 Feb '04

24 Feb '04

The random_device.cpp in boost version 1.31.0 does not support a nondeterministical random device for Windows. I used the Windows CryptoAPI to make random_device.cpp support the Windows platform as well. The attached random_device.cpp has new code at lines 100-152 and is tested under VC 7.1. Best regards, Richard Peters

1 0

BBv1 New CodeWarrior toolset.
by Rene Rivera 24 Feb '04

24 Feb '04

Boosters, Yesterday I added a new Boost.Build v1 toolset for use with the Metrowerks CodeWarrior compilers. This is a cleanup, and improvement, of the current toolsets metrowerks-tools, cwpro8-tools, cwpro9-tools. The new toolset "cw" implements all the functionality in those three and more. It is meant as a replacement for them, and hence they will be removed soon. Documentation is in the usual place, boost-root/tools/build/v1/cw-tools.html. For testers I ask that they test with the new toolset at the earliest opportunity. Especially those with version 9 of CW, as I only have version 8. Right now the toolset still only supports the Windows platform. But if people have CW on other platforms changes to accommodate them are welcome ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 3

Re: [boost] Re: Customization via Overloading in Namespace
by Peter Dimov 24 Feb '04

24 Feb '04

Peter Dimov wrote: > David Abrahams wrote: >> >> Simple: specializations that follow the point of instantiation aren't >> considered. This program exits with an error: >> >> template <class T> >> int f(T) { return 1; } >> >> int main() { return ::f(0); } >> >> template <> int f(int) { return 0; } > > It's ill-formed, actually. On reflection, I think I see what you are trying to illustrate, and I also think that you are wrong. #include <iostream> // f.hpp template<class T> void f(T) { std::cout << "General\n"; } // g.hpp template<class T> void g(T t) { ::f(t); } // X.hpp struct X {}; /*template<>*/ void f(X) { std::cout << "X-specific\n"; } // main.cpp int main() { f( X() ); g( X() ); } Uncomment the /*template<>*/ to see what I mean. No order dependency.

2 1

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 24 Feb '04

24 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > Should we propose std::regress (the counter-part for > std::advance) for > standardization (via a DR)? The current definition of > std::advance seems > to limit the number of elements that can be skipped backwards > to signed > types, but the container can be larger (OK, in theory, never tried it > myself :). This would also nicely solve the implementation > issue for us. I don't think it's really a defect; there's a slight inconsistency with regards to the max/min values on most platforms, but nothing inherently wrong AFAICS. Note that the reverse_iterator trick can be used by client code too, so the "signed type limit" is easily defeated. [snip] > right? Although I wonder what happens if T is already a reverse > iterator. Is it legal to reverse a reverse_iterator? Or do we need a > trait and implement both cases separately? Yes, reversing a reverse_iterator this way is fine (because a reverse_iterator satisfies the iterator requirements). Bjorn

4 4