- Boost - lists.boost.org

namespace for math function and statistics distributions
by Paul A Bristow 21 Oct '06

21 Oct '06

John Maddock and I have been beavering away on the many math function and statistics distributions but are uncertain if and how best to use namespaces, so we are asking for views because we need to make rather pervasive decisions now (that we should have done before ;-). There are existing math functions (octonions, quaternions, acosh) in namespace boost::math:: and John has added many more, for example: #include <boost/math/special_functions/beta.hpp> // for ibeta(a, b, x) == Ix(a, b). so users can write using boost::math::ibeta_invb; ibeta_invb(r, p, P); So far, so good. Each statistical probability distribution, like negative_binomial includes a typedef typedef negative_binomial_distribution<double> negative_binomial; // Reserved name of type double. so that users have the great convenience (when using double - 99% of use?) of specifiying distributions thus using boost::math::negative_binomial; // default type is double. negative_binomial mydist(8., 0.25); rather than having to use the rather long full, type specified name: negative_binomial_distribution<double> my8dist(8., 0.25); This seems neat, except that there are functions beta, gamma and binomial :-(( So there is a name clash when using thus: using boost::math::binomial; binomial mydist(2., 0.5); // is it a function or a probability distribution? We are therefore considering to use namespaces to separate the math functions from the stats distributions into namespace boost::math::distributions, or ? so users would write: using boost::math::distributions::binomial; binomial mydist(8., 0.25); Or should it be in namespace boost::statistics; or boost::statistics::distributions or should all the functions be in namespace boost::math::functions - changing much existing code :-(( or ???? Views please. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

2 2

[thread] Should read_write_mutex be removed from 1.34 branch?
by Roland Schwarz 21 Oct '06

21 Oct '06

Since the current implementation of read_write_mutex still is suffering from a known bug (which has not been fixed since pre1.33) I ask if it should also be removed from 1.34 branch. The read_write_mutex has not been part of 1.33 exactly for this reason. We plan to provide a rewritten one for 1.35, but it is not yet stable enough (i.e being extensively reviewed and tested). The alternative would be to deliver it in 1.34, but putting a big fat warning. Also it could be marked in the regressions as "unexpectedly passing", so users would not get a wrong impression. Unfortunately no test case yet exists, that is able to trigger the error for sure. The below links refer to the bug: http://lists.boost.org/Archives/boost/2005/08/92307.php http://lists.boost.org/Archives/boost/2005/09/93180.php Please let me know what you think. Roland

1 0

question about boost::ends_with
by Leo Jay 21 Oct '06

21 Oct '06

following code is supposed to output 1, but in my vs2005, the output is 0. if i change the "ends_with(str, sz)" into "ends_with(str, string(sz))", the output is correct. i wonder why. is there any difference between these two statement? thanks. // boosttest.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <boost/algorithm/string.hpp> #include <string> #include <iostream> using namespace boost; using namespace std; int _tmain(int argc, _TCHAR* argv[]) { char sz[1024] = "test.bat"; string str("C:\\test.bat"); cout << ends_with(str, sz) << endl; return 0; } -- Best Regards, Leo Jay

1 0

Boost bind "improvement"?
by Herve Bronnimann 21 Oct '06

21 Oct '06

Peter and David (and others :-) Boost.bind currently has the limitation that a binder will not be invoked with non-const rvalues, as was very nicely explained in the "Forwarding Problem" (document http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm) In that paper, you discuss a possible solution which you deem impractical, i.e. to add all 2^N overloads mixing & and const& for the invocation arguments. Indeed, Boost.bind already supports 9 arguments and 2^9 is a large number... However, I fail to see the shortcoming in the following approach: add 2*N (not 2^N) overloads, one set of N where all arguments are taken as &, and another set of N where all the arguments are taken as const&. If any invocation argument is a non-const lvalue, then all arguments will be taken as & (first set of overloads) since this is the only one that will match. And if all arguments can be passed to a const&, then the second set of overloads will provide a better match than the first, hence no ambiguity. Such an extension would allow boost.bind to forward non-const rvalues, in the case where none of the arguments is a non-const lvalue. So the example showing the limitation of the current solution #1 in the document cited above will then work. You still will not be able to forward a mix of non-const lvalues and rvalues, but it may not happen very frequently (most return arguments I use in my code are passed by address, in C style, and an address can be matched to a "T* const&"). Also, the cost is not high (what's an extra 9 overloads, when you already have 9 :-) My question is: Is there something I am missing that would create problems in the usage of Boost.bind, if the second set of overloads were added (besides the inconvenience of more overloads and a longer source code to parse for the compiler)? BTW, I am not necessarily advocating that Boost.bind provide the const& overloads, although I think it would be nice if there are no problems associated with it. Thanks for any thoughts, -- Herve Bronnimann

