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

[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

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

21 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 Ok > > > 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 There is no compelling reason why I shouldn't use shared_ptr. The first implementation I did of ValueRef was just a small modification to Adobe's C++03 copy_on_write library, because I had already been playing with that class, it was fairly quite simple and just involved: adding the forwarding constructors; removing the dependencies on the other (Adobe and Boost) libraries; changing the wrapped type to const T; removing the non-const write() function. I operate in a fairly constrained environment, and I generally like the idea of minimising dependencies, however, as you imply, there is no point reinventing the wheel (for example shared_ptr/make_shared would already provide most of the solution for the dual C++03/11 support for forwarding constructors, etc.). Furthermore, I'd guess using shared_ptr might help facilitate submission generally. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom

1 0

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

21 Apr '15

> Message: 7 > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] > Message-ID: <loom.20150420T202848-660(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > THOMAS JORDAN <tomjordan766 <at> gmail.com> writes: >> > > > From: Andrey Semashev <andrey.semashev <at> gmail.com> > > > > > Is this similar to Boost.Flyweight? > > > > It is similar in that both provide a 'smart' handle which can be used > > pretty much as a drop in for the wrapped type. > > > > However, Boost.Flyweight requires the wrapped type to be hashable. > Not necessarily; set_factory, for instance, requires values to > be less-than comparable: > http://boost.org/libs/flyweight/doc/tutorial/configuration.html#set_factory Ok > Also, see below. > > Also, there is a level of indirection with Flyweight which can mean that > > unnecessary temps may need to be created to do the initial lookup (and > > addition) to the Flyweight store, unless you use the Flyweight key-map > > interface. > 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. > > ValueRef does not use 'flyweighting.' That is, if there are two > > ValueRefs created independently with the same value, e.g., > > > > ValueRef<std::vector<int> > v1(10,10), v2(10,10); > > > > there will be two separate wrapped vector<int> objects - it is only when > > copying/assigning that sharing takes place. It is simpler than Flyweight > > and is essentially intended to be a more value-orientated option to > > shared-ptr-to-const. > The lib is extensible to the point that ValueRef can potentially be > built on top of it: > template<typename Entry,typename Key> > struct ValueRefFactory > { > using handle_type=Entry*; > template <typename E> > handle_type insert(E&& x){return new Entry{std::forward<E>(x)};} > void erase(handle_type h){delete h;} > const Entry& entry(handle_type h){return *h;} > }; > template<typename T> > using ValueRefImpl=flyweight< > T,no_locking, > factory<ValueRefFactory<boost::mpl::_1,boost::mpl::_2>>>; > template<typename T> > struct ValueRef:ValueRefImpl<T> > { > using impl_type=ValueRefImpl<T>; > const impl_type& impl()const{return *this;} > using impl_type::impl_type; > ValueRef(const ValueRef&x):impl_type(x.impl()){} > ValueRef(ValueRef&x):impl_type(x.impl()){} > ValueRef(const ValueRef&&x):impl_type(x.impl()){} > ValueRef(ValueRef&&x):impl_type(x.impl()){} > using impl_type::operator=; > const T& operator*()const{return this->get();} > const T* operator->()const{return &this->get();} > bool identity(const ValueRef& x)const{return &**this==&*x;} > }; > See complete example at: > http://coliru.stacked-crooked.com/a/c33389766fac6ecb > (except the unique_instance bit, which can be done, but admittedly > with more effort). > > Another (less significant) difference is that ValueRef > > currently has no dependency on MPL, which I believe Flyweight does, though > > that could well change if needed. > 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. I also unfortunately y see shared-ptr-to-non-const being used a lot when people should be using shared-ptr-to-const, which is less safe and makes it much harder to reason about what is going on. ValueRef is an explict, consistent and safe alternative to such (mis)usages, and would also sit more comfortably with people who have concerns about build times, library-dependencies and cross-platform issues, etc. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom.

2 1

Configuration error on BenPope x86_64 Ubuntu - clang-linux-3.6~tsan~c14_libc++?
by Vicente J. Botet Escriba 21 Apr '15

21 Apr '15

Hi, There are some reported errors that seems to be associated to the configuration of the tester E.g. http://www.boost.org/development/tests/develop/developer/output/BenPope%20x… /home/ben/development/boost/test/build/results/boost/bin.v2/libs/chrono/test/test_7868_d.test/clang-linux-3.6~tsan~c14_libc++/debug/address-model-64/architecture-x86/test_7868_d: symbol lookup error: /home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1: undefined symbol: __tsan_unaligned_read16 Please, could you check it? Best, Vicente

2 3

Generating documentation
by Alain Miniussi 21 Apr '15

21 Apr '15

Hi, Just curious, has anyone been able to get the documentation generated (on a linux platform) by following the instructions in http://www.boost.org/doc/libs/1_58_0/doc/html/boostbook/getting/started.html ?? Alternatively, is there a place where the documentation is generated for develop and/or master branch ? Thanks Not that the error messages make much sense, but FWIW, right now, I'm stuck with: [alainm@tagir doc]$ ../../../b2 html Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) /gpfs/scratch/alainm/view/modular-boost/tools/build/src/tools/boostbook.jam:683: in construct warning: object is empty /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:1336: in class(a)basic-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:757: in generate-really /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:729: in class(a)main-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:272: in class(a)project-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build-system.jam:707: in load /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/modules.jam:289: in import /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /gpfs/scratch/alainm/view/modular-boost/boost-build.jam:17: in module scope /gpfs/scratch/alainm/view/modular-boost/tools/build/src/tools/boostbook.jam:693: in construct warning: object is empty /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:1336: in class(a)basic-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:757: in generate-really /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:729: in class(a)main-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:272: in class(a)project-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build-system.jam:707: in load /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/modules.jam:289: in import /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /gpfs/scratch/alainm/view/modular-boost/boost-build.jam:17: in module scope /gpfs/scratch/alainm/view/modular-boost/tools/build/src/tools/boostbook.jam:707: in construct warning: object is empty /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:1336: in class(a)basic-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:757: in generate-really /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:729: in class(a)main-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:272: in class(a)project-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build-system.jam:707: in load /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/modules.jam:289: in import /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /gpfs/scratch/alainm/view/modular-boost/boost-build.jam:17: in module scope ...found 1 target... [alainm@tagir doc]$ -- --- Alain

2 4

Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing?
by THOMAS JORDAN 21 Apr '15

21 Apr '15

> Message: 2 > Date: Tue, 21 Apr 2015 10:33:26 +0100 > From: Sam Kellett <samkellett(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for > immutable values with internal sharing? > Message-ID: > <CAHK+-Fu6aYO2UwNkSvJWpn6UzmLjr+qNu+K3x8OSto8dyYGSBA(a)mail.gmail.com > > Content-Type: text/plain; charset=UTF-8 > On 20 April 2015 at 18:07, Thomas Jordan <tomjordan766(a)gmail.com> wrote: > > 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). > Absolutely! Hence the ref in the name. :) > I kept the pointer as part of the interface seeing as I saw it as a smart > pointer to replace another smart pointer, but either direction is not wrong > for sure. > The thing I like about the schrodinger_ptr is that I can carry on mutating > it while nobody else is looking, it seems with yours you would have to add > all data to it on it's construction, is that right? Yes, it is an immutable value with sharing of the underlying value object, that is pretty much the gist of it

