June 2012 - Boost - lists.preview.boost.org

[1.50] Beta build of the PDF docs
by John Maddock 13 Jul '12

13 Jul '12

A PDF build of the 1.50(beta) docs is here: https://sourceforge.net/projects/boost/files/boost-docs/1.50/ Please let me know if there are any issues, John.

3 6

[xpressive] Compiler error on VC7.1
by Robert Dailey 10 Jul '12

10 Jul '12

Hi, I'm using Boost 1.49 Xpressive on VC7.1. When I compile the following code, I get compiler errors (these do not appear on VC9): sregex const& rex = bos >> _serverName >> !as_xpr("_GWDomino") >> ".diagnostics" >> *(as_xpr(".base")|".renamed"); 'rex' is really a function parameter in my real world use case. I'm passing the entire static regex into a function that takes a 'sregex const&'. I get the compiler error below. Anyone know why this is happening? C:\Code\work\cmake-decomp\build-vc7\third_party\boost\1.49.0-stlport-5.2.1\include\boost\proto\traits.hpp(691) : error C2664: 'boost::proto::exprns_::expr<Tag,Args,Arity>::expr(const boost::proto::exprns_::expr<Tag,Args,Arity> &)' : cannot convert parameter 1 from 'boost::proto::detail::as_expr<T,Generator,WantsBasicExpr>::result_type' to 'const boost::proto::exprns_::expr<Tag,Args,Arity> &' with [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] and [ T=const char [10], Generator=boost::proto::detail::base_generator<boost::proto::default_generator>::type, WantsBasicExpr=false ] and [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] Reason: cannot convert from 'boost::proto::detail::as_expr<T,Generator,WantsBasicExpr>::result_type' to 'const boost::proto::exprns_::expr<Tag,Args,Arity>' with [ T=const char [10], Generator=boost::proto::detail::base_generator<boost::proto::default_generator>::type, WantsBasicExpr=false ] and [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] No constructor could take the source type, or constructor overload resolution was ambiguous \Code\work\cmake-decomp\server\exchange\tools\uploadlog\uploader.cpp(1372) : see reference to function template instantiation 'const boost::add_const<T>::type boost::proto::functional::as_expr<>::operator ()<char,10>(const char (&)[10]) const' being compiled with [ T=boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::result_type ]

3 18

[chrono] time_point.hpp depends on Boost.System; should it?
by Krzysztof Czainski 09 Jul '12

09 Jul '12

Hello, I want to create my own clock class, and in it among other things I would like to typedef a time_point<...>. struct MyClock { typedef int64_t rep; typedef boost::milli period; typedef boost::chrono::duration<rep,period> duration; typedef date_chrono::time_point<SystemClock,duration> time_point; static bool const is_monotonic = false; static time_point now(); }; Now, for this to work I obviously need to #include <boost/chrono/time_point.hpp>. Including it causes a dependency on Boost.System, making me have to link with it. But since I don't use any clocks provided by Boost.Chrono, I think the dependency on Boost.System is unnecessary. In fact, I was able to get rid of the dependency, and everything seems to work. I commented out 1 line from <boost/chrono/time_point.hpp>: //#include <boost/chrono/detail/system.hpp> Could this #include be removed from time_point.hpp, or is it needed for something I am not using ATM? Regards, Kris

2 5

[1.51][Release] Short release cycle
by Daniel James 08 Jul '12

08 Jul '12

Hello everyone, Just a quick warning that due to the delay releasing 1.50, the 1.51 release cycle is going to be a lot shorter than normal. It's a little under 2 months until the scheduled 1.51 release date. This means that the deadlines are pretty soon. If you haven't checked it yet, please take a look at the calendar at: http://www.boost.org/community/ The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon. thanks, Daniel

21 54

[Range] Range adaptor approach for temporary range lifetime issue
by Michel Morin 06 Jul '12

06 Jul '12

