- Boost - lists.boost.org

GSoC idea on Geometry library
by sultana rashid 08 Feb '12

08 Feb '12

Hello, I have several ideas on some libraries.Today I present on Geometry library. *1.Conics:* I did not found *conics* in Geometry library.Ellipse,parabola,hyperbola concept is very useful in geometry.Can Boost add some functionality of conics? as: 1.Area determination of conics 2.Foci determination 3.Major-minor axis 4.Determine whether a point on a conic 5.Focal length,center determination etc... etc... Or at least add something on Conic in Concept section? If this idea seems useful to you,please let me know.I will describe details on what I want to do about Conic section in Geometry library. *2. **Convex HUll: *There is only one algorithm implemented .We can implement *Gift wrapping*<http://en.wikipedia.org/wiki/Gift_wrapping_algorithm> *O*(*nh*) ; *Divide and conquer* *O*(*n* log *n*) or *Chan's algorithm*<http://en.wikipedia.org/wiki/Chan%27s_algorithm> *O*(*n* log *h*). Jarvis march ,Chan's algo are output sensitive.These are useful when we can assume that the result will not be too large. Thanking you, Sultana

3 2

Manually marking noexcept for a constructor
by Daryle Walker 08 Feb '12

08 Feb '12

I realized that my proposed C++11 update for base_from_member should propagate noexcept. But how do I manually specify the noexcept status of an inner constructor? (Beta versions of C++11 may just have core language changes but not the library changes, so I shouldn't rely on is_nothrow_XXX_constructible just like not relying on std::forward.) I originally thought of: class MyType{ MyInnerType x;public: MyType() noexcept( noexcept(MyInnerType()) );}; This expression includes the inner default constructor call, but it also secretly includes a destructor call (for MyInnerType), and therefore includes it in the calculations! But how about: class MyType2{ MyInnerType x;public: MyType2() noexcept( noexcept(new (std::nothrow) MyInnerType()) );}; Hopefully this, or something like it, includes the constructor call, without calling a destructor. I think the C++11 version of nothrow_t-new is marked noexcept, and I hope the complete new call doesn't hide the constructor call. Daryle W.

1 0

MSVC 2010 Compile error for polygon_set_data
by Praveen Vs 08 Feb '12

08 Feb '12

Hi, Below code gives a compile error in MSVC2010. Any ideas whats the issue? #include <boost/polygon/polygon.hpp> namespace gtl = boost::polygon; using namespace gtl; using namespace boost::polygon::operators; using namespace std; typedef gtl::polygon_set_data<double> CPolygonSet; static void test_boost_polygons() { CPolygonSet polyset1, polyset2, rset; rset = polyset1 + polyset2; } void main() { test_boost_polygons(); } Error: ===== \boost\polygon\polygon_45_set_data.hpp(1458): error C2825: 'iT': must be a class or namespace when followed by '::' 1>\boost\polygon\polygon_45_set_data.hpp(1524) : see reference to function template instantiation 'void boost::polygon::get_error_rects_shell<cT,const boost::polygon::point_data<T>*>(cT &,cT &,iT,iT)' being compiled 1>with 1>[ 1> cT=stlp_std::vector<boost::polygon::rectangle_data<Unit2>>, 1> T=double, 1> iT=const boost::polygon::point_data<double> * 1>] 1>\boost\polygon\polygon_45_set_data.hpp(1621) : see reference to function template instantiation 'void boost::polygon::get_error_rects<stlp_std::vector<_Tp>,boost::polygon::polygon_45_with_holes_data<T>>(cT &,cT &,const pT &)' being compiled 1>with 1>[ 1> _Tp=boost::polygon::rectangle_data<Unit2>, 1> T=double, 1> cT=stlp_std::vector<boost::polygon::rectangle_data<Unit2>>, 1> pT=boost::polygon::polygon_45_with_holes_data<double> 1>] 1>\boost\polygon\detail/polygon_set_view.hpp(102) : see reference to function template instantiation 'void boost::polygon::polygon_45_set_data<Unit>::applyAdaptiveBoolean_<0>(boost::polygon::polygon_45_set_data<Unit> &,const boost::polygon::polygon_45_set_data<Unit> &) const' being compiled 1>with 1>[ 1> Unit=double 1>]

1 1

[utility] Don't mind if I "change" base_from_member?
by Daryle Walker 08 Feb '12

08 Feb '12

Since the suggested trick of using GCC (4.6) from MacPorts as a Darwin GCC worked, I've tried out my first C++11 update: base_from member. It's very straightforward. //$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$Index: boost/utility/base_from_member.hpp===================================================================--- boost/utility/base_from_member.hpp (revision 76917)+++ boost/utility/base_from_member.hpp (working copy)@@ -1,6 +1,6 @@ // boost utility/base_from_member.hpp header file --------------------------// -// Copyright 2001, 2003, 2004 Daryle Walker. Use, modification, and+// Copyright 2001, 2003, 2004, 2012 Daryle Walker. Use, modification, and // distribution are subject to the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or a copy at // <http://www.boost.org/LICENSE_1_0.txt>.)@@ -10,6 +10,7 @@ #ifndef BOOST_UTILITY_BASE_FROM_MEMBER_HPP #define BOOST_UTILITY_BASE_FROM_MEMBER_HPP +#include <boost/config.hpp> #include <boost/preprocessor/arithmetic/inc.hpp> #include <boost/preprocessor/repetition/enum_binary_params.hpp> #include <boost/preprocessor/repetition/enum_params.hpp>@@ -68,12 +69,19 @@ protected: MemberType member; +#if defined(BOOST_HAS_RVALUE_REFS) && defined(BOOST_HAS_VARIADIC_TMPL)+ template <typename ...T>+ explicit BOOST_CONSTEXPR base_from_member( T&& ...x )+ : member( static_cast<T&&>(x)... ) // some libs don't have std::forward+ {}+#else base_from_member() : member() {} BOOST_PP_REPEAT_FROM_TO( 1, BOOST_PP_INC(BOOST_BASE_FROM_MEMBER_MAX_ARITY), BOOST_PRIVATE_CTR_DEF, _ )+#endif }; // boost::base_from_member //$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ I don't use std::forward because I've heard that some beta C++11 modes implement the core-language ideas needed (r-value references) but not the library changes (i.e. std::move and std::forward), and I didn't want to find (and conditionally?) #include another header. What I got will work just fine, right? Do the constructors need any marking besides "explicit" and "constexpr"? (I believe the "constexpr" will be safely ignored if the forwarded constructor isn't "constexpr" itself without a compile-time error. It was designed that way, right?) I'll just update the documentation and commit the change, then. Daryle W.

1 0

docs on new build system?
by Neal Becker 07 Feb '12

07 Feb '12

I am testing 1_49_0_beta1. I see my usual build failed, saying 'warning: mismatched versions of Boost.Build engine and core'. Taking a wild guess, tried cd tools/build/v2 sh ./bootstrap.sh sudo ./b2 install --prefix=/usr/local I see I now have a new bjam, and something called 'b2'. Should I be reading some new docs on how to use this stuff? Are there some docs? My old build procedure: bjam -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage Seems to be proceeding normally (so far)

2 1

[hash] regular behaviour of hash function for double values
by Kai Schroeder 07 Feb '12

07 Feb '12

Hi, the following code: double fStart = 31337; double fEnd = 65536; double fStep = fStart - fEnd; fStep /= 512; for (int i = 0; i < 512; i++) { std::cout << std::hex << boost::hash<double>()(fStart + i * fStep) << std::endl; } leads to the output of surprisingly regular hash values (see end of mail). This seems to occur mainly if a power of two number of points is sampled equidistantly within an interval. Especially since some hash table implementations (e.g. intel's threading building blocks) only use the last few bits to determine the bucket, this can lead to very bad caching behaviour for the rather common case of regularly sampled points (equidistant samplings of power of 2 are e.g. common in computer graphics and numerical algorithms). Are you aware of this? Would you consider it a bug? Best regards, Kai Schroeder Output of code using Boost 1.48 (similar behaviour can be observed for other start and end values and other power of 2 step counts): ff9f20000000000f e5042f900000000f 52f13f200000000f 297ac8b00000000f 48721e400000000f 2f9b8dd00000000f 3df0b1600000000f d19cf2f00000000f 9201c800000000f 9409aa100000000f 7cb3fba00000000f d7a42b300000000f b15982c00000000f 5f7900500000000f e0ba85e00000000f 255ee5700000000f cec119000000000f 955bd6900000000f 6a58f4200000000f 843a37b00000000f 590797400000000f 7e8db4d00000000f 1721b6600000000f 37acf9f00000000f df5f65800000000f 88b1a5100000000f 494a0a00000000f bb1082300000000f 1ea62bc00000000f ...

11 43

unordered_map 32bit VS 64bit
by Avikam Bara-nes 07 Feb '12

07 Feb '12

Hi, I'm porting a project from Linux 32bit to Linux 64bit. While doing so I notice that I have a dramatic performance degradation with unordered_map. My platform is Ubuntu 10.4.3 64bit running on Intel Xeon X3220 but, I tested similar program on WindowsXP SP2 64bit which running on Intel i5 and I get the same degradation. My boost version is 1_46_1. I use the following program in order to test unordered_map - Hop I didn't make any copy mistakes :-). #include <stdio.h> #include <sys/time.h> #include <boost/unordered_map.hpp> int main(int argc, char *argv[]) { struct timeval tv_before, tv_after; boost::unordered_map<boost::int_32_t, boost::int32_t> boost_map; boost_map[1] = 2; boost_map[3] = 4; gettimeofday(&tv_before, NULL); for(int i = ; i < 100000; i++) boost_map.find(1); gettimeofday(&tv_after, NULL); printf("Boost time is %f \n", (double)(((tv_after.tv_sec - tv_before.tv_sec) * 1000000 + (double)(tv_after.tv_usec - tv_before.tv_usec)) / 100000)); return 0; } I use the following compile commands: 64bit - g++ -O3 perf_test -o perf_test_64bit 32bit - g++ -m32 -O3 perf_test -o perf_test_32bit When I run the 32bit program I get 0.5 sec When I run the 64bit program I get 1.54 sec Any ideas ???

6 16

[MPI]: All tests failing -- branch and trunk
by Steve M. Robbins 07 Feb '12

07 Feb '12

Hi, I have been running a daily test of the Boost release branch for a long time. It normally takes an hour or so. However, two days ago (rev 76868), the build time shot up to over 9 hours. The same thing happened for testing the Boost trunk branch. Others on the boost-test list have experienced the same and Jurgen Hunold pointed out that all the MPI tests are failing. According to http://www.boost.org/development/tests/trunk/developer/mpi.html this is true for about half the tester machines. Should probably be fixed before 1.49 is released! -Steve

1 0

[functional] adding overload
by Lorenzo Caminiti 06 Feb '12

06 Feb '12

Hello all, During Boost.Local review, it was proposed to move the overload template out of Local and in Boost.Functional. What would the best name for it? 1) boost::overload_function (my preference) 2) boost::overloaded_function 3) boost::function_overload 4) boost::functional::overload (Boost.Functional seems to use boost:: directly and not boost::functional-- to mimic C++11 <functional>). For example: void print_text(char const* text) { std::cout << text << std::endl; } void print_add(int x, int y = 10) { std::cout << (x + y) << std::endl; } boost::function<void (int, int)> f = print_add; boost::overload_function< void (char const*) , void (int, int) , void (int) > print(print_text, f, print_add); print("abc"); // abc print(1, 2); // 3 print(1); // 11 Docs: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… Thanks. --Lorenzo

