- Boost - lists.boost.org

boostdep documentation?
by Robert Ramey 22 May '15

22 May '15

I am interesting in taking a look at boostdep. I see the code in tools/... but I don't see any documentation. Is there any? will there be in the future? Robert Ramey

2 3

Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 22 May '15

22 May '15

I've been keeping away because I am doing a ton of work on the library, and I don't want to attract too much attention until the work is ready, since there are lots of changes. But, I think I should reply, and I will also give a brief update of the progress at the end of the message. > I suspect this code: > > Depth depth = default_<Depth>(); > > could be made to look like this: > > Depth depth = _default; > > > ie all enums have a constructor that takes a default_t type. The > constructor then calls default_<T>(). > Or something like that. And then change the names to get > > Depth depth = default_; // calls default_impl<T>(); That’s a good idea. I hadn't thought of such a constructor. I will try it out, but I am not sure that it would belong directly in the library, if that's what you mean. It's not clear where one should stop. Should there also be an "invalid" constructor for projects that have such a notion? Are there other special values we can't predict? Perhaps this could be achieved with some kind of extension facility. I will eventually be adding either support for subclassing, or extra macros, or some kind of template-based extensibility. To the other commenters: thanks :) As for progress: there are substantial improvements. - The entire interface is now constexpr, including string functions and iterators. - I ported the interface to C++98, though it still requires __VA_ARGS__. This makes the topic of this message inaccurate. Should I start a new thread for the new version when it's up? - The C++98 conversion means that, in theory, the library should work on MSVC down to VS2005. I will be testing that when I get my new notebook in a few days. If successful, Better Enums will be compatible with the 3 major compiler families. - Eliminated all weak symbols, leaving only standard C++. Some may be brought back later for optimization, but they are no longer required. - When compiling for C++11, there are no more implicit conversions to integers. - The library is now a single header file, containing both the C++11 version and the C++98 port, and all helper macros. - The documentation is getting a major improvement, so please don't look now. The all-constexpr version is unfortunately noticeably slower to compile. The performance test that was previously two times faster than including iostream is now twice as slow, but I can mitigate this with some combination of opt-in and optimization. Anton

1 0

[build][test][gsoc] question about compiling tests with multiple compile params using b2
by Damian Vicino 22 May '15

22 May '15

Hi, I’m working in the safe_float library for the GSOC. For testing I’m using the boost.test library and for building I’m using b2. The implementation have several pieces that are implemented in two flavours, one for compilers supporting FLOAT_ENV and one for those not supporting it. (this is a C++11 feature missed in at least clang and gcc compilers) Right now, the implementation is selected with an #ifdef and I #define them with a -D parameter. My config file for test is: using testing ; lib boost_unit_test_framework ; unit-test test : main-test.cpp [ glob *_test.cpp ] boost_unit_test_framework ; I guess I can generate 2 different executables using 2 targets, duplicating last line and adding something to tell it to pass -DFENV_AVAILABLE, but I couldn’t find how to do that. Having 2 executables for the tests and running them both will provide testing for both compilation paths (when using a compiler supporting FENV). Also, I’m wondering if B2 has the inteligence detect and pass a parameter when using a compiler supporting FENV. Is there any common approach for these situations where conditionally compiling based on a c++ feature support? In the case a Boost.Build needs to define a test for detecting if the compiler supports the feature (autoconf-like) it can be tested compiling a one-liner file: test.fenv.cpp #pragma STDC FENV_ACCESS ON When compiled: clang++ -c test.fenv.cpp test.clang.cpp:1:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON The warning means the feature is not supported. Thanks for any guidance in this area, I’m pretty newbie with the b2 system. Best regards, Damian

2 1

[Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 21 May '15

21 May '15

Hello, I’ve just released an enum library that takes advantage of constexpr functions and literal types to provide a nice declaration syntax and decent feature set: https://github.com/aantron/better-enums <https://github.com/aantron/better-enums> I’d like to get feedback on it from the experienced developers here at Boost. Is this approach useful? Are any major features missing? Would this be an interesting candidate for enums in Boost? I am very willing to do further development on this project. The library's basic features are string conversions, value and name listing, some type safety, and a declaration syntax that is based on built-in enums and is easy to learn and use. A much more "advanced” feature is that the generated class is a literal type, and almost everything is constexpr. Here is a simple example, that takes advantage of this, of a compile-time encoding of project policy: https://github.com/aantron/better-enums/blob/master/example/6-traits.cc <https://github.com/aantron/better-enums/blob/master/example/6-traits.cc> . Once I make the iterators constexpr as well, by providing a way to increment them other than mutation (++), it will be easy to write rather involved compile-time algorithms that process Better Enums declarations. Here is an example of a whole bunch of simple compile-time processing already possible: https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc <https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc> . Some of that could be useful when C++ declarations are generated by script. The library is all standard C++11 (to the best of my knowledge), except for the usage of weak symbols for some generated constexpr static arrays. I have tested it successfully on clang and g++, but I would need help getting access to more compilers. I believe weak symbols are not a problem for MSVC, but I still don’t believe the library will compile on MSVC since I don’t think MSVC supports enough of C++11 yet. Performance is what I would call excellent. I compared compilation times of these two files to each other: https://github.com/aantron/better-enums/blob/master/test/performance/4-decl… <https://github.com/aantron/better-enums/blob/master/test/performance/4-decl…> https://github.com/aantron/better-enums/blob/master/test/performance/5-iost… <https://github.com/aantron/better-enums/blob/master/test/performance/5-iost…> The first file includes enum.h and declares a bunch of enums, and the second merely includes iostream. On my machine, clang compiled all those enums in about half the time it took to process iostream. g++ was faster on iostream, but only slightly. Using a lot of compile-time expressions would have additional cost, but it has been too small to measure for “realistic” examples from my own usage. I haven’t yet made an example that repeatedly deals with a very large enum at compile time to properly measure that impact. I’ve also explored an alternative interface where the constexpr properties provided by the library are in a traits class parametrized by a normal C++11 enum class, but the interface seemed too verbose. There is also a bitset type that has a very slightly nicer interface than std::bitset for usage with enums, but I didn’t think the improvement was worth the user’s learning effort. I can put these in branches if there is interest, however. Please let me know what you think. Best, Anton

5 4

[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