When an rvalue range is adapted in range-based for loop, the lifetime of the rvalue range ends before the loop body begins. For example, the following code produces dangling references. for (auto x : std::string("Hello world!") | reversed) { /*...*/ } This is the temporary range lifetime issue. When I proposed BOOST_FOREACH extension for this issue, ( http://lists.boost.org/Archives/boost/2011/04/180591.php ) a solution with "moving an rvalue range into range adaptors" was suggested in the thread. I implemented this approach as a range adaptor (with the aid of rvalue references and decltype C++11 features): for (auto x : std::string("Hello world!") | moved | reversed) { /*...*/ } When an rvalue range is piped to `moved` adaptor, it returns `moved_range`. `moved_range` stores the following data: * Moved rvalue range: The rvalue range is moved and stored in `moved_range`. * Applied adaptors: When range adaptors are applied to`moved_range`, they are not invoked immediately; they are stored in fusion vector. The stored adaptors are invoked when `begin` or `end` member functions of `moved_range` are called. (To prevent repeated applications of the stored range adaptors, begin and end iterators are cached when they are first computed.) For example, in `std::string("Hello world!") | moved | reversed`, 1. By applying `moved` adaptor, `moved_range` is created. It stores `std::string` object moved from `std::string("Hello world!")`. It doesn't store any adaptors. 2. By applying `reversed` adaptor, another `moved_range` is created. It stores `std::string` object moved from the previous `moved_range`. It also stores `reversed` adaptor in fusion vector. Step 2 is repeated if more adaptors are applied. Then, in "for-init-statement" of range-based for loop, the stored adaptors are actually applied (and the result is cached). The free function version (`boost::adaptors::move`) supports `std::initializer_list`: for (auto x : move( {1, 2, 3, 4, 5} ) | reversed) { /*...*/ } Note that we cannot support it in the pipe syntax `{1, 2, 3, 4, 5} | moved` because the C++11 Standard does not allow to use list initializers in binary operators. Code attached. Comments? Regards, Michel

7 40

[1.50.0] Release candidates available for testing
by Beman Dawes 05 Jul '12

05 Jul '12

Release candidate files for 1.50.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

[Review Request] Inclusion of the Boost.Polygon Voronoi Library
by Andrii Sydorchuk 04 Jul '12

04 Jul '12

Boost community, It has been two years since I started development of the Voronoi library as part of the Google Summer of Code 2010. Finally I feel that the library is ready to become public and would like to request a review for the inclusion into the Boost.Polygon library. Features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). The full list of features could be found here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm Limitations: - Input geometries should have integer coordinates; - Input segment data sets should not contain intersection points, except segment's endpoints. Information on why the first limitation is not sufficient is explained here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm The second limitation could be waved using native Boost.Polygon functionality: http://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_polygon_set_concept.htm Resources: The code is already merged with the Boost.Polygon sandbox branch. All the Voronoi related files are prefixed with "voronoi". - Code location: http://svn.boost.org/svn/boost/sandbox/gtl - Main documentation page: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm or http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm - Benchmarks: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_benchmark.htm - Examples: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/example/output_data/ - Tests: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/test/ - Tutorials: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm and http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm - Official Google+ page: https://plus.google.com/b/109395909314556242008/ Review manager: I would kindly ask Simonson, Lucanus J. the author of the Boost.Polygon library to be my review manager. PS. The library was designed in a user friendly way, so I would invite everyone to give it a try! No configuration of the geometric or predicate kernels is required. Simply follow the basic tutorial: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm Thanks and have fun, Andrii

11 86

[ratio] error in template specialization: template parameter n1 depends on another template parameter
by Krzysztof Czainski 04 Jul '12

04 Jul '12

Hello, In order to use Boost.Ratio with my poor compiler from TI, I had to apply the attached fix. I suspect a more general fix would be desirable, should such a fix be added to Boost. However, before investigating further, I'd like to ask, if such a fix would be welcome, or is my compiler too poor to be supported by Boost.Ratio? Regards, Kris

2 3

Large Integer Library
by Michael Tryhorn 03 Jul '12

03 Jul '12

