- Boost - lists.preview.boost.org

[graph] strong_components & depth_first_visit feature proposal
by Alexander Lauser 27 Aug '14

27 Aug '14

Hi all, I am writing two minor extensions for Boost.Graph, making strong_components and depth_first_visit more generic. This mail is to assess interest in publishing these features. * Question 1: What about extending strong_components to allow the user to (optionally) hook into DFS-events? The rationale for that is that when computing strong components, one may also be interested in connecting paths between any two distinct vertices in a component. With the ability to hook into the events, the paths can be traced, using tree_edge and back_edge to store paths to/fro the root of the component. One may possibly even allow additional events with respect to the discovery and finishing of components as well as the adding of vertices. What do you think about that? A technical question w.r.t the implementation of such a visitor: Why is the name dispatching for the named parameters of strong_components done "by hand" and not using the same facilities as depth_first_search? (I'm quite new to Boost and most of its notions like named parameters, so I may have missed something trivial. If so I beg to forgive the question.) * Question 2: What about introducing a new (optional) event for finish_tree_edge during a depth_first_visit? This event would be called when backtracking a tree_edge. Even though I cannot give a specific application where such an event would be essential, I still think it's a event during a depth-first-search that is natural enough to allow the user to hook in. (N.b. that similar events finish_back_edge and finish_forward_or_cross_edge would not make sense as they get always called immediately after back_edge and forward_or_cross_edge, respectively.) * Another minor question: Why are not all events of a DFS-visitor optional (like finish_edge is)? I think this would make implementing a partial DFS-visitors easier (by not having to derive from dfs_visitor in order to provide events that one is not interested in). A problem in the implementation of this would be that there is currently a bug (ticket 10231) with the current implementation that makes finish_edge optional. - Alex

2 2

[build] Running b2 with particular toolset invokes other toolsets in user-config.jam
by Edward Diener 27 Aug '14

27 Aug '14

I brought up this issue on the Boost build mailing list and it was eventually ignored, so I will bring it up here again. If I run "b2 toolset=sometoolset" Boost Build ends up invoking other toolsets in my user-config.jam along with "sometoolset" to do the build. This invoking of other toolsets seems not only a waste of time and unnecessary but also wrong in the sense that the invoking of some other toolset in user-config.jam may produce an error. I do not understand the necessity for invoking other toolsets in user-config.jam when I have specified the toolset I want. The practical situation for me which is causing problems with Boost Build behavior, because of the actions described above, is that I have a local setup under Windows where I can run many different versions of gcc/mingw or gcc/mingw64. In order to do this I using a changing symbolic link, on my PATH, to point to any one of many versions of gcc in different directories. I have a file running appropriate commands that switches between the versions. I have also built clang on Windows with a particular gcc version and therefore any invocation of clang looks for the run-time system of that particular version when clang is invoked. So if I "switch" gcc to a version which is not the one wih which i built clang, and then invoke Boost Build with that gcc toolset, clang also gets invoked as explained in the beginning remarks above, and this gives an error from the clang invocation. It is true that Boost Build continues, even after the error message coming from clang, in executing the appropriate jamfile with the particular version of gcc as the toolset. But it is annoying nonetheless to see this error for a toolset I am not even invoking. Cannot something be done in Boost Build so that if I am invoking toolset=x there should be no reason to be trying toolset=y unless it is actually needed for something when using toolset=x ? As for instance when the bjam files specifies some other tool ( doxygen, fop, xsl ) which have to be used.

2 4

[documentation] Incorrect link in prebuilt Win binaries.
by Mostafa 26 Aug '14

26 Aug '14

1) Download and install boost_1_56_0-msvc-8.0-64 2) Open libs/libraries.htm 3) Click the link for static_assert 4) Wrong 2nd link in the following message: Automatic redirection failed, please go to ../../doc/html/boost_staticassert.html or view the online version at http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost_stati…

1 0

Building boost on osx 10.9 mavericks
by Jerome Laurens 26 Aug '14

26 Aug '14

Hi I could build boost 1.56 on macosx 10.9 for 10.9 but I do not manage to build boost on macosx 10.9 targeting macosx 10.8. It seems that darwin.jam does not recognize the installed SDKs such that I cannot use macosx-version feature. Now the developer resources are no longer in the /Developer folder but in /Applications/.../Xcode.app/Contents/Developer I tried to symlink this folder from /, I also tried a root=... argument to no avail. Any hint ? Tia Jérôme LAURENS

1 0

Movable but not copyable bug?
by Mostafa 26 Aug '14

26 Aug '14

