- Boost - lists.boost.org

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

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