Dear Boosters, I have written a Boost-compatible library for the representation and manipulation of integers of large or arbitrary size (including 128bit and above). I would like to make a preliminary submission of this library for your review and input, for potential inclusion into Boost v1.51.0 or later, as per the Boost Library Submission Process. The library and all its files are publicly available on github, at: http://github.com/mjtryhorn/Boost.LargeInt A tagged .zip of these files (v1.0.0) is available for download at: http://github.com/mjtryhorn/Boost.LargeInt/tags This library has been written for strict conformance to C++03 and the Boost coding guidelines. This library is also header-only, and as such may be directly merged into existing Boost installations without the need for recompilation. All files are distributed under the Boost Software License, Version 1.0. Now a quick explanation of why I've written this library and what it does: I have found myself on several occasions to be working with unsigned 64bit numbers, mostly for the sizes of files or C++ collections. Where I had a need to perform a calculation upon those numbers, there was often the possibility of overflow. 128bit integers would have been an appropriate fix, but these are either entirely unavailable, non-portable, or in a library which I preferred not to use either due to its complexity or incompatible licensing. Floating-point arithmetic is also a means around the problem, but is inherently inaccurate. I decided to fix this problem once-and-for-all by writing a new integer arithmetic library, making judicious use of C++'s template-metaprogramming and Boost to make my solution both as simple and as transparent as possible. Now, what started out as 128bit integers for my own use has grown into a fully- functional library which has the ability to compose any two integer or integer- like types into a new, larger, signed or unsigned integer type, including all the standard integral operators and a number of utility functions to support them. Thus, Boost.LargeInt supports not only signed and unsigned 128bit integer arithmetic but 24bit, 64bit, 160bit, 192bit, 256bit, 512bit and more. Boost.LargeInt is compatible and has been tested with the following compilers and platforms: GNU GCC 4.6.1, 4.6.2 (Linux, Ubuntu 11.10 (64bit) & openSUSE 12.1 (32bit)) Borland C++ 5.6.4 (Windows XP SP3, Borland C++ Builder 6) Microsoft Visual C++ 2010 (Windows XP SP3, Microsoft Visual Studio 2010) (I have also tried to add compatibility for Microsoft Visual C++ 6, but unfortunately this compiler's support for template-metaprogramming is insufficient and the tests for Boost.LargeInt fail to compile.) Documentation is included in BoostBook format (.qbk), but a pre-compiled version is available alongside the library code itself for your convenience. Please, if you have the time, download this library and give it a try. Any comments, or information upon its compatibility (or lack thereof) with compilers which are or are not listed would be greatly appreciated. If no-one has any comments (I think that unlikely ;-) ), then I shall resubmit this library for formal review. Thanks, Michael J. Tryhorn

9 20

[range] treating N-ary function with N-1 default args as unary
by Nathan Ridge 03 Jul '12

03 Jul '12

Hi, Some Boost.Range adaptors, such as 'transformed' or 'filtered', require a unary function. The documentation does not formally define "unary function", but it's pretty clear what it ought to be: a function (object) that's callable with one argument. Thus, to me, the following is a perfectly valid unary function: int foo(int a, int b = 0); as it is callable with one argument. However, Boost.Range does not accept such a function as an argument to 'transformed' or 'filtered'. For example, the following code: #include <boost/range/adaptor/transformed.hpp> int foo(int a, int b = 0); int main() { int A[5]; A | boost::adaptors::transformed(foo); } produces the following compiler errors (recent Boost trunk, with GCC 4.7): In file included from boost/preprocessor/iteration/detail/iter/forward1.hpp:52:0, from boost/utility/result_of.hpp:113, from boost/iterator/transform_iterator.hpp:23, from boost/range/adaptor/transformed.hpp:16, from test.cpp:1: boost/utility/detail/result_of_iterate.hpp: In instantiation of 'struct boost::detail::cpp0x_result_of_impl<int (* const(int&))(int, int)>': boost/utility/detail/result_of_iterate.hpp:46:8: required from 'struct boost::result_of<int (* const(int&))(int, int)>' boost/mpl/eval_if.hpp:38:31: required from 'struct boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::result_of<int (* const(int&))(int, int)>, boost::mpl::identity<boost::use_default> >' boost/iterator/iterator_adaptor.hpp:160:12: required from 'struct boost::detail::ia_dflt_help<boost::use_default, boost::result_of<int (* const(int&))(int, int)> >' boost/iterator/transform_iterator.hpp:50:17: required from 'struct boost::detail::transform_iterator_base<int (*)(int, int), int*, boost::use_default, boost::use_default>' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: recursively required from 'constexpr const bool std::__has_iterator_category_helper<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >::value' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: required from 'struct std::__has_iterator_category<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' c++/4.7.0/bits/stl_iterator_base_types.h:160:12: required from 'struct std::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/detail/iterator.hpp:81:8: required from 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp:30:75: required from 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/utility/detail/result_of_iterate.hpp:69:5: error: too few arguments to function In file included from boost/range/iterator_range_core.hpp:22:0, from boost/range/iterator_range.hpp:13, from boost/range/adaptor/transformed.hpp:15, from test.cpp:1: boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:30:75: error: no type named 'value_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_difference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:143:54: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:49:80: error: no type named 'difference_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_reference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:157:53: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:36:74: error: no type named 'reference' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' Would it be possible to treat N-ary functions with N-1 default arguments as unary? Thanks, Nate

