April 2015 - Boost - lists.preview.boost.org

[Git] Pull requests and rebasing
by John Maddock 22 Apr '15

22 Apr '15

So I have a rebase vs pull question: Lets say I have a PR, if I merge that to my local tree using "git pull --rebase remote-repro branch-name" then I get a nice clean history locally without those pesky merge commits cluttering everything up. But... Now I can't fast-forward when I push to the remote, *because I've changed the existing history of the develop branch*. Would this not be a) bad form, and b) potentially dangerous to push to the remote develop branch? Still don't understand Git yours, John.

6 7

[typeof][CMT] Could the maintenance team please review and merge a trivial pull request?
by Adam Wulkiewicz 22 Apr '15

22 Apr '15

Hi, There is one trivial PR hanging for nearly a year now: https://github.com/boostorg/typeof/pull/1 In those 2 lines of code namespace boost was explicitly added in front of enable_if and disable_if. This allows msvc8 to compile the tests when Boost.Test and Boost.TypeOf are both used. Could you please have a look at it? Regards, Adam

3 4

Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing?
by Thomas Jordan 22 Apr '15

22 Apr '15

> Message: 2 > Date: Mon, 20 Apr 2015 15:40:37 +0100 > From: Sam Kellett<samkellett(a)gmail.com> > > To:boost@lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for > immutable values with internal sharing? > Message-ID: > <CAHK+-Fsy1-sCuMuz+hpjNC2ogAbxUazNY0Qt3xL__bndzkwduw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > I had a similar idea for a new smart pointer that would aim to obsolete the > shared_ptr-to-const idiom. The problem I found with that idiom is that it > only guarantees that you can't change it. There's no promise that somebody > else doesn't have a non-const ref to the data and so it could in the worst > case completely change from under your feet (even if you know it won't get > destroyed). ValueRef doesn't expose (shared) pointers/pointees, they are a hidden, implementation detail. Its interface just deals in values (as shown in the example usage).

3 2

Re: [boost] [ValueRef]
by THOMAS JORDAN 22 Apr '15

22 Apr '15