1 0

Missing 1.58.0 tag on github.com
by Florent Guiliani 21 Apr '15

21 Apr '15

Hi, The release tag for Boost 1.58.0 is missing on github.com: https://github.com/boostorg/boost/releases Could someone please push the tag on github.com ? -- Florent

1 0

Re: [boost] [Boost-bugs] Fwd: [Boost C++ Libraries] #11211: Fusion example no longer compiles
by Joel de Guzman 21 Apr '15

21 Apr '15

Yes we should. This is a showstopper. On 4/21/15 3:06 PM, Damien Buhl wrote: > Sorry for this message, I just saw after sending that Flast already > replied about the problem : > > https://svn.boost.org/trac/boost/ticket/11211?replyto=3#comment:3 > > Shouldn't we make some bugfix release ? Because it is a seriously weird > issue. > > On 21/04/2015 09:01, Damien Buhl wrote: >> Hi Joel, >> >> Thanks for forwarding. >> >> Looks like the support for BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED was >> added to DEFINE_STRUCT in a too strong way, which makes it impossible to >> use non-constexpr enabled types (namely std::string). >> >> I think the problem comes from the addition of BOOST_CONSTEXPR where >> BOOST_FUSION_GPU_ENABLED already was. >> >> In this commit >> https://github.com/boostorg/fusion/commit/2114bfca6c8d5e4f7fe2439346e1feddf… >> >> there is BOOST_CONSTEXPR added for the constructors and assignment >> operators. >> >> I think we have to remove the constexpr for this part, because we cannot >> add the requirements that the types the users gives to DEFINE_STRUCT are >> valid within constant expression. >> >> It also didn't come out by unit-tests runs, because our test are only >> done with int types. We have to add types which aren't constant-enabled >> to the tests for DEFINE_STRUCT and by the way for ADAPT also. >> >> I understand the idea behind adding BOOST_CONSTEXPR everywhere where >> BOOST_FUSION_GPU_ENABLED was, but actually it's not the same : on GPU >> there isn't any scenarii where one uses std::string I think, while it is >> typical in normal execution platform, and by the way BOOST_CONSTEXPR >> shouldn't be in this file. >> >> I've pushed a small commit where it then compiles for me on clang + g++ >> with C++03,11,14 : >>> https://github.com/boostorg/fusion/compare/boostorg:master...daminetreg:fea… >> >> >> Cheers, >> >> -- >> Damien Buhl >> >> On 20/04/2015 21:18, Joel de Guzman wrote: >>> Hello Kohei, Damien, >>> >>> Uh oh. Do you know what's happening here? >>> I'm getting: >>> >>> Constexpr constructor never produces a constant expression >>> >>> How did this slip? >>> >>> -------- Forwarded Message -------- >>> Subject: [Boost C++ Libraries] #11211: Fusion example no longer compiles >>> Date: Mon, 20 Apr 2015 19:01:29 -0000 >>> From: Boost C++ Libraries <noreply(a)lists.boost.org> >>> CC: boost-bugs(a)lists.boost.org >>> >>> #11211: Fusion example no longer compiles >>> -----------------------------------------------------+--------------------- >>> Reporter: Adrián Etchevarne <adrian.etchevarne@…> | Owner: djowel >>> Type: Bugs | Status: new >>> Milestone: To Be Determined | Component: fusion >>> Version: Boost 1.58.0 | Severity: Problem >>> Keywords: fusion | >>> -----------------------------------------------------+--------------------- >>> From the manual: >>> >>> {{{ >>> >>> #include <string> >>> #include "boost/fusion/adapted/struct/define_struct.hpp" >>> >>> // demo::employee is a Fusion sequence >>> BOOST_FUSION_DEFINE_STRUCT( >>> (demo), employee, >>> (std::string, name) >>> (int, age)) >>> >>> >>> int main() >>> { >>> } >>> >>> }}} >>> >>> It fails to compile with boost 1.58. With boost 1.57, compiles >>> successfully. >>> >>> g++ --std=c++11 test.cpp -I /home/saknussemm/downloads/boost_1_58_0 >>> >>> clang fails with a similar error. >>> >> _______________________________________________ >> Boost-bugs mailing list >> Boost-bugs(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-bugs >> -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

1 0