6 8

Does Boost.Pool have a maintainer ?
by DUPUIS Etienne 03 Jul '12

03 Jul '12

Greetings, Does Boost.Pool have a maintainer ? If no, what happens in that case, who decides to include bug fixes for open bugs ? If there is no maintainer, can I become the maintainer ? If the answer to the latter question is yes, can someone volunteer to be my "mentor" to help me with issues related to the way boost development work ? I have already fixed pool bugs in the sandbox and added related test programs. Regards, Étienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

2 2

Is there a macro to test if std::numerc_limits<>::max_digits10 is supported by a platform?
by Paul A. Bristow 02 Jul '12

02 Jul '12

A proposed (but not reverted) fix for Trac #5758: Boost.Test Floating-point comparison diagnostic output does not support radix 10 if( std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 10 ) ostr.precision( 2 + std::numeric_limits<T>::max_digits10); // Assume that max_digits10 is provided for all radix 10 as they are quite new, // and anyway Kahan formula will not work for decimal. has caused trouble on platforms that do not yet support std::numeric_limits<T>::max_digits10 We need a macro perhaps BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 that will prevent the compiler seeing this code if max_digits10 is not supported. Do I need to add a default for all compilers # define BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 and then undefine for compilers that DO support #if defined (_MSC_VER >=1600) || (... other compilers that DO support) # undef BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 #endif Can anyone advise compiler versions or library versions that DO support max_digits10? Suggestions? Paul PS maxdigits10 will become more useful generally as the wrong value in float in MSVC 2011 seems to be corrected in Microsoft Visual Studio Ultimate 2012 RC 11.0.50522.1 --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 4

[contract] C++11-like auto-functions
by Lorenzo Caminiti 02 Jul '12

02 Jul '12

Hello all, I'm thinking to expand Boost.Contract to support C++11-like auto-functions for C++03. The following macro: CONTRACT_FUNCTION( // f template( typename Left, typename Right ) auto (adding_func) ( (Left const&) left, (Right const&) right ) return(BOOT_TYPEOF_TPL(left + right)) ) { return left + right; } Would expand to something like the code below (but the main of course): #include <boost/typeof/typeof.hpp> #include <iostream> template< typename Left, typename Right > // TPARAMS(f) struct adding_func_result_123 { Left const& left; // PARAMS(f) Right const& right; // PARAMS(f) typedef BOOST_TYPEOF_TPL(left + right) // RESULT_TYPE(f) type ; }; template< typename Left, typename Right > typename adding_func_result_123<Left, Right>::type // TPARAMS(f) adding_func ( Left const& left, Right const& right ) { return left + right; } int main ( void ) { std::cout << adding_func(1, 2) << std::endl; return 0; } I got a ticket for it: https://sourceforge.net/apps/trac/contractpp/ticket/59 But I might implement it only after the Boost review... (Are C++11 auto-function really useful?) Thanks. --Lorenzo

3 2

[thread/exception] trivial compile fix
by Tim Blechmann 02 Jul '12

02 Jul '12

the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1]. as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it? tim [1] https://svn.boost.org/trac/boost/changeset/75902

4 13

Re: [boost] Exact Decimal library
by Andrew Robb 02 Jul '12

02 Jul '12

I am proposing a Boost library for exact decimal numbers https://docs.google.com/document/d/19n-E8Mu-0MWCcNt0pQnFi2Osq-qdMDW6aCBweMK…<https://docs.google.com/document/d/19n-E8Mu-0MWCcNt0pQnFi2Osq-qdMDW6aCBweMK…> Message-ID: <33DFA071B6DD6D4FB44851BDE4A7259317128A(a)xchmbbal503.ds.susq.com> Andrew Robb wrote: > > Introduction [snip] > Exact Decimal [snip lots of information and reference links] The reason for your post is unclear. Are you proposing a Boost library? Are you asking for an indication of interest?

