- Boost - lists.preview.boost.org

[ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by ThePhD 28 Jun '18

28 Jun '18

Dear Boost Community, I was encouraged to submit this small library that I had created as a formal public investigation of the performance and API-interop benefits to the Boost Mailing List, to perhaps see if other people have come up with something similar to this at their own comapnies. out_ptr is a small abstraction for making types such as std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming std::retain_ptr <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work work C-Style output functions as a parameter, addressing the need of wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's design is meant to be extensible by both the library implementer and the user, enabling it to be used with other pointer types that do not originate from either `boost::` or `std::`. The library replaces the sought-after syntax of: my_c_api_init( foo, bar, &my_start_ptr ); with a free function that does not impose on the interface of the smart pointer: my_c_api_init( foo, bar, out_ptr( my_smart_ptr ) ); This makes it possible to use a temporary return value to give a reference to a pointer value that then performs a reset on the smart pointer. Is there any want for something like this? I know it has seen use at companies and Studios I have worked in and interacted with, including Microsoft and VMWare. std::retain_ptr's author also has a need for this to make interop easier with reference-counting C APIs and beyond, and I myself implemented something like it 5 years ago and have been using it ever since. Sincerely, JeanHeyd P.S.: this is also going to end up going in the Post-Rapperswil Standards C++ Mailing as well. The proposal is also contained in the repository: https://rawgit.com/ThePhD/out_ptr/master/papers/d1132.html

1 0

[release] 1.68.0 closed for major changes
by Marshall Clow 28 Jun '18

28 Jun '18

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/ history/boost_1_68_0.qbk> After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Thanks, -- The Boost Release Team

1 0

[Boost PP] MSVC PP
by degski 28 Jun '18

28 Jun '18

We seem to be getting there. Visual Studio 2017 version 15.8 Preview 3 Announcement <https://blogs.msdn.microsoft.com/visualstudio/2018/06/26/visual-studio-2017…> tl:dr: "*C++ Standards:* A new, experimental, token-based preprocessor that conforms to C++11 standards (including C99 preprocessor features), enabled with /experimental:preprocessor switch. This will be controlled with macro _ *MSVC*_TRADITIONAL, which will be defined to 1 when using the traditional preprocessor and 0 when using the new experimental standards conformant preprocessor." degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

4 4

[release]
by Zach Laine 27 Jun '18

27 Jun '18

I'm seeing a difference in the Yap Quickbook build in a local checkout of boost-with-submodules, develop branch, and the Circle CI develop build. The auto-index seems to be wrong in the Circle CI one: https://www.boost.org/doc/libs/develop/doc/html/yap.html Note that the stuff at the bottom of that page refers to content in other libs. The Reference section also points to the wrong stuff in the .hpp detail pages. When I originally moved Yap over to Boostorg, I did not initially update all the paths correctly for an integrated Boost build; I was doing a standalone doc build. I have since fixed the paths, and I see the right index and Reference sections when I build locally. I suspect that the Circle CI cache has some files lying around that are causing this problem, but I don't really know. Does anyone have any insight into this problem? Does anyone have admin rights to do a Circle CI rebuild-without-cache? Thanks, Zach

1 0

[Library idea] Type-safe Flagsets
by Julien Vernay 27 Jun '18

27 Jun '18

Hello everybody, I want to know if some people are interested in a type-safe flagsets. I define flagsets as a container similar to a bitset, but where each bit has a meaning. For example, we could have in some game : enum Direction : unsigned { UP = 0b0001, DOWN = 0b0010, LEFT = 0b0100, RIGHT = 0b1000 }; ... unsigned player_dir = UP | RIGHT; if ((player_dir & (UP|LEFT)) == (UP|LEFT)) player.setAnim("up_left"); player_dir &= ~UP; //removing UP from player_dir I think there are some issues with this kind of flagset : - you need to think about power-of-twos when attributing values to your flags. - you need to use bitwise operations which can be non-trivial, even for removing only one flag. - it is not safe: for example with another flagset using the flag INIT_VIDEO (in a window library like SDL), you can do " UP | INIT_VIDEO " even if the two flagsets have nothing in common With a type-safe flagset library, this code would become : namespace Direction { struct UP; struct DOWN; struct LEFT; struct RIGHT; using Type = flagset<unsigned, UP, DOWN, LEFT, RIGHT>; //unsigned is the underlying type }; ... auto player_dir = Direction::Type::Value<Direction::UP, Direction::RIGHT>(); if (player_dir.allOf<Direction::UP,Direction::LEFT>()) player.setAnim("up_left"); player_dir.reset<Direction::UP>(); It is more verbose but also more safe and easy to use. I actually have a partial implementation on GitHub, supporting read, write and conversions to strings : https://github.com/J-Vernay/flagset I would like to know if some people are interested in this kind of library, and if yes, what they think about the current syntax/implementation. Thanks for reading !

3 8

Re: [boost] On Boost's logo copyright
by Mateusz Loskot 25 Jun '18

25 Jun '18

(CC to boost(a)lists.boost.org) On 25 June 2018 at 22:03, Giovanni Mascellani <gio(a)debian.org> wrote: > Il 25/06/2018 14:33, Mateusz Loskot via Boost ha scritto: >> AFAICT, the logo design was established around Boost 1.33. >> Here is related note from the release notes [1] >> >> ``` >> Rene Rivera for the new Boost web page design; and Zoltan >> "cad" Juhasz for the new Boost logo. >> ``` > > This is very useful, thank you! You're welcome. I hope I've pulled the actual facts. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

On Boost's logo copyright
by Giovanni Mascellani 25 Jun '18

25 Jun '18

Dear Boost developers, I am preparing the next upload of Boost package in Debian. I would appreciate your help on a little detail, which is however very important for Debian (if this is not the right place to ask, please accept my apologies and direct me to a more appropriate one): who is the copyright holder of Boost's logo? I understand that it is licensed under the BSL license, but it seems to me that the name of the rights holder is not listed anywhere. Thanks for your help and for the great library, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

2 1

[release][yap] Master archive builds broken.. for a long time.
by Rene Rivera 24 Jun '18

24 Jun '18

While checking to see that the master PRs I did yesterday to master where not causing problems I noticed something unrelated. Looks like the master archive build has been failing for a long time now. Seems the addition of YAP is broken. It appears there's some documentation files missing: /home/ubuntu/build/boost/bin.v2/doc/gcc-4.8/debug/auto-index-on/threadapi-pthread/src/boost.auto_index.docbook:65535: element include: XInclude error : could not load /home/ubuntu/build/boost/bin.v2/doc/gcc-4.8/debug/auto-index-on/threadapi-pthread/home/ubuntu/boost/libs/yap/doc/yap_reference.xml, and no fallback was found >From any of the builds in < https://circleci.com/gh/boostorg/boost/tree/master>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 4

[math] policy<discrete_quantile<real> > test's fail because multiple matches for 'real'
by Brian Kuhl 24 Jun '18

24 Jun '18

When I compile with VxWorks 7/Clang v5/ Dinkum 700 there is an inline real() function in global scope. Leading to a few errors like this: ----------------------------------------------------------------------- clang-vxworks.compile.c++ ../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o "/yow-build40-lx1/bkuhl/vx7/compilers/llvm-5.0.0.3/LINUX386/bin/clang" -x c++ --target=x86_64 -m64 -mcmodel=large -fno-omit-frame-pointer -fno-strict-aliasing -mno-implicit-float -fno-builtin -nostdlibinc -nostdinc++ -fno-use-init-array -ftls-model=local-exec -ansi -std=c++14 -O2 -Wall -Wno-missing-braces -Wreturn-type -Wconversion -Wformat -Wno-sign-conversion -Wno-c++11-narrowing -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/system -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -O0 -fno-inline -Wall -g -include/yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0/autoconf_vsbConfig_quote.h -D_C99 -D_HAS_C9X -D__vxworks -D__VXWORKS__ -D__RTP__ -D__ELF__ -D__WRS_NO_DIRECT_TLS_ACCESS_FROM_RTP_TO_SHARED_LIB -I/yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0 @/yow-build40-lx1/bkuhl/workspace/VSB/mk/_vsbuinc_cmdllvmBOOST -D_VX_CPU=_VX_SIMLINUX -D_VX_TOOL_FAMILY=llvm -D_VX_TOOL=llvm -D_nq_VSB_CONFIG_FILE=/yow-build40-lx1/bkuhl/workspace/VSB/h/config/vsbConfig.h -I/yow-build40-lx1/bkuhl/workspace/VSB/share/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/system -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -D_VSB_PUBLIC_HDR_DIR=/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -I. -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_TIMER_STATIC_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -DTEST_FLOAT -I".." -I"../libs/math/include_private" -I"../libs/math/test" -c -o "../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o" "../libs/math/test/test_poisson.cpp" ../libs/math/test/test_poisson.cpp:454:39: error: reference to 'real' is ambiguous typedef policy<discrete_quantile<real> > P1; ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:689:21: note: candidate found by name lookup is 'real' inline long double real(_Lcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:543:14: note: candidate found by name lookup is 'real' inline float real(_Fcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:397:15: note: candidate found by name lookup is 'real' inline double real(_Dcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0/boost/math/policies/policy.hpp:225:4: note: candidate found by name lookup is 'boost::math::policies::discrete_quantile_policy_type::real' real, ^ ../libs/math/test/test_poisson.cpp:454:39: error: unknown type name 'real' typedef policy<discrete_quantile<real> > P1; ^ ../libs/math/test/test_poisson.cpp:454:45: error: expected a type typedef policy<discrete_quantile<real> > P1; ^ 3 errors generated. ...failed clang-vxworks.compile.c++ ../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o... -------------------------------------------------------- I'd like to contribute a pull request to resolve this. But I'd like some guidance; is a simple change that qualifies real acceptable. using namespace boost::math::policies; - typedef policy<discrete_quantile<real> > P1; + typedef policy<discrete_quantile<boost::math::policies::real> > P1; typedef policy<discrete_quantile<integer_round_down> > P2; Or is this something that should be added with #ifdef __VXWORKS__

2 1

Re: [boost] Boost.Signals deprecation and removal
by Mike 22 Jun '18

22 Jun '18

> Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: > [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says > If you have existing [2]Boost.Signals-based code, it **will continue to work**, but consider moving to Boost.Signals2.Â Best Mike References 1. http://Boost.Signals/ 2. http://Boost.Signals/

6 6