August 2014 - Boost - lists.preview.boost.org

[algorithm] Interface for longest_increasing_subsequence (proposal)
by Curdeius Curdeius 17 Aug '14

17 Aug '14

Hi all, I want to propose a new algorithm to Boost.Algorithm: a well-known longest increasing subsequence <https://en.wikipedia.org/wiki/Longest_increasing_subsequence> (LIS for short). Just for a short info: given a sequence like ( 7 )( 2 )( 8 )( 1 )( 3 )( 4 )( 10 )( 6 )( 9 )( 5 ), the result will be a subsequence ( 1 )( 3 )( 4 )( 6 )( 9 ). The proposed algorithm has O(n log n) time and O(n) complexity, where n - sequence length. I have created a pull request https://github.com/boostorg/algorithm/pull/7. I have however some questions. I am not sure what should be the exposed interface. For the moment, I propose (I base it on the existing interface from algorithm/searching functions): - class longest_increasing_subsequence with methods - operator() - *compute_length* (a better name may be needed) - free function longest_increasing_subsequence_length returning the length of the LIS and taking as arguments: - a pair of iterators (first, last) - or a range - and (optionally) a comparison predicate - *free function longest_increasing_subsequence_search taking the same arguments as _length function and an Output Iterator or a tag.* - free function make_longest_increasing_subsequence taking a range and optionally a comparison predicate and returning corresponding longest_increasing_subsequence object The problematic part is the underlined longest_increasing_subsequence_search function and the way in which I should return the resulting LIS. I see possibilities like the following: 1. taking an OutputIterator argument: the best for me, generic and the most flexible solution, but there is a performance hit as we cannot reserve the memory for the output LIS. 2. returning a container with the subsequence, e.g. std::vector<value_type>: no performance hit with small objects or if the user needs a vector of values. However, not really generic as the user would be obliged to use a vector (in the aforementioned example). 3. returning a container with iterators, e.g. std::vector<InputIter>: good if a container of iterators is acceptable, it has a benefit of avoiding possibly expensive copies of sequence elements. As 2., not really generic. 4. -taking a container as an argument: the worst solution in my eyes, there is no way nice way to write generic code that handles all containers. I have coded possibilities 1-3. Thank you in advance for all the comments, corrections etc. Regards, Marek Kurdej

1 0

[testing] Proposal - regression tests results display upgrade
by Adam Wulkiewicz 17 Aug '14

17 Aug '14

Hi, Currently test failures of a new feature are always marked with the yellow color and a word 'fail'. Would it make sense to use some more descriptive color/naming scheme? In particular it would be nice to distinguish between the actual failures and the situations when the compilation of a test took too much time or an output file was too big. Would it make sense to also distinguish between compilation, linking and run failure? E.g. instead of a simple 'fail' use 'fail (c)', 'fail (l)' and 'fail (r)'. E.g. the color for actual failures could be orange and for "others" could stay yellow. Furthermore, currently it's impossible to see the results of compilation if a test passed. Would it make sense to change it? This would allow us to view and fix warnings even if the test was passed. The test passed with warnings could be marked e.g. with 'pass (w)' or the color could be set to some between yellow and this light green. If you directed me where it should be done I could try to change it. I'm guessing it would require modifying some script generating the page and some CSS? Regards, Adam

6 10

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 16 Aug '14

16 Aug '14

Hi all, I considered proposing myself as a maintainer of Boost.Units for some time, but considered too inexperienced to do it on my own. Therefore I am happy that Jürgen proposed himself and I would like to help him by being a co-maintainer if it is possible and needed. As for me, I have been using the library for at least 3 years now and would like to contribute to it. For the moment, I mainly proposed small bug fixes to Boost libraries. Regards, Marek Kurdej -- Ph.D. candidate Hi Matthias, > Am Donnerstag, 31. Juli 2014, 11:25:35 schrieb Matthias Schabel: > > I would love to pass the responsibility for ongoing maintenance of > > Boost.Units on to a new torchbearer. > First a "Thank you very much" for the great library. > > My time to dedicate to this project > > has dwindled to essentially zero, and I believe it would be best for all > > involved to enlist some fresh blood, ideally someone who is using the > > library on a regular basis... Any volunteers? > As no one else has stepped up, I'd like to volunteer. I've been using > Boost.Units with great success for the last five years. For my recent Boost > contributions see https://github.com/jhunold. Mostly small bugfixes, > Boost.Build support over the last decade. > Boost.Units is getting more attentions now as c++11 is getting momentum. > Personally, I'd like to get > https://github.com/boostorg/units/pull/5 > into 1.57. > > As far as Erik's request, I don't have any objections to adding these to > the > > library, though I have not had time myself to verify that they are > correct. > It would be nice if one of the current maintainer could comment on this. > > >> Link to PR: https://github.com/boostorg/units/pull/3 > Seems obsolete, > https://github.com/boostorg/units/pull/6 > it the improved commit. > Feel free to ask questions. > 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