2 1

[geometry] distance on multiline with spherical coordinates
by Karsten Ahnert 01 Jul '12

01 Jul '12

Hi, the following code produces some strange results: typedef cs::spherical_equatorial< boost::geometry::degree > cs_type; typedef model::point< double , 2, cs_type > point_type; typedef model::linestring< point_type > linestring_type; point_type p( 1.0 , 1.0 ); linestring_type l; l.push_back( point_type( 0.0 , 2.0 ) ); l.push_back( point_type( 2.0 , 2.0 ) ); l.push_back( point_type( 4.0 , 2.0 ) ); cout << "Distance : " << boost::geometry::distance( p , l ) << endl; for( size_t i=1 ; i<l.size() ; ++i ) { linestring_type l_tmp; l_tmp.push_back( l[i-1] ); l_tmp.push_back( l[i] ); cout << "Point distance : " << boost::geometry::distance( p , l_tmp ) << endl; } The output is Distance : 0.0174373 Point distance : 0.0174586 Point distance : 0.0174373 This looks like a bug. The distance to the second segment can not be smaller than that to the first one. If I change the coordinate system to cartesian coordinates everything works as expected. Do I miss some major points?

2 7

Formal Review Request: TypeErasure
by Steven Watanabe 30 Jun '12

30 Jun '12

AMDG I'd like to request a formal review of the TypeErasure library that I've posted about several times before here. The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. As an example of basic usage, we can simulate Boost.Any: any<mpl::vector<copy_constructible<>, typeid_<> > > x(10); int i = any_cast<int>(x); // i == 10 The library is available in the Boost Sandbox at http://svn.boost.org/svn/boost/sandbox/type_erasure/ You can download archives with pre-built documentation from http://sourceforge.net/projects/steven-watanabe.u/files/ Online documentation can be found here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ In Christ, Steven Watanabe

26 118

[exception] Boost.Exception and the C++11 standard
by Vicente J. Botet Escriba 30 Jun '12

30 Jun '12

Hi, I was wondering how Boost.Exception works on compilers supporting 18.8.5 Exception propagation. Can an exception thrown by a 3pp library by retrieved by boost::current_exception() by another library or application code? BTW, what is the degree of compliance of Boost.Exception respect to 18.8.5 Exception propagation and 18.8.6 nested_exception sections of the standard? Do you have a plan towards been C++11 compliant? Best, Vicente P.S. I know that I can ask myself the same kind of questions respect to Boost.Ratio/Chrono/Thread, but this should be covered on a separate thread ;-)

2 1

Re: [boost] A GUI Library
by jinhao 30 Jun '12

30 Jun '12

