- Boost - lists.preview.boost.org

[git] [filesystem] [system] [timer...] Remove useless SVN branches?
by Beman Dawes 18 Aug '14

18 Aug '14

Boost library repos converted from Subversion are littered with branches created by the conversion process that seem to me to be quite useless. For example, Boost filesystem has 65 branches, yet only 10 or so have any usefulness I'm aware of. A lot of the useless branches have names that begin "sandbox" or "svn-". I go back to the subversion repo when I want to look at pre-git-conversion history. Is there any point in retaining these branches? Does anyone object if I remove these branches from the libraries where I am the maintainer? What are other maintainers doing about stale branches? --Beman

3 2

clang and variadic macro warnings revisited
by Edward Diener 18 Aug '14

18 Aug '14

After making pull requests for a number of Boost libraries in order to reduce the warnings from compilation from clang using the Boost PP library, John Maddock suggested a specific solution, as Niall Douglas had suggested a general one before, that changes in the Boost PP library could get rid of these extraneous warnings. Originally I thought this would be too difficult and intrusive in Boost PP but after reading John's specific suggestion I decided to try to implement it. The suggestion John made was to surround code in Boost PP which uses variadic macros with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wvariadic-macros" # endif // variadic macros # ifdef __clang__ # pragma clang diagnostic pop # endif This was actually easier than expected since all code in Boost PP which uses variadic macros is surrounded by: # if BOOST_PP_VARIADICS #endif // eventually Of course there are many files changed by this but overall it is very straightforward. This technique does work for the diagnostic "-Wvariadic-macros". Hooray ! Unfortunately the second situation involving warnings, where clang warns about: warning: empty macro arguments are a C99 feature [-Wc99-extensions] coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif #define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,) # ifdef __clang__ # pragma clang diagnostic pop # endif does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang. The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported. In retrospect, when I changed Boost PP from never supporting variadic macros for clang ( Paul's original conservative choice ) to always supporting variadic macros for clang, I gave in to an outcry that clang users should have variadic macro support in Boost PP. It would have been wiser to follow the gcc method in Boost PP. But that is past and we need a good solution now. Thoughts ? Solutions ? Brickbats <g> ?

3 3

[endian] Was: [Boost-testing] All runners on develop are failing.
by Rene Rivera 18 Aug '14

18 Aug '14

---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Fri, Aug 15, 2014 at 8:13 PM Subject: [Boost-testing] All runners on develop are failing. To: Running Boost regression tests <boost-testing(a)lists.boost.org> It is looking for the endian library...which I have, but is still failing. error: Unable to find file or target named error: '../libs/endian/' error: referred to from project at error: '.' I did a: git checkout develop git pull git submodule update --init on my repository, which caused the previously empty endian directory to be populated, but still getting the error. Thoughts? Tom _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[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