3 4

Re: [boost] GIL Review: example files coming...
by Lubomir Bourdev 20 Oct '06

20 Oct '06

I just posted the GIL code sample files and regression tests. You can get them from http://opensource.adobe.com/gil/download.html The following example files are included: 1. resize.cpp Scales an image using bilinear or nearest-neighbor resampling 2. affine.cpp Performs an arbitrary affine transformation on the image 3. convolution.cpp Convolves the image with a Gaussian kernel 4. mandelbrot.cpp Creates a synthetic image defining the Mandelbrot set 5. interleaved_ptr.cpp Illustrates how to create a custom pixel reference and iterator. Creates a GIL image view over user-supplied data without the need to cast to GIL pixel type 6. x_gradient.cpp Horizontal gradient, from the tutorial 7. histogram.cpp Algorithm to compute the histogram of an image 8. packed_pixel.cpp Illustrates how to create a custom pixel model - a pixel whose channel size is not divisible by bytes 9. dynamic_image.cpp Example of using images whose type is instantiated at run time ____________________ You should also resync to the latest GIL. The change: When you assign a channel to a grayscale pixel you must qualify it with the channel type. For example, the following code will no longer compile: gray8_pixel_t p(5); // error gray8_image_t img(100,100); img[10] = 5; // error You must now do: gray8_pixel_t p(bits8(5)); gray8_image_t img(100,100); img[10] = bits8(5); This affects the x_gradient code in the tutorial/presentation. We updated the tutorial. ____________________ I am away this weekend. I may not have email access until Monday. Lubomir

1 0

[concept_check] Why should this fail to link?
by Nicola Musatti 20 Oct '06

20 Oct '06

Hallo, I was looking at the concept_check tests that fail for Borland and I can't understand why they're expected to compile but not to link. If I haven't made any mistake the following should be a stripped down version of concept_check_fail_expected, which is marked as link_fail (the comments are mine - feel free to correct me): #include <boost/mpl/identity.hpp> namespace boost { // mpl::identity is used to ensure that the Concept argument is not instantiated when function_requires is template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { // this causes Concept::constraints to be instantiated - // and nothing else void (Concept::*x)() = &Concept::constraints; } // This enforces the "convertible to bool" requirement template <class TT> void require_boolean_expr(const TT& t) { bool x = t; } template <class TT> struct EqualityComparableConcept { // Why shouldn't this just fail to compile due to operator== not being // defined for foo? void constraints() { require_boolean_expr(a == b); } TT a, b; }; } // namespace boost struct foo { }; int main() { boost::function_requires< boost::EqualityComparableConcept<foo> >(); return 0; } What am I missing? Thanks for your help. Cheers, Nicola Musatti

1 0

[typeof] support for template nested types
by Peder Holt 20 Oct '06

20 Oct '06