[config][type_traits] Support for final keyword in Boost?
by John Maddock 16 Aug '14

16 Aug '14

I have a couple of pull requests to add support for the final keyword in Boost.Config and an is_final trait to type traits, so my questions are: 1) Are these generally useful? 2) Do we need BOOST_NO_CXX11_FINAL_CLASS and BOOST_NO_CXX11_FINAL_OVERRIDE or will a single BOOST_NO_CXX11_FINAL do? 3) The trait appears to be unimplementable via SFINAE (anyone care to prove me wrong?) which means it's only usable on GCC and lookalikes which have an __is_final intrinsic. Should we still add this to Boost or is the answer "use GCC's native features" given that a Boost version effectively adds nothing? Thanks! John.

4 3

[docbook] Add detail namespace to Reference section
by Benedek Thaler 16 Aug '14

16 Aug '14

Hi, I have the following example code fragment: namespace boost { namespace detail { /** documentation */ class implementation {}; } // namespace detail using detail::implementation; } // namespace boost I'd like to have the class `implementation` show up in the Reference section generated by doxygen+docbook-xsl+boost build+docbook+... . Issue is, every namespace which name contains the string "detail" is excluded somehow. The direct output of doxygen has it, but not the docbook version. I couldn't find any EXCLUDE_SYMBOLS setting (it's not set in the doxyfile)or anything relevant amongst the docbook-xsl params or in the boost build scripts. Google search term "doxygen ignores detail namespace" and the like did not help. Adding documentation to the using statement and/or TYPEDEF_HIDES_STRUCT did not help. Thanks, Benedek

2 3

Should intrusive_ptr copy constructors be declared noexcept?
by James Yonan 16 Aug '14

16 Aug '14

Currently, intrusive_ptr's copy constructors are not declared noexcept. This disables the std::function small object optimization when intrusive_ptr objects are passed by value in a lambda closure. The attached patch tries to fix this by making the copy constructors conditionally noexcept, based on the noexcept status of the user-provided intrusive_ptr_add_ref function. James

1 0

[Boost][filesystem] imbue in global constructor crashes
by Peter Bindels 15 Aug '14

15 Aug '14

Hi all, When trying to use a global constructor to set the locale to utf8 for an entire project, the system failed to start due to global constructor ordering making the override happen before the std::locale object itself was initialized. Looking into the boost::filesystem code for imbue it seemed that there were a few different implementations, one of which could work. I've tried to keep the same side conditions and made this same lazy-initialization approach for all platforms, which should keep working in all the same conditions and also work for a global constructor overriding the locale. I've attached the patch. I hope that this change can be integrated into boost::filesystem or that we can have a constructive discussion on what solution we should be making. Best regards, Peter Bindels

2 1

[variant] static_visitor constructor error with boost 1.56.0 and g++ 4.5.1
by Richard Hadsell 15 Aug '14

15 Aug '14

I am trying to upgrade from Boost 1.55 to 1.56. I get this error with G++ 4.5.1: In file included from ...: .../boost/variant/static_visitor.hpp:52:24: error: 'boost::static_visitor<R>::static_visitor()' declared with non-public access cannot be defaulted in the class body .../boost/variant/static_visitor.hpp:53:25: error: 'boost::static_visitor<R>::~static_visitor()' declared with non-public access cannot be defaulted in the class body The OS is Linux Fedora 14. The compiler is gcc version 4.5.1 20100924 (Red Hat 4.5.1-4). I saw a similar problem in noncopyable.hpp, when upgrading to Boost 1.55. Andrey Semashev fixed it, and it looks like static_visitor requires the same fix. In static_visitor.hpp change line 51 from #ifndef BOOST_NO_DEFAULTED_FUNCTIONS to #if !defined(BOOST_NO_CXX11_DEFAULTED_FUNCTIONS) && !defined(BOOST_NO_CXX11_NON_PUBLIC_DEFAULTED_FUNCTIONS) I think this would be appropriate for any non-public defaulted functions, not just the ones that trip up code I happen to compile. Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560 Follow Blue Sky Studios on Facebook <http://www.facebook.com/BlueSkyStudios> and Twitter <http://twitter.com/#%21/blueskystudios>

2 1

[1.56] PDF documentation available
by John Maddock 14 Aug '14

14 Aug '14

The PDF build of Boost's documentation for 1.56 is now available from the usual address: https://sourceforge.net/projects/boost/files/boost-docs/1.56.0/ Note that it includes only the subset of Boost libraries whose documentation is quickbook/docbook based. John Maddock.

6 8

[container] 1.56.0 flat_map static assert typo ?
by feverzsj 14 Aug '14

14 Aug '14

hi, list in <boost/container/flat_map.hpp>, the ctors seems to contain a wrong static assert: flat_map() : m_flat_tree() { //Allocator type must be std::pair<CONST Key, T> BOOST_STATIC_ASSERT((container_detail::is_same<std::pair<Key, T>, typename Allocator::value_type>::value)); } missing "const" ? regards. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-container-1-56-0-flat-map-static-a… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3