I had posted this on the user's list but I think this should be brought to the attention of the developers. The following code contains a templated copy constructible Boost.Move enabled class (Bar) with a single non-copy constructible Boost.Enabled member (Foo). If Bar's copy constructor is not explicitly defined then the code compiles with both g++ 4.8.2 and VS2005, else if it's explicitly defined then it fails to compile on g++ 4.8.2 I think this is due to the fact that g++ 4.8.2 erroneously instantiates Bar's default copy constructor in the latter case. Is this a Boost.Move bug or a gcc bug? #include <boost/move/core.hpp> #include <boost/move/utility.hpp> struct Foo { Foo(int x, int y) {} Foo(BOOST_RV_REF(Foo) rhs) {} private: //Purposefully declared and not defined. Foo & operator=(Foo); private: BOOST_MOVABLE_BUT_NOT_COPYABLE(Foo) }; template <typename T> struct Bar { Bar() : f(0, 1) {} // (1) //Bar(Bar const & rhs) //: f(rhs.f) //{} Bar(BOOST_RV_REF(Bar) rhs) : f(::boost::move(rhs.f)) {} private: //Purposefully declared and not defined. Bar & operator=(Bar); private: BOOST_COPYABLE_AND_MOVABLE(Bar) private: T f; }; Foo f1() { return Foo(0, 1); } Bar<Foo> f2() { return Bar<Foo>(); } int main() { // Foo f( f1() ); Bar<Foo> b(( Bar<Foo>() )); // Bar<Foo> b1; // Bar<Foo> b2(b1); return 0; }

4 14

[Range] compilation error with mfc-iteration-support
by Tobias Loew 26 Aug '14

26 Aug '14

Hi, moving parts of range_const_iterator to the namespace range_detail in file boost/range/const_iterator.hpp leads to ambiguity in /range/detail/mfc.hpp line 747: 25>..\src\libs\boost\boost\boost/range/mfc.hpp(747): error C2872: 'range_const_iterator' : ambiguous symbol 25> could be '..\src\libs\boost\boost\boost/range/const_iterator.hpp(67) : boost::range_const_iterator' 25> or '..\src\libs\boost\boost\boost/range/const_iterator.hpp(40) : boost::range_detail::range_const_iterator' 25> ..\src\libs\boost\boost\boost/range/detail/microsoft.hpp(135) : see reference to class template instantiation 'boost::range_detail_microsoft::customization<Tag>::meta<X>' being compiled 25> with 25> [ 25> Tag=CEbsValueArray::mfc_range_base_type, 25> X=CTypedPtrArray<CObArray,EbsValue *> 25> ] 25> ..\src\libs\boost\boost\boost/range/begin.hpp(111) : see reference to class template instantiation 'boost::range_detail_microsoft::const_iterator_of<T>' being compiled 25> with 25> [ 25> T=CTypedPtrArray<CObArray,EbsValue *> 25> ] ... changing the name of boost::range_detail::range_const_iterator to boost::range_detail::range_const_iterator_helper resolves the problem. I expect other begin/end adapters to run into the same problem. Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Range-compilation-error-with-mfc-iterati… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[endian] Boost.Endian library added for 1.57.0
by Beman Dawes 26 Aug '14

26 Aug '14

The library provides integer and floating point types and conversion functions for portable byte ordering regardless of processor endianness. Although the primary uses are for file or network I/O, it is also useful for unaligned integers or floats, or for 3, 5, 6, and 7 byte integers. The library's predecessors have been in use for thirty years and developed independently multiple times. The repository is https://github.com/boostorg/endian The documentation is online at https://boostorg.github.io/endian/ See https://boostorg.github.io/endian/index.html#Release-history for changes since the Formal Review. No need to report "Inspection Report" problems; those will be cleaned up before 1.57.0 ships. Please do report any other problems or concerns, since the time between now and when the 1.57.0 beta ships in effect acts a mini-review period. If anyone has access to a big-endian platform with a modern C++ compiler, please, please run the endian test suite and report the results. All testing and use in recent years has been on little-endian platforms, so big-endian platform testing is a worry. Thanks for you patience, --Beman

7 9

Align and TypeIndex are missing in components list
by Antony Polukhin 25 Aug '14

25 Aug '14

Hi, It is impossible to create a ticket for TypeIndex or Align libraries in track (https://svn.boost.org/trac/boost/newticket) -- Best regards, Antony Polukhin

2 1

[Serialization] link error in 1.56
by Tobias Loew 25 Aug '14

25 Aug '14

Hi, linking the serialization lib fails in version1.56 with unresolved symbols due to the missing implementation of boost::archive::detail::shared_ptr_helper::shared_ptr_helper(void) boost::archive::detail::shared_ptr_helper::~shared_ptr_helper(void) up to version 1.55 those symbols were defined in libs\serialization\src\shared_ptr_helper.cpp, but now this file is excluded from the build and contains the implementation of a nowhere defined class shared_ptr_helper_base. Is there a replacement for shared_ptr_helper, is it redundant or is serialization broken in 1.56? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-link-error-in-1-56-tp46668… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[container] New container: why is everybody silent?
by Alexander Kuprijanov 25 Aug '14

25 Aug '14

Hi boost community! Please tell me something about my container, don't be silent. I firmly intend to offer it to boost, because it's much faster than competitors (by a constant factor). It's intended to replace std::vector in cases, when an application requires multiple insertion/deletion. It takes O(log(N)) for insertion/deletion. Docs: http://alexkupri.github.com/array/ Code: https://github.com/alexkupri/array Best regards, Aleksandr Kupriianov

10 22