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

Find All Paths
by Tom Skora 10 Sep '15

10 Sep '15

I have a list of vertices and using unidirectional edges, create multiple start and end paths starting from a start vertex. Ex. Vertices= 1,2,3,4,5, 6 Edges = (1,2), (2,3), (2,4), (2,5), and (5, 6) I would like to put in vertex 1 and have the following lists returned: 1,2,3 and 1,2, 4 and 1,2, 5, 6 What function can I use to return those lists Thanks Sent from my iPhone

1 0

[git] Stalled submodule updates?
by Rene Rivera 09 Sep '15

09 Sep '15

I was investigating why testing is currently broken.. And narrowed it down to the tools/build subproject on develop not being up to date with the current build submodule commit. Anyone know what has gone awry with the auto-updates of the super project? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[type_traits] Time to merge Version 2 to the master branch?
by Ion Gaztañaga 09 Sep '15

09 Sep '15

Hi, Once Boost 1.59 is out, I'd like to suggest merging TypeTraits V2 to the master branch. It's a great job that will reduce boost library dependencies. Any chance this can happen soon? Best, Ion

4 5

[container] Implemented Polymorphic Memory Resources
by Ion Gaztañaga 09 Sep '15

09 Sep '15

Hi to all, In case anyone is interested, I just committed to the develop branch the implementation of the proposal "N3916 Polymorphic Memory Resources - r2" that was included in the TS "C++ Extensions for Library Fundamentals". The library continues to support C++03 compilers. It basically introduces in namespace boost::container::pmr and the path boost/container/pmr/: - memory_resource - synchronized_pool_resource - unsynchronized_pool_resource - monotonic_buffer_resource - polymorphic_allocator - resource_adaptor - new_delete_resource / null_memory_resource / get_default_resource / set_default_resource - Aliases for all containers, using the polymorphic_allocator. As default resource, new_delete_resource and null_memory_resource are required to be globals, they are implemented in the separately compiled boost.container library that was used to implement the DLMalloc-based extended allocator. It seems that many users dislike building Boost libraries, but I felt this was the correct way to implement it. We could change or make it optionally header-only if there is demand. To avoid dependencies to some users, I made sure that memory_resource and resource_adaptor, which don't depend on the global default memory resource, can be used without linking the library. Some logic was refactored from scoped_allocator_adaptor to avoid repeating the complicated template and preprocessor machinery in the polymorphic_allocator. I hope this does not cause any problem to scoped allocator users. Any suggestion or bug report is welcome. Best, Ion

5 8

Compiling with Clang 3.7.0 from windows
by Paul A. Bristow 09 Sep '15

09 Sep '15