> Message: 7 > Date: Tue, 21 Apr 2015 15:37:56 +0000 (UTC) > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] > Message-ID: <loom.20150421T164358-569(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > THOMAS JORDAN <tomjordan766 <at> gmail.com> writes: > > > > > Message: 7 > > > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > Boost.Flyweight uses move semantics and perfect fwd ction where > > > available, > > > I don't see how another solution can do better on this front > > > > Agreed, I'll withdraw that statement. However, as I said in the O.P., the > > ValueRef implementation I have done is currently only C++03. It uses a > > combination of N x forwarding constructor overloads taking arguments by > > const reference, and the client can use reference wrappers to forward to > > lvaluesto do the non-perfect forwarding (as boost.shared_ptr make_shared > > does) . The intention in the final library would be to support > > C++11/perfect forwarding and possibly Boost.Move for C++03 move semantics. > > So they would be equivalent in that regard. > Understood. Boost.Flyweight does in fact this something similar, > you might want to take inspiration from > http://boost.org/boost/flyweight/detail/perfect_fwd.hpp > > > Boost.Flyweight is indeed heavier on the include side than some > > > people might be comfortable with. > > > > I think this is my concern with having Boost Flyweight as the only option > > for what is a relatively simple type. ValueRef is currently about 350 > > lines of easy-to-understand code in a single header file, and has no > > dependencies on MPL or any other Boost or std libraries, with the > > exception of an atomic library. > > It is intended in particular as a lightweight, clean replacement for > > shared-ptr-to-const, which I see used a lot in code [...] > Of course I don't want to disregard the merit of a lightweight approach > to implementing this idiom. I'm curious: why are you implementing > this from scracth, using atomic etc. rather than wrapping > boost::shared_ptr? The latter, seems to me, is going to be much less > code on your side and the dependencies on the lib are not that many: > http://www.pdimov.com/tmp/report-b1adfee/smart_ptr.html I was inaccurate when I said that ValueRef did not depend on any std libraries, in fact it depends on <memory> for std::allocator<T>. I've modified it to use boost::shared_ptr and boost::allocate_shared (though still just with C++03 forwarding constructors at the moment) - it was trivial, and reduces the LOCS by ~half. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom

1 0

Re: [boost] [Boost-bugs] [Boost C++ Libraries] #11225: failed to compile with msvc8, variadics used wrong
by Damien Buhl 22 Apr '15

22 Apr '15

Thanks Flast, Normally only warnings should be generated. Did you had warnings as errors active? Original Message ‎ From: Boost C++ Libraries Sent: mercredi 22 avril 2015 15:32 Reply To: boost(a)lists.boost.org Cc: boost-bugs(a)lists.boost.org Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11225: failed to compile with msvc8, variadics used wrong #11225: failed to compile with msvc8, variadics used wrong -------------------------+------------------------------------------------- Reporter: | Owner: djowel ingo.loehken@… | Status: new Type: Bugs | Component: fusion Milestone: To Be | Severity: Regression Determined | Keywords: BOOST_PP_IS_EMPTY, phoenix vector, Version: Boost | variadics, vs2005, mscv8 1.58.0 | Resolution: | -------------------------+------------------------------------------------- Comment (by Kohei Takahashi <flast@…>): rels. to #11157 -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/11225#comment:1> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries. _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-bugs

2 1

[thread] Windows compilation broke with 8853a4c
by Jürgen Hunold 22 Apr '15

22 Apr '15

Hi Vicente, the commit 8853a4cbdf34d2699d7997ea99adf62fe9d6d568 broke compilation on windows: compile-c-c++ E: \dev\devel\boost\bin.v2\libs\thread\test\test_barrier_void_fct.test\msvc-12.0\debug\test_barrier_void_fct.obj test_barrier_void_fct.cpp E:\dev\devel\boost\boost/thread/win32/condition_variable.hpp(344) : error C2039: 'is_pos_infinity' : is not a member of 'boost::xtime' E:\dev\devel\boost\boost/thread/xtime.hpp(35) : see declaration of 'boost::xtime' E:\dev\devel\boost\boost/thread/win32/condition_variable.hpp(349) : error C2039: 'is_special' : is not a member of 'boost::xtime' E:\dev\devel\boost\boost/thread/xtime.hpp(35) : see declaration of 'boost::xtime' It seems you are calling Boost.DateTime special functions on boost::xtime variables. I'm not sure on how to fix this. The change has not been pickup by the regression matrix yet. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

1 0

[github] contribution activity not updated
by Joaquin M Lopez Munoz 22 Apr '15

22 Apr '15

Hello, Not that this is very important, but seems like, at least for my GitHub user account, the contribution dashboard is not being updated: if you go to the bottom of https://github.com/joaquintides you'll see the dashboard says I haven't committed anything since Feb 23, which is certainly not the case. Just reporting here in case this might be a symptom of some more serious internal problem with the tool or the repository. Joaquín M López Muñoz Telefónica

2 2

[iostreams] Bogus gzip_alloc in gzip_test.cpp
by Stephan T. Lavavej 21 Apr '15

21 Apr '15

Hi, While testing VC 2015 with Boost, we've discovered a bug in Boost.Iostreams' tests. boost_1_58_0\libs\iostreams\test\gzip_test.cpp contains: struct gzip_alloc : std::allocator<char> { }; This doesn't conform to C++98-17's allocator requirements, because it isn't properly rebindable. (The Standard has always required that rebinding MyAlloc<T> to U and back to T produces MyAlloc<T>.) Thanks, STL

1 0

[polygon] polygon_traits.hpp is incompatible with C++17 std::size()
by Stephan T. Lavavej 21 Apr '15

21 Apr '15

Hi, While testing VC 2015 with Boost, we found that Boost.Polygon contains unqualified calls to non-member size() which are incompatible with C++17's std::size(). Specifically, lines 617 and 703 of boost\polygon\polygon_traits.hpp say: points.reserve(size(polygon)); The argument appears to be "typedef std::list<CPoint> CPolygon;" which is why ADL is considering std::size(). (Note that VC's current lack of Expression SFINAE is not relevant here, as std::size() is viable for std::list.) Here's the full error output (including a new shadow warning): C:\Temp>cl /EHsc /nologo /W4 /wd4100 /MTd /I C:\Temp\boost-1.58.0\include boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp gtl_custom_polygon.cpp Unknown compiler version - please run the configure tests and report the results c:\temp\boost-1.58.0\include\boost\polygon\detail/property_merge.hpp(286): warning C4458: declaration of 'output' hides class member c:\temp\boost-1.58.0\include\boost\polygon\detail/property_merge.hpp(223): note: see declaration of 'boost::polygon::merge_scanline<coordinate_type,property_type,polygon_set_type,keytype>::output' c:\temp\boost-1.58.0\include\boost\polygon\detail/property_merge.hpp(584): note: see reference to class template instantiation 'boost::polygon::merge_scanline<coordinate_type,property_type,polygon_set_type,keytype>' being compiled c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(617): error C2668: 'boost::polygon::size': ambiguous call to overloaded function c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(478): note: could be 'unsigned int boost::polygon::size<polygon_type>(const T &)' with [ polygon_type=CPolygon, T=CPolygon ] \\vcfs\builds\VS\feature_WCFB01\1457423\binaries.x86ret\inc\xutility(1347): note: or 'unsigned int std::size<polygon_type>(const _Container &)' [found using argument-dependent lookup] with [ polygon_type=CPolygon, _Container=CPolygon ] c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(617): note: while trying to match the argument list '(CPolygon)' boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp(38): note: see reference to function template instantiation 'std::list<CPoint,std::allocator<_Ty>> &boost::polygon::convolve<Polygon,CPoint>(polygon_type &,const point_type &)' being compiled with [ _Ty=CPoint, Polygon=CPolygon, polygon_type=CPolygon, point_type=CPoint ] boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp(144): note: see reference to function template instantiation 'void test_polygon<CPolygon>(void)' being compiled c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(703): error C2668: 'boost::polygon::size': ambiguous call to overloaded function c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(478): note: could be 'unsigned int boost::polygon::size<polygon_type>(const T &)' with [ polygon_type=CPolygon, T=CPolygon ] \\vcfs\builds\VS\feature_WCFB01\1457423\binaries.x86ret\inc\xutility(1347): note: or 'unsigned int std::size<polygon_type>(const _Container &)' [found using argument-dependent lookup] with [ polygon_type=CPolygon, _Container=CPolygon ] c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(703): note: while trying to match the argument list '(CPolygon)' boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp(40): note: see reference to function template instantiation 'std::list<CPoint,std::allocator<_Ty>> &boost::polygon::scale_up<Polygon>(polygon_type &,boost::polygon::coordinate_traits<int>::unsigned_area_type)' being compiled with [ _Ty=CPoint, Polygon=CPolygon, polygon_type=CPolygon ] Thanks, STL

1 0

Re: [boost] Feedback on Boost.Http
by Brian Wood 21 Apr '15

21 Apr '15

Bjorn Reese writes: > I am using Boost.Http in an embedded application, albeit work on the > integration has been slow due to company priorities. I see. Perhaps the author of the library would be willing to support you in that rather than creating his own applications. That's how I hope to do things also - http://webEbenezer.net/about.html . -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

1 0