- Boost - lists.preview.boost.org

[OpenOffice] [Boost_Document_Library] [GSoC'15] Unable to compile and run the examples in the OpenOffice SDK
by Abhinav Tripathi 23 Apr '15

23 Apr '15

I know this question should be sent to OpenOffice forum. I sent it to their dev list but did not get any response so i am mailing it here in hope to get a response. . I downloaded The OpenOffice 4.1.1 deb files and Sdk 4.1.1 deb file... I used dpkg from command line to install all the deb files.. They got installed in /opt/openoffice4 and Sdk in /opt/openoffice4/sdk . I had to use deb files from the website because i couldn't download it from the apt-get... It showed errors like could not find... I am Using Ubuntu 14.10! When i tried to compile any example in /opt/openoffice4/sdk/examples/DevelopersGuide/ProfUNO/ i got many errors.. . To overcame some of these i did : 1. copied all files from /opt/openoffice4/sdk/bin/ to my root folder /bin/ because the error said /bin/cppumaker : command not found 2. Used a conf file to load all libraries in linux linker cache... using sudo ldconfig because g++ showed error that libreg.so.3 was not found! 3. copied the types.rdb file from sdk folder to my root folder / because it said something about registries not loaded. 4. made a few variables in the makefile like OO_SDK_HOME, JAVA_HOME, JAVA_BIN to allow compilation... 5. Made folder for each example in /opt/openoffice4/sdk/LinuxExamples.out/bin folder because g++ always gave the error that the there was no file or folder of the name of the example that i was compiling. . Now, i am able to compile the examples but when i try to run them with : make office_connect.run or anything like that then again i am getting errors regarding command not found. cd ../../../../LINUXexample.out/bin && office_connect /bin/sh: 1: office_connect: not found Makefile:100: recipe for target 'office_connect.run' failed make: *** [office_connect.run] Error 127 I think it is because of this line in the makefile : %.run: $(OUT_BIN)/%$(EXE_EXT) cd $(subst /,$(PS),$(OUT_BIN)) && $(basename $@) I have no experience of Makefiles and also i am new to openoffice sdk... I am guessing that these errors are happening beacause i installed the packages manually from dpkg instead of using apt-get... Also, i did use setsdkenv_unix once but i think it didnt work as expected as the variables in Makefile are NOT set.. . . It took me nearly a week to figure out these errors and now my patience is wearing out. I know that there has to be an elegant solution to this problem. Please help! . Abhinav

2 4

[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

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

[convert] Help. Need promotion from 'develop' to 'master'.
by Vladimir Batov 20 Apr '15

20 Apr '15

On 04/21/2015 05:38 AM, Edward Diener wrote: > On 4/20/2015 1:10 PM, Vicente J. Botet Escriba wrote: >> Le 20/04/15 00:09, Vladimir Batov a écrit : >>> Daniel James created an entry point for 'convert' in the Boost >>> 'develop' branch and 'convert' has been sitting there for quite some >>> time. Now that Boost 1.58.0 has been released I would like to have >>> 'convert' promoted from 'develop' to 'master' so that 'convert' would >>> make it to 1.59. Is there anything that *I* can/need to do to have an >>> entry point created for 'convert' in the Boost 'master' branch? >> I would start a new thread and add you review manager. It is the review >> manager that should check everything is okay. > I was the review manager for 'convert' and it was accepted into Boost. > It has been on 'develop' and been regression tested. > > I myself am not sure of the process of moving a library from 'develop' > to 'master' so maybe someone dealing with the boostorg/boost project > can comment. > > My educated guess is that it would involve a fork of boostorg/boost, a > local 'pull --rebase' from that fork, changes locally that add the > library submodule to 'master' with the necessary commit, a 'push' back > to the fork, and then a pull request so that it shows up at > boostorg/boost and eventually gets merged into the superproject. I > believe part of the local changes are also that status/jamfile.v2 has > to be changed so that the library's tests are added to it. I would expect the master-branch-related "procedure" to be the same as for "develop". As I understand, I myself cannot create an entry point for the library (which is reasonable) and Daniel did that for me in the develop branch. So, I suspect, someone with super-duper permissions would need to step in. Any help in the matter would be greatly appreciated. Tnx, V.

1 0

open for merge?
by Oliver Kowalke 20 Apr '15

20 Apr '15

Hello, is boost open for merging into branch master after the release (unfortunately no entry in the calendar as it was available for previous releases)? thx, Oliver

1 0

DLL library: In search for Review Manager
by Antony Polukhin 20 Apr '15

20 Apr '15

Hi, Boost.DLL library seems ready, users use it and do not complain. Is there anyone wishing to help with review and become a Review Manager? Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol Github: https://github.com/apolukhin/Boost.DLL Docs: http://apolukhin.github.io/Boost.DLL/index.html -- Best regards, Antony Polukhin

4 6

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

20 Apr '15

> Message: 11 > Date: Mon, 20 Apr 2015 13:22:35 +0300 > From: Andrey Semashev <andrey.semashev(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: <1988978.ROPBOsQPor@lastique-pc> > Content-Type: text/plain; charset="us-ascii" > On Monday 20 April 2015 11:04:22 THOMAS JORDAN wrote: > > Hi, > > I'd like to gauge whether there might be any interest in a new Boost > > library comprising a generic, non-intrusive, wrapper class for creating > > immutable/const values with sharing of the underlying object via internal > > reference counting. > 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. 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. 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. 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.

2 1

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

20 Apr '15

Vin?cius dos Santos Oliveira: > I recently submitted an HTTP server library to Boost Incubator and I'd > appreciate feedback: > http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460 <http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460> > > I intend to submit to Boost later. > > This is the library that I developed during GSoC 2014 and I made several > improvements (new features, bug fixes, better and extended > documentation...) after the end of GSoC. There are a few improvements that > I still want to do, but none of them would be a barrier for Boost > integration, in my opinion. > > This library doesn't have a builtin request router, opposed to several > libraries out there, then you can use whatever routing style you wish > (tree-based, middleware-based, no router...). > > Also, it follows Boost active style, then you can build your own scheduler > around it (prioritize requests from certain IPs, defer acceptance of new > connections during server high load, reuse prior constructed objects...). > > The library follows Asio threading model, then you also choose whether you > will handle all requests from the same thread (useful for embedded devices) > or multiples ones. The library is fully async, then one thread is not a > problem. > > It has a powerful and flexible file server API, supporting range-based > requests, conditional requests, support for ETags and so on. > > After the GSoC, I had the chance to add tests for asynchronous abstractions > and now the implementation is much more trustable and stable. The choice to > reuse an existing HTTP parser (the Node.js's C parser) also helps a lot. > > The simple message-based API helps to support HTTP pipelining, allocation > fine tuning and much more. Besides HTTP pipelining, HTTP chunking (and > other modern features like 100-continue and HTTP Upgrade) are also > supported. > Do you have any users? If you don't have users, I suggest you become the first user by developing an application. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

4 3

Boost.locale update
by Maks Naumov 20 Apr '15

20 Apr '15

Any plans to update the Boost.Locale ? In https://github.com/boostorg/locale/pulls there are some fixes.

1 0

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

20 Apr '15

Hi, I'd like to gauge whether there might be any interest in a new Boost library comprising a generic, non-intrusive, wrapper class for creating immutable/const values with sharing of the underlying object via internal reference counting. This new class would be called ValueRef (or possibly just Value), and it would effectively provide an assignable/swappable 'reference'/handle to shared, const values. It can be considered an effective alternative to the commonly used shared-pointer-to-const idiom, providing cleaner and more explicit value semantics, whilst also hiding calls to 'new' as an internal implementation detail. In a nutshell, ValueRef adapts a regular type T to give a new type ValueRef<T> with const T value semantics and uses reference counting of an underlying object on the heap internally to reduce copying overhead. ValueRef will spawn off a new copy of the wrapped object (if necessary) if the ValueRef is assigned another ValueRef or another object of type T. Const functions of T do not incur any overhead of counter access or copy and are invoked by either * or -> syntax. Forwarding constructors are provided which permit the wrapped value to be constructed in place, and conversion operator allows inter-operation with values of the unwrapped type. ValueRef also provides the common relational operators. I have so far implemented a rough (C++03-only so far) version of this (based on a stripped down version of Adobe::copy_on_write library) and a test suite and it seems to work okay. Example usage: /* type of ValueRef wrapped std::vector<int> */ typedef ValueRef<std::vector<int> > ValueRefVecType; /* create vector of 10 elements via forwarding constructor */ ValueRefVecType valueRefVector1(10,1); /* non-mutating/const op */ assert( valueRefVector1->size() == 10 ); /* non-mutating/const op */ assert( (*valueRefVector1)[0] == 1 ); /* error - compilation failure occurs calling a non-const op */ (*valueRefVector)[0] = 2; /* copy ctor */ ValueRefVecType valueRefVector2(valueRefVector1); /* test for equality */ assert( valueRefVector1 == valueRefVector2 ); /* test for equality (implicit conversion) */ assert( valueRefVector2 == std::vector<int>(10,1) ); /* valueRefVector1 and valueRefVector2 share same std::vector */ assert( valueRefVector1.identity(valueRefVector2) ); /* ref count is no longer one */ assert( !valueRefVector1.unique_instance() ); /* new value */ valueRefVector1 = std::vector<int>(5); /* non-mutating/const */ assert( valueRefVector1->size() == 5 ); /* test for equality - value semantics */ assert( !(valueRefVector1 == valueRefVector2) ); /* valueRefVector1 and valueRefVector2 do not share same std::vector */ assert( !valueRefVector1.identity(valueRefVector2) ); I am not aware of anything else current that provides this functionality. Regards, Tom

3 2