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

[testing] Regression unresolved issues page
by Adam Wulkiewicz 15 May '15

15 May '15

Hi, The unresolved issues page seems to be outdated (only msvc-8.0 failures can be found there): http://www.boost.org/development/tests/develop/developer/issues.html It's because from all required toolsets mentioned here: https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mar… only the msvc-8.0 is currently tested. The required compilers are quite old ones. I'm not sure how we should addres this issue. I get an impression that in the past this page was used differently than it is now. I'm not sure how though. The ToC/menu is also missing. Anyway, we could: - add only some specific, more modern required toolsets to the explicit-failures-markup.xml - ignore the required toolsets entries and display the issues detected in a library for all non-disabled toolsets - remove the issues page I'd probably go with the second option and treat this page as a complement of the regression matrix. What do you think? Regards, Adam

1 0

[ELFIO] - New library proposal
by Serge Lamikhov-Center 15 May '15

15 May '15

Hello Boost community! I'd like to determine interest in possible new library submission. ELFIO is header-only C++ library that provides a simple interface for reading and generating files in ELF binary format. It is a mature library and is in use by a number of open source and commercial projects. It is a part of some Linux distributions as well as Cygwin project. Would you please have a look at the library's home page located at: http://elfio.sourceforge.net Documentation: http://elfio.sourceforge.net/elfio.pdf Library download: http://sourceforge.net/projects/elfio/files/ELFIO-sources/ELFIO-3.1/ and its source code available through: http://github.com/serge1/ELFIO Please share your opinion on making this library be a part of the Boost. Thank you and Best regards, Serge

5 6

[test] Problem with BOOST_TEST_MESSAGE
by Edward Diener 15 May '15

15 May '15

In testing out a library with Boost.Test I want to inject informational messages that will appear in the output of the test results. When I use BOOST_TEST_MESSAGE with the correct logging level my message appears in the output if there is some sort of Boost.Test error during my tests. However if my unit test does not have a Boost.Test error my BOOST_TEST_MESSAGE does not appear. Needless to say I always want my BOOST_TEST_MESSAGE messages to always appear in the output. Is there a solution to this ?

4 12

[website] Broken uBLAS link
by Renato Florentino Garcia 14 May '15

14 May '15

Hi, The link to uBLAS documentation page on http://www.boost.org/doc/libs points to http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.htm instead of http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.html There are a missing l on .html Regards, Renato Garcia

1 0

[testing] Looking for test runner owner
by Andrzej Krzemienski 14 May '15

14 May '15

Hi All, The test matrix in branch 'master' contains these two test runners: oracle-intel-S2-stlport4 <http://www.boost.org/development/tests/master/oracle-intel-S2-stlport4.html> and oracle-sparc-S2-stlport4 <http://www.boost.org/development/tests/master/oracle-sparc-S2-stlport4.html> Could the owner of these reply to me? I am trying to fix a bug on this platform in Boost.Optional, and would require some assistance. Regards, &rzej

2 1

[variant] 1.58 boost/variant/get.hpp compile errors
by Maarten de Vries 14 May '15

14 May '15

Hello list, I recently updated to boost 1.58 and one of my programs didn't compile any more. The reason was the <boost/variant/get.hpp> header. A simple test program and compiler output is attached below. Swapping the order of the includes or including <boost/type_traits/remove_cv.hpp> before <boost/variant/get.hpp> in the test program will get rid of the errors. It would appear that <boost/variant/detail/element_index.hpp> should include <boost/type_traits/remove_cv.hpp>. Kind regards, Maarten de Vries Test program: #include <boost/variant/get.hpp> > #include <boost/variant/variant.hpp> > > int main() { > return 0; > } > Compiler output g++ (GCC) 4.9.2 20150304 (prerelease): In file included from /usr/include/boost/variant/get.hpp:24:0, > from test.cpp:1: > /usr/include/boost/variant/detail/element_index.hpp:38:69: error: > ‘remove_cv’ in namespace ‘boost’ does not name a template type > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > ^ > /usr/include/boost/variant/detail/element_index.hpp:38:78: error: expected > template-argument before ‘<’ token > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:38:78: error: expected > ‘>’ before ‘<’ token > /usr/include/boost/variant/detail/element_index.hpp:38:88: error: template > argument 2 is invalid > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: expected > ‘::’ before ‘>’ token > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: expected > identifier before ‘>’ token > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: template > argument 2 is invalid > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: expected > ‘::’ before ‘>’ token > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: expected > identifier before ‘>’ token > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: template > argument 2 is invalid > /usr/include/boost/variant/detail/element_index.hpp:41:1: error: expected > ‘::’ before ‘{’ token > {}; > ^ > /usr/include/boost/variant/detail/element_index.hpp:41:1: error: expected > class-name before ‘{’ token >