8 18

[filesystem] windows/posix inconsistencies.
by Thorsten Ottosen 06 Feb '12

06 Feb '12

Hi Beman, I noticed the following in v3 whie hunting down a bug in my unit test: # ifdef BOOST_WINDOWS_API const std::string string() const { return string(codecvt()); } const std::string string(const codecvt_type& cvt) const; // string_type is std::wstring, so there is no conversion const std::wstring& wstring() const { return m_pathname; } const std::wstring& wstring(const codecvt_type&) const { return m_pathname; } # else // BOOST_POSIX_API // string_type is std::string, so there is no conversion const std::string& string() const { return m_pathname; } const std::string& string(const codecvt_type&) const; const std::wstring wstring() const { return wstring(codecvt()); } const std::wstring wstring(const codecvt_type& cvt) const # endif I can understand, that it is more efficient to return a reference when a referenec can be formed. However, consider const std::string& ext = iter->path().extension().string(); This is fine on windows, as a temporary is returned, and its lifetime is extended; on linux, extension() returns a temp path object, from where we get a reference. I'm not a 100% sure, but I think the C++ standard does not guarantee that this path object be kept alive. The net efffect is a crash on linux. I'm not sure its a great idea to have different reference-ness on the return types here. It could lead to other subtle differences. kind regards -Thorsten

9 14