I've downloaded the shiny new Clang 3.7 and added this to my user-config. # 64-bit version using clang # from http://llvm.org/releases/download.html : # version 3.7.0 : # Clang compiler .exe location #"C:/LLVM/bin/clang++.exe" # OK #"C:\\Program Files (x86)\\LLVM\\bin\\clang++.exe" # OK "C:\\Program Files\\LLVM\\bin\\clang++.exe" # : # options ; If I compile a simple hello world (no Boost library calls) program using the defaults (jam (using up-to-date Boost develop branch) it fails at the link complaining c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe which seems an odd message??? I:\modular-boost\libs\quickdox\example>b2 toolset=clang-3.7.0 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) ...found 22 targets... ...updating 4 targets... clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.obj clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-w64-windows-gnu Thread model: posix "C:\\Program Files\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -disable-free -main-file-name quick_auto_dox_index.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -g -dwarf-column-info -coverage-file "I:\\modular-boost\\libs\\quickdox\\example\\..\\..\\..\\bin.v2\\libs\\quickdox\\example\\quick_auto _dox_index.test\\clang-linux-3.7.0\\debug\\quick_auto_dox_index.obj" -resource-dir "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.7.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -I "..\\include" -internal-isystem "c:\\mingw\\mingw32\\include\\c++" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\mingw32" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\backward" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1\\mingw32" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1\\backward" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1\\mingw32" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1\\backward" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++\\mingw32" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++\\backward" -internal-isystem "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.7.0\\include" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include" -internal-isystem "c:\\mingw\\mingw32/sys-root/mingw/include" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include-fixed" -internal-isystem "c:\\mingw\\mingw32\\include" -internal-isystem "c:\\mingw\\include" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\quickdox\\example" -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-use-cxa-atexit -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\quickdox\\example\\quick_auto_dox_index.test\\clang-linux-3.7.0\\debug\\q uick_auto_dox_index.obj" -x c++ quick_auto_dox_index.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-w64-windows-gnu ignoring nonexistent directory "c:\mingw\mingw32\include\c++" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\mingw32" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\backward" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1\mingw32" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1\backward" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1\mingw32" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1\backward" ignoring nonexistent directory "c:\mingw\mingw32/sys-root/mingw/include" ignoring nonexistent directory "c:\mingw\mingw32\include" #include "..." search starts here: #include <...> search starts here: ..\..\.. ..\include c:\mingw\lib\gcc\mingw32\4.8.1\include\c++ c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\mingw32 c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\backward C:\Program Files\LLVM\bin\..\lib\clang\3.7.0\include c:\mingw\lib\gcc\mingw32\4.8.1\include c:\mingw\lib\gcc\mingw32\4.8.1\include-fixed c:\mingw\include End of search list. clang-linux.link ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.exe c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) "C:\Program Files\LLVM\bin\clang++.exe" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_ dox_index.exe" -Wl,--start-group "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_ dox_index.obj" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -m64 ...failed clang-linux.link ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.exe... ...skipped <p..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug>quick_auto _dox_index.run for lack of <p..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug>quick_auto _dox_index.exe... ...failed updating 1 target... ...skipped 2 targets... ...updated 1 target... If I specify address-model=32, then it runs OK - but still says "64-bit : yes (cached)" which isn't what I would expect? I:\modular-boost\libs\quickdox\example>b2 -a toolset=clang-3.7.0 address-model=32 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) <<<<<<<<<<<<<<<<<<< ??????????????????? <snip> [Also example>b2 -a toolset=clang-3.7.0 address-model=64 fails to link as with no address-model specified (so default is 64 bit?)]. Suggestions? (Have I got the wrong version of mingw? I have others from ming64 - how do I specify to use those?) Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

6 26

Re: [boost] Common future base class (was Re: Boost.Fibermini-review September 4-13)
by Nat Goodspeed 07 Sep '15

07 Sep '15

On Sun, Sep 6, 2015 at 2:07 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >> I've always found when_any much more interesting than when_all. Is it as >> trivial to implement with await as when_all? > Nod, I agree. However, I have not found a clever way to do that yet. On Mon, Sep 7, 2015 at 9:39 AM, Anthony Williams <anthony.ajw(a)gmail.com> wrote: > On 07/09/15 14:36, Agustín K-ballo Bergé wrote: >> On 9/7/2015 4:32 AM, Anthony Williams wrote: >>> On 03/09/15 16:47, Agustín K-ballo Bergé wrote: >>>> calling `set_value` on the same instance from different >>>> threads concurrently is expected to work, as in only one (unspecified) >>>> of them will actually make the shared state ready while all the others >>>> would throw `promise_already_satisfied`? >>> Yes, that was the intent. I've got an example that does exactly that in >>> chapter 8 of my book. >> Could you describe briefly what this example does? Is it just workers >> racing (in the good sense) to satisfy the promise? Or does serialization >> of set_xxx calls matter? > It's just workers racing to satisfy the promise. The first one to do so > sets the value, the rest get an exception. Seems like that could be the basis for a nice when_any?

2 1

Re: [boost] [Boost-users] Boost.Fiber mini-review September 4-13
by Vicente J. Botet Escriba 07 Sep '15

07 Sep '15