We have recently been working to implement support for deduction of stl iterators in the typeof emulation. In the process, a method to completely deduce the type of nested templates emerged. Initially we want to make this method available in order to deduce dinkumware iterators, as there is no (standard) way to do that at present. With the method we are able to deduce e.g. std::set<UserType,user_predicate<UserType>,user_allocator<UserType> >::const_iterator, given separate registration of the template user_predicate and user_allocator. It is possible to envision a general utility for registering template nested classes with the typeof emulation. Is there any interest in this? Otherwise we'll only add specialized code for stl iterators. The method consists of two steps. The first of which is well known. Given a type T (presumably an iterator) Lets assume it is of type std::set<T,std::greater<T> >::iterator 1. Check if it has a value_type typedef, using enable_if. 2. If it has a value_type typedef, pass the value_type to a predicate resolver (enabled with enable_if IFF the resulting iterator generated using that predicate matches T). 3. The predicate resolver sends the value_type on to the allocator resolver which uses enable_if in the same way. The allocator resolver in turn tries to match against an actual iterator, using the given value_type, predicate and allocator. Below is a sample code: deduction of allocator type is ignored for simplicity. template<class T> static char has_value_type_helper(typename T::value_type*); template<class T> static char (&has_value_type_helper(...))[2]; template<class T> struct has_value_type : boost::mpl::bool_<sizeof(has_value_type_helper<T>(0)) == sizeof(char)> {}; template<typename T,typename ValueType,typename Pred,typename Enable=void> struct deduce_set : boost::mpl::false_ {}; template<typename T,typename ValueType,typename Enable=void> struct deduce_set_predicate : boost::mpl::false_ {}; template<typename T,typename Enable=void> struct is_set_iterator : boost::mpl::false_ {}; template<typename T,typename ValueType,typename Pred> struct deduce_set<T,ValueType,Pred,typename boost::enable_if<boost::is_same<T,typename std::set<ValueType,Pred>::iterator> >::type> : boost::mpl::true_ { typedef std::set<ValueType,Pred> container_type; BOOST_STATIC_CONSTANT(bool,is_const_iterator=false); }; template<typename T,typename ValueType,typename Pred> struct deduce_set<T,ValueType,Pred,typename boost::enable_if<boost::is_same<T,typename std::set<ValueType,Pred>::const_iterator> >::type> : boost::mpl::true_ { typedef std::set<ValueType,Pred> container_type; BOOST_STATIC_CONSTANT(bool,is_const_iterator=true); }; /*Enable this template only if std::set<ValueType,std::less<ValueType> >::(const_)iterator is the same type as T */ template<typename T,typename ValueType> struct deduce_set_predicate<T,ValueType,typename boost::enable_if<deduce_set<T,ValueType,std::less<ValueType> > >::type> : deduce_set<T,ValueType,std::less<ValueType> > {}; /*Enable this template only if std::set<ValueType,std::greater<ValueType> >::(const_)iterator is the same type as T */ template<typename T,typename ValueType> struct deduce_set_predicate<T,ValueType,typename boost::enable_if<deduce_set<T,ValueType,std::greater<ValueType> > >::type> : deduce_set<T,ValueType,std::greater<ValueType> > {}; //Check if type has value_type typedef template<typename T> struct is_set_iterator<T,typename boost::enable_if<has_value_type<T> >::type > : deduce_set_predicate<T,typename T::value_type> {}; int main() { bool value=is_set_iterator<std::set<int, std::greater<int> >::iterator>::value; typedef is_set_iterator<std::set<int, std::greater<int> >::iterator>::container_type container_type; typedef is_set_iterator<int>::container_type container_type; //Fails to compile return 0; } Regards, Peder

3 2

[bbv2] installed libs
by Roland Schwarz 20 Oct '06

20 Oct '06

I am not sure if the following behavior is due to a local configuration error or an outcome of boost bbv2: In bbv1 the install generated libboost_XXX.lib for static libraries and boost_XXX.lib import and boost_XXX.dll DLL libraries. When doing the same with bbv2 I get boost_XXX.dll and no import libs for DLL and libboost_XXX.a for static libs. I am trying with mingw which I specified as using gcc : 3.4.2 : C:\Mingw\bin\g++.exe ; in user.config.jam in my "home" directory. Additional note: I also have cygwin installed. Roland

1 0

1.34 release: What about the inspection failures?
by Andreas Huber 20 Oct '06

20 Oct '06

Hi there After the call for volunteers to clear the regression failures (can't help with those, currently no access to the relevant platforms), I think it's also time to get busy with the remaining inspection failures: - The *X* report doesn't look too bad, all of the few remaining problems seem to be in libraries that are currently actively maintained. - The *LC* report however does not look good at all. There are a large number of problems and some of them are in public areas (e.g. people) or not actively maintained libs (e.g. pool). What should we do about the *LC* problems? Is it worth bothering with those? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

7 12

[bbv2] wrong include directory path for install target?
by Roland Schwarz 20 Oct '06

20 Oct '06

In bbv2 (on Windows) I observed, that the include gets installed to C:\install\include\boost-1_34\libnames This is problematic since include directives used by libarary users usually are: #include "boost/libname.hpp" Instead bbv2 install should go to: C:\install\include\boost-1_34\boost\libnames as it did in bbv1. Roland

1 0