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

[BOOST_FOREACH] Problem to iterate on a non-copyable container...
by nico 21 May '15

21 May '15

I'm not sure of the title, because I'm not sure the issue comes from the "copyablility" of my container. I tryied quite everything but I can't get rid of this error. Here is a simplified version of my code (please do not challenge the class design, I really would like to keep the end-used syntax in the BOOST_FOREACH): template <typename T> class MyContainer { public: typedef typename std::vector<T>::iterator iterator; typedef typename std::vector<T>::const_iterator const_iterator; MyContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_lock(mutex) { } iterator begin() { return m_vector.begin(); } const_iterator begin() const { return m_vector.begin(); } iterator end() { return m_vector.end(); } const_iterator end() const { return m_vector.end(); } private: std::vector<T>& m_vector; boost::lock_guard<boost::mutex> m_lock; }; template <typename T> struct GetContainer { GetContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_mutex(mutex) { } MyContainer<T> Get() { return MyContainer<T>(m_vector, m_mutex); } std::vector<T>& m_vector; boost::mutex& m_mutex; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); boost::mutex m; GetContainer<int> getter(v, m); BOOST_FOREACH(int i, getter.Get()) { std::cout << i << std::endl; } return 0; } The compiler complains about not having a copy constructor for MyContainer<int>::MyContainer(const MyContainer<int>&) I also have : error: no matching function for call to ‘MyContainer<int>::MyContainer(boost::foreach_detail_::rvalue_probe<const MyContainer<int> >::value_type)’ I follow the extensibility tips: http://www.boost.org/doc/libs/1_58_0/doc/html/foreach/extensibility.html#fo… But, making MyContainer<T> : private boost::noncopyable doesn't solve the issue. Nor defining the function boost_foreach_is_noncopyable or specializing the template struct is_noncopyable for MyContainer<int> (in fact, how would I specialize this template for a template type ?) Last "tip": If I remove the mutex and the lock from everywhere (I just pass the vector to GetContainer and to MyContainer<T>, it works. But it doesn't work if I make MyContainer<T> : private boost::noncopyable (I expected it should, so I'm not sure my problem is with BOOST_FOREACH, but maybe because I return a copy of MyContainer with my getter ?) I thank you if you read me until here, and thanks in advance for help.

3 4

What does "xml this : this.qbk" do?
by Peter Dimov 21 May '15

21 May '15

Documentation Jamfiles often contain a line like xml core : core.qbk ; What does this line do? Is "xml" a rule? I haven't been able to find it anywhere.

2 1

Questions about upcoming review of Boost.AFIO
by Niall Douglas 21 May '15

21 May '15

Dear list, Ahmed has volunteered to review manage AFIO (thanks Ahmed!), however I wanted to get the list's feedback on some things first. 1. After collecting feedback at C++ Now from members of WG21 on the shape and preferred future of a race free Filesystem TS, the next iteration of AFIO will have a radically different API consisting of the form: std::vector<afio::future<T>> afio::batch(...) afio::future<T> afio::async_io_handle::operation(inputs) noexcept(is_nothrow_move_constructible<T>) T afio::io_handle::operation(inputs) T afio::io_handle::operation(error_code &ec, inputs) The internal engine is the same very well tested code, just the API is very different from before. The current API was forced by VS2010's limitations and the lack of constexpr in MSVC - now VS2015 RTM has C++ 11 constexpr, I can adopt the custom future based API I always originally wanted. This new API will require C++ 14 in the compiler. Question: Given the API will so radically change, is now the time for a community review? Do note that APIBind allows me to support the existing API and the new API concurrently without issue. 2. AFIO requires APIBind which is a separate library. APIBind is not yet in the review queue and it is pending me writing up its documentation and a more useful unit test suite. Is this a problem? Do note that you the user of AFIO will never need to know about APIBind, it is entirely an internal implementation detail. Comments appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 10

More cool free github tooling: https://reviewable.io/
by Niall Douglas 21 May '15

21 May '15

Dear list, I'm not sure about other libraries, but in Boost.Thread Vicente the primary maintainer does the lion's share of dealing with pull requests but he occasionally needs someone else to review a patchset or a pull request before it can be merged. Github's facilities for this are okay - you can comment per line of a pull request, and overall. It works, though one wishes for something more gerrit like. So enter a new free tool with github integration: https://reviewable.io/. One click install into your github project. You now gain an alternative UI for pull requests, one which is much better than the default Github UI, specifically: * Per file review gating like gerrit * Can publish a group of per-line comments as a single thing (and just one email notification) * Doesn't hide deleted change history * Diffs are much better calculated and presented I've turned it on for AFIO. We'll see how it goes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Some statistics about the C++ 11/14 mandatory Boost libraries
by Niall Douglas 21 May '15