3 3

Community Maintainence Team - a Modest proposal
by Robert Ramey 13 May '15

13 May '15

Today at 12:45 in Bethe is the operations meeting of the Boost Community Library Maintainence team. In advance of that meeting I'd like to render my proposal on this list so I have it written down. Premise:The library maintainence team does not and will likely never have sufficient resources to maintain libraries without current maintainers. Proposal: a) The CMT will solicit volunteers to take over maintainence of specific libraries. b) The most likely source of such volunteers are those working in companies which use and depend upon the libraries in maintainence. Such companies will be expected to support the library maintainence by permitting the maintainer to undertake this effort using company time and resources. c) Since we don't have a list of which companies are using which libraries, we will send a solicitation to volunteer to every person who has posted a bug report for the library in question on the TRAC system. I believe this is the most likely source for prospective maintainers. d) Companies that support maintainence of a particular library will be permited to place their logo and link on the TRAC page for that library. So they will receive the following benefits from sponsoring the maintainece of the library. 1) They will be demonstrating their commitment to the high standard of software development that Boost supports. 2) By placing their logo and link on the track page, they will be encouraging and facilitating prospective employees who desire to work for such an organization to contact them. That is, they will have a leg up on attracting the highest quality C++ programmers. 3) They will be guarenteed timely and rigorous maintainence of the library which they depend on. 4) They will have the inside track on proposing and implementing any library enhancements that they desire. 5) They will benefit from collaboration of the boost community which provides numerous valuable benefits: Bug fixes submitted by users, suggestions for enhancements. etc. The value of all these benefits to the sponsoring company will far, far out weigh the incremental cost of the employee time. In many cases, since employees have to maintain the library anyway - the incremental cost is zero anyway. This moves the responsibility for library maintainence to those most willing and able to undertake it. The role of the CMT would be to promote, recruit, certify, and monitor library maintainence. The CMT would have the authority to move the responsability from maintainer to another. The current practice of having a single person/entity responsible for maintainence of a library would continue unchanged. Robert Ramey

4 7

boost serialization and new archive types
by Robert Ramey 13 May '15

13 May '15

I'm here at C++Now and some have approached me about some enhancements to the serialization library. Specifically there is interest in moving the implementation of XML serialization to the latest C++11 of boost. I've gone them one better - While they're at it, how about including JSON and YAML as well? I would be happy to meet with anyone and everyone interested in this while here at the conference. I'm commited to all the operations meetings 12:45 so that time would be out - I'm flexible. Robert Ramey

2 1

Windows XP support survey
by Niall Douglas 13 May '15

13 May '15

The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here, so I'd appreciate if library maintainers could state: 1. If they still support Microsoft Windows XP i.e. actively do not use APIs not supported by XP. And if SP3 is the only service pack supported, or if any XP is okay. 2. Whether they regularly test their libraries on a Windows XP machine to ensure their libraries work there. 3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it. As we all know, Microsoft Windows XP is no longer supported by Microsoft as of April 2014, however a widely available registry tweak reenables support and updates until 2019. However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult. It may become wise to announce a date that XP support guarantees will be dropped, and any users needing XP support must remain on an older Boost version and/or make use of Boost modularity to mux their own Boost distro. One big reason for thinking about this is that the first C++ 11 mandatory Boost libraries are just around the corner, and they of course need VS2013 or even VS2015 and so therefore cannot promise Windows XP support. There are also a number of post-XP APIs the assumption of which would make some library authors very pleased. For example, I would assume any Boost.Thread v5 would use the Vista only condvar APIs as one can then skip emulating condvars with win32 semaphores which would be an enormous saving of code complexity. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

14 41

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 12 May '15

12 May '15

You're correct in that a vector<boost::any> can achieve the same thing, and that would probably be the better way to implement this internally. I guess the proposal would be to provide the container interface to give some data modification functions and iterators which iterate over only a given type and such. That way there would be a standardized container with methods to deal with the data in a type specific way. -- James Armstrong

5 17