- Boost - lists.boost.org

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

allocator_facade
by Alberto Barbati 24 Feb '04

24 Feb '04

Hi Boosters, I had a very good time writing iterators with the new iterator_facade template. Very good job! It makes writing iterators so much simpler! What about having a similar template for allocators? Given that a large class of useful allocators are de facto built over a couple of typeless malloc-like/free-like functions, I imagine something that could be used like this: struct malloc_impl { static void* allocate(size_t n) { return malloc(n); } static void deallocate(void* p) { free(p); } }; std::vector<int, boost::allocator_facade<int, malloc_impl> > v; where boost::allocator_facade<T, malloc_impl> satisfies all requirements that std::allocator<T> does. An implementation for a conforming compiler and library is straightforward and allocator_facade could also include workarounds for specific platforms where possible (for example it can easily and automatically provide the __stl_alloc_rebind hack in STLport). Is there any interest for such a thing? Alberto

3 2

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Hurd, Matthew 24 Feb '04

24 Feb '04

> On Behalf Of Matthew Vogt > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > >Hurd, Matthew <hurdm <at> sig.com> writes: > > > Had a little thought that might be relevant. Please spank me if this is > > OT given the rather specific implementation I'm dropping in on... > > > > Not at all. If this proves useful, I would certainly want to support it. > > > As mentioned previously, future values could give you a lazy way of > > evaluating the result, even when you aren't multithreaded. > > > > In the truly "active" object, that is, it has at least one thread, you > > could call the methods with a future instead of a normal value so that > > when the result arrives it percolates through the implied queue. > > > > Now for a new thought. What about using an expression template > > mechanism so that when you combine futures they are glommed at compile > > time to remain lazy? > > > > boost::future<double> sum = some_thing_maybe_active.total(); > > boost::future<double> count = some_thing_maybe_active.count(); > > boost::future<double> average = sum / count; > > > > sum / count forms a lazy expression > > > > if a method groks a future and then this becomes interesting... > > > > boost::future<double> result = > > some_thing_maybe_active.do_stuff(average); > > > > You can end up with the active object percolating all the way through to > > "result" without any blocking until the result of "result" is used. > > > > Yes, certainly. I'm not au fait with expression templates, but you could > alternatively implement arithmetic operations in future<T> which > maintained > shared pointers to operands, and stored a function pointer to std::plus, > etc. Expression templates are just a way of doing the kind of thing you have just described at compile time. Here is a famous intro http://www.adtmag.com/joop/crarticle.asp?ID=627 that I like anyway. > > If you get rid of the thread(s) in the active object idea, you end up > > with a mechanism for lazy evaluation. > > > > This I don't really follow. If you take away the thread from the active > object > then the calling thread must perform the evaluation itself, eventually. > What > you have left is equivalent to a sequence of boost::binds to a standard > function, haven't you? No, it doesn't have to perform the operation, the future could simply contain a boost::optional<value> with a boost::function callback, for one example implementation, so the calc might not be done until it is really needed... I was thinking about this situation in terms of what it would take to move this successfully to a single threaded (or passive object?) case and the problem of messy dependencies that automagically resolve themselves in the threaded active object sense might not have a solution, or might have a less efficient solution, if laziness was not the default behaviour. That is you could end up waiting on things that haven't been kicked off and thus you deadlock without laziness. > > Perhaps there is a more general mechanism / pattern and bike shop name > > lurking in this pattern... > > > > Regards, > > > > Matt Hurd > > Are you suggesting that the 'future' template is a convenient syntactic > sugar > for lazy evaluation, as a separate concern to the threading involved? If > so, > I can't disagree... > > Matt Yup, laziness and possibly a neat way of keeping things architectural neutral with appropriate policies. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0