21 May '15

Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries. I looked at fifteen libraries and decided ten were worth further investigation. I'm sure you all remember my colour coded ranking of those ten libraries by "nearness" to entering Boost: https://goo.gl/6l1KiH I sadly only have time to review four of those libraries during my talk, but one (APIBind) enables an alternative Boost 2.0 approach and I will spend 45 mins on that library alone. And here is my alternative Boost 2.0 vision: Boost 2.0 is a alternative distro of modular standalone Boost libraries which can be each downloaded separately. Each has contemporary per commit CI testing and is nightly dashboarded by quality score by a web service under the 19 quality score headings listed at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook (still unfinished, but nearly there). APIBind allows the library end user to dependency inject what dependencies that library uses. This allows a Boost library, in a single codebase, to be part of both the monolithic Boost 1.x distro and to be modular and standalone and part of the Boost 2.x distro. Motivated library maintainers port their Boost 1.x library to the APIBind platform, and therefore can be part of both 1.x and 2.x distros if they want. Those libraries not ported to APIBind remain in the 1.x distro, which I would assume will gradually fade into obsolescence over time. This makes sense, as if a maintainer is not motivated to do the port then it seems proper that library should gracefully deprecate. There is some empirical data supporting the inevitability of this alternative vision of Boost 2.0. Of the ten libraries I examined in any detail: * Just 1.5 libraries have any dependencies on Boost headers at all (the 0.5 is because that library is currently removing its Boost dependencies). * Just 3 libraries can use Boost.Test. * Just 3 libraries use Boost Docs. * Just 2 libraries require using Boost.Build. The rest are header only, or use cmake. * Just 6 libraries use Travis/Appveyor for free CI testing on Linux, OS X and Windows. * Just 3 libraries use valgrind as part of their unit testing (two are mine!). * Just 3 libraries use coveralls for coverage reporting (two are mine!). Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost. I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

28 133

Deprecation Policy
by Rob Stewart 21 May '15

21 May '15

Some Boost libraries are unmaintained, some are under-maintained, and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it. Please consider my initial thoughts below and provide ideas on such a policy. I will try to capture your ideas and create a policy statement for later review. It would seem obvious that unmaintained libraries should be deprecated, but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. Another issue is deciding when a library is unmaintained. Boost prefers that library authors and maintainers seek a replacement when no longer able to provide maintenance. Unfortunately, that doesn't always happen. Thus, establishing criteria by which to judge a library as unmaintained is warranted. Many continue to use C++03 and benefit from the presence of libraries that only support that language. I think it a non-starter to suggest that a library is unmaintained, or under-maintained, because it hasn't been updated to use C++11/14. Indeed, a replacement library may be the better way forward, while the old library might remain in Boost releases. Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries. Libraries that have superior replacements in Boost releases seem like obvious candidates for deprecation. There is precedent for that: Boost.Signals was deprecated in favor of Boost.Signals2. There are some likely libraries in this category, such as Boost.Lambda. Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___ Rob (Sent from my portable computation engine)

12 33

[preprocessor] Link to Boostpro site for introduction to preprocessor metaprogramming
by Edward Diener 20 May '15

20 May '15

The preprocessor documentation has a link to the Boostpro site which had an html version of the Appendix A of "C++ Template Metaprogramming" by Abrahams and Gurtovoy. Appendix A is "An Introduction to Preprocessor Metaprogramming", which is all about Boost PP. Alas Boostpro is no more and the link in the preprocessor documentation goes nowhere. I can remove the link and any notice of the introduction. But If either David Abrahams or Aleksey Gurtovoy are still around it would be nice to get the html pages which existed before and incorporate them into the Boost PP docs. Does anyone know how to contact either of them ? I can try their addresses in maintainers.txt but I do not want to directly encroach on their privacy if there is a better way.

2 4

Interest in non-intrusive signal/slot lib?
by Emil Dotchevski 20 May '15

20 May '15

Hello, I realize that Boost has Signals library already, but I've implemented a non-intrusive one which approaches the problem differently, and I'm pretty sure that there is no overlap between the two. It turned out more generic than I originally anticipated, so I thought I'd ask if others would find it useful as well. Specifically I was motivated by wanting to use Qt without MOCing. I asked the Qt community if that was possible which generated several rather annoyed negative responses. :) The issue is that while in Qt it's possible to use any function as a Slot, to define a new Qt signal for an existing Qt type one needs to derive from the Qt type, define the signal (as a member function) and do the MOC dance -- which I wanted to avoid. The result is a small, non-intrusive signals/slots library that allows objects of any type to be used as signal emitters, e.g. one of the included examples shows how signals can be emitted by a Windows HWND object. Documentation and source code released under the Boost license can be found here: http://www.revergestudios.com/boost-synapse/. Thanks, Emil P.S. Thanks to Peter Dimov for his feedback and for coming up with the name Synapse. :)

9 48

Version mismatch on develop
by Peter Dimov 20 May '15

20 May '15

On the current develop, autolink wants to link to (for instance) libboost_filesystem-vc80-mt-s-1_59.lib, but b2 builds libboost_filesystem-vc80-mt-s-1_58.lib. That's because BOOST_VERSION has been updated to 1.59 in boost/version.hpp, but is still 1.58 in Jamroot.

2 1

[type_traits] A bug in has_nothrow_default_constructor
by Andrzej Krzemienski 20 May '15

20 May '15

Hi All, I have submitted a new ticket: https://svn.boost.org/trac/boost/ticket/11324 Given the information floating around that Boost.TypeTraits are unmaintained and that they are to be replaced with the rewrite, is there any chance that this is fixed, or at least the test case added to regression matrix? BTW, does type_traits v2 handle this case correctly? Regards, &rzej

2 2