Le 06/09/15 02:21, Vicente J. Botet Escriba a écrit : > Le 05/09/15 16:27, Nat Goodspeed a écrit : >> On Fri, Sep 4, 2015 at 5:08 PM, Vicente J. Botet Escriba >> <vicente.botet(a)wanadoo.fr> wrote: >> >>> Le 04/09/15 20:37, Nat Goodspeed a écrit : >>>> On Fri, Sep 4, 2015 at 2:07 PM, Vicente J. Botet Escriba >>>> <vicente.botet(a)wanadoo.fr> wrote: >>>>> Please could you recall us what "not in the present form" meant as a >>>>> result >>>>> of the review and what has been done to overcome these issues? >>>> http://lists.boost.org/boost-announce/2014/01/0393.php >>>> >>>> I have not yet tried to address those point by point. >>> I don't understand then why are we doing the mini review now, before >>> you >>> check that any point has at least tried to be addressed. >> Sorry. How about these points: >> >> Performance: Oliver has not only worked to improve performance, he has >> included and documented performance tests you can run on your own >> hardware. > Great, I will check. > See below. >> Documentation: The documentation now contains several new sections >> explaining how to use the library for interesting/common use cases. >> New examples are presented and documented. > See below. >> >> API: The API has been aligned more closely with std::thread. C++14 is >> not only supported but required. Move-only callables are supported. >> Variadic parameters are supported. std::chrono is more generically >> supported. Channels now support value_pop(). fiber_group has been >> dropped. Migrating fibers between threads has been dropped. > See below. >> That said, of course, it is up to each reviewer to state for him- or >> herself whether s/he believes that the Fiber library should become >> part of Boost. In particular, regardless of what Oliver or I might >> synopsize, it is up to each previous reviewer to decide whether his >> January 2014 objections have been addressed. > To be clear, I believe that by respect to the reviewers you should > take the review summary you wrote and add a comment for each point. > > Best, > Vicente Hi again, In addition to my last request and in order to be able to write a review, I would like to know what exactly has been changed since the first review, what was expected after the review summary and what was removed, changed or added and what was the rationale. Best, Vicente

2 1

[android] New compilers: gcc-5.2 and clang-3.7
by Dmitry Moskalchuk 03 Sep '15

03 Sep '15

Hi all, We've added new compilers into CrystaX NDK recently: gcc-5.2 and clang-3.7 (old gcc-4.9 and clang-3.6 still there too). Testing results should appear on Boost regression page in a few days. Both compilers have fully passed our automatic tests, but you know, there still could be bugs, especially in such complicate projects. We're asking all maintainers of the Boost libraries look on that results and report us bugs (if any) to https://tracker.crystax.net/projects/ndk. The most important for us is catching regressions caused by new compilers compared to theirs previous versions. In case of such bugs, please don't add workarounds into Boost code; better report and let us fix them in CrystaX NDK. Thank you. -- Dmitry Moskalchuk

1 0

[Boost.AFIO] Formal Review
by Joel FALCOU 02 Sep '15

02 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? The topic of asynchronous file operation is very very important and quite critical in our days. Boost needs such a library but I fear *current* AFO is not there yet. I vote NO for its inclusion in Boost in its current form. > 2. What is your evaluation of the design? I think the intent are goods but there's some icky parts. The use of future and other asynchronous element in the API cudl be made more clear and easy. Thomas Heller made a compelling lsit of gotcha that shoudl be followed. Currently i had to fight against my habit of writing future absed code to get the stuff working. > 3. What is your evaluation of the implementation? Next to small scale issues like mammoth headers and liberal use of allocation in the implementation of some functions, I think the main culprit is to simplify the implementation by splitting the ABI stable part into another component. Also, the way asynchronous cmponents are used internally hould be aligned with the required fix on the public API. > 4. What is your evaluation of the documentation? The documentation is hard to follow and some 'simple example' are clearly not that simple. This should be the second major point of improvement. > 5. What is your evaluation of the potential usefulness of the library? THis kind of library is very useful and as I said, we need one with proper design and implementation. > 6. Did you try to use the library? Played around with the examle and the doc. > 7. How much effort did you put into your evaluation? Roughly 10-12 hours > 8. Are you knowledgeable about the problem domain? Not with async file I/O but I have a fair amount of experience in asynchronous computation and parallel programming in general. As a concluding note, I *really* want Niall to keep going on making AFIO the reference async file I/O library. Just take the needed time to reflect on the afformentionned PAI and implementation issues and remember that there is no rush to get there.

3 3

boost::python::make_setter(&X::y) no longer compiles
by Jonathan Wakely 02 Sep '15

02 Sep '15

This compiled with 1,58, it doesn't with 1.59: #include <boost/python.hpp> struct X { int y; }; int main() { boost::python::make_setter(&X::y); } Is this intentional? Is it documented somewhere? The examples in the docs still seem to use this form.

1 1