On 2012/6/27 16:24, Klaim - Joël Lamotte wrote: > Hi, > > On Wed, Jun 27, 2012 at 2:55 PM, jinhao<cnjinhao(a)hotmail.com> wrote: > >> Is there any interest in this library? > > > My current understanding is that both Boost and the Standard C++ commitee > are interested in fully C++ library. > > However, the subject is complex and no library until now gathered > enough consensus to even get to the review stage of the boost process > (from memory). > You have to be ready for tons of feedback pointing problems. > > Now, I just read the websites but I have some questions: > > 1. can you write somewhere a big comparison between your library and other > popular GUI C++ libraries? Nana library is written though standard C++, this is a big difference between other libraries, as the brief mentioned, C++ idioms should works with a C++ library, and this is why the other popular GUI C++ libraries are not really C++ style at all. Secondly, this library can be work with a thread pool, it reduces the difficulty for threadization. > 2. if you want to submit your library to Boost, I think it would need to > be compatible (or maybe just use) boost.thread instead of your own solution I recognize that many ideas of my own solutions come from boost, not only boost.thread, there are boost.function, boost.any and so on, this is why I try to submit this library to boost and erase all my own solutions. > 3. the STR macro is a big problem, I think it will be a big source of > negative feedback. Now that we have boost.locale, would it be possible to > work with it instead? Somebody told me the problem before, I left the problem and searched a solution, I found many problem can be fixed by boost, and I rethink, can't keep on stealing ideas from boost. This is also why I try to submit this library to boost. > 4. I understand how you can build a GUI application in a way that is > mostly a list of statements. Does it means that you'd better organize your > windows/forms "types" as constructor functions? (ok found this that > partially answer my question: > http://nanaproject.wordpress.com/2012/01/31/idioms-and-insights-for-a-good-…) > 5. It is said that Nana is cross-platform, but I don't see any > demonstration of this (nevermind, I just found this: > http://nanaproject.wordpress.com/2012/05/16/tutorial-of-release-0-2-3/ ) > What are the target platforms? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now. > 6. Should it work in non-graphic contexts like command-line only display? > (I'm thinking about GUI working in bash for example) Yes, like ncurses. But now it is not able to work in such environment. > 7. Is it thought to be easily extendable? For example, can I write myself > a new front-end implementation and plug it in? The library provide a general method to implement a customer widget, and supports external image-processing algorithm implementation (http://nanaproject.wordpress.com/2012/04/17/an-introduction-to-the-image-pr…) > 8. do you have an available example of complex application being built > with this library? Yes, but its language is Chinese, it is a stock software, a screenshot at http://sourceforge.net/projects/stdex The status of this library I give is alpha and the so library is not used widely. Best Regards! Jinhao

5 6

Meeting C++ - Call for Papers
by Jens Weller 30 Jun '12

30 Jun '12

Dear C++/boost community! I'm proud to announce the call for papers for the Meeting C++ conference! After having talked to some people in Aspen about the plans for a C++ conference in Germany, I've decided to give it a try. Meeting C++ will take place in November in Germany, as a 2 Day C++ conference. We are looking for speakers and possible talks at our conference in fall! Possible topics could include: * (modern) C++ * C++11 * boost * C++ Frameworks like Qt, wxWidgets, Ogre, ... * other C++ related topics You'll find more information and updates at the webpage http://meetingcpp.com Tickets will be available from July at our website. regards, Jens Weller -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

2 2

[config] request for BOOST_NO_CXX11_HDR_ATOMIC
by Tim Blechmann 30 Jun '12

30 Jun '12

preparing boost.lockfree for trunk, i need a good way to figure out if the <atomic> header is available. would it be possible to add a macro to detect that? BOOST_NO_CXX11_HDR_ATOMIC or the like? thanks, tim

3 6

[smart_ptr] Patch for #6824
by Brent Lewis 30 Jun '12

30 Jun '12

Regarding bug report: https://svn.boost.org/trac/boost/ticket/6824 I've attached a diff file

3 2

[nowide] Updates and Standalone Version
by Artyom Beilis 30 Jun '12

30 Jun '12

Hello all Booster, Boost.Nowide updates: The library provides an implementation of standard C and C++ library functions such that their inputs are UTF-8 aware on Windows without requiring using Wide API to make program work on Windows. --------------------------------- I had updated the library: - Changed boost::nowide::convert to boost::nowide::widen, boost::nowide::narrow - Changed boost::nowide::args to restore an original values in destructor - Updated the docs. Also I had created a stand-alone version of the nowide library such that it does not require boost and can be build with CMake - the use is the same just change: #include <boost/nowide/foo.hpp> ... boost::nowide::fstream To #include <nowide/foo.hpp> ... nowide::fstream ------------ Looking forward for more comments on a library that I want to submit for a formal review. Library: Boost.Nowide Download: http://cppcms.com/files/nowide/nowide.zip Documents: http://cppcms.com/files/nowide/html/ Non-Boost: http://cppcms.com/files/nowide/nowide_standalone.zip Git Repo: git://cppcms.git.sourceforge.net/gitroot/cppcms/nowide Tested On: OS: Windows 7 32/64 bit, Linux Compilers: GCC-4.6, MSVC-10 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 7

[make_shared]
by Yuriy Zubritsky 30 Jun '12

30 Jun '12

Regarding https://svn.boost.org/trac/boost/ticket/6829 (make_shared is slower than shared_ptr(new) in MSVC) Does anyone want to apply it? It contains patch inside. Thanks

1 0

[BGL] How can I measure the memory used by a Boost graph ?
by ShNaYkHs ShNaYkHs 29 Jun '12

29 Jun '12

Hi, I have a graph defined as follow: struct NodeData{ /*...*/ }; struct EdgeData{ /*...*/ }; typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> MyGraph; MyGraph G; This graph is updated iteratively (by adding/deleting some edges/vertices). At each iteration, I want to evaluate the memory space occupied by this graph G. How can I do that ?

2 1