- Boost - lists.boost.org

[algorithm] split_copy
by Chambers, Matthew 13 Dec '16

13 Dec '16

I like the simplicity and flexibility of boost::algorithm::split, but whenever I do some one-off, trivial split with it where performance isn't an issue, I find myself wishing that I didn't have to predeclare the result container. That is, I want a split_copy which returns the result container by value, analogous to the many other *_copy functions in boost::algorithm. This turns the split into an easy to read one-liner. Is there a technical reason that this doesn't exist, or just something the boost::algorithms developer didn't think was sufficiently sweet (syntactic-sugar-wise) to add? Thanks, -Matt

2 2

Synapse library review starts today December 2
by Edward Diener 13 Dec '16

13 Dec '16

The formal review of the Synapse library by Emil Dotchevski starts today, December 2, and is scheduled to continue through December 11. This gives two full weekends and the week in between for the formal review. Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[synapse]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. I encourage all programmers with an interest or knowledge of signal/slot processing to be part of the review or discussion of the Synapse library as your time permits.

8 27

[spirit] [qi] What's the differences between qi::uint_parser<int>() and qi::uint_parser<unsigned int>()?
by Han Wang 13 Dec '16

13 Dec '16

Both of them are the same as qi::uint_(parsing integers from 0 to UINT_MAX). For qi::uint_parser<int>, the required maximum value of numeric base type int is not used at all.

2 1

[release 1.63] required bugfixes
by Oliver Kowalke 13 Dec '16

13 Dec '16

Hi, during the test of boost-1.63 rc 1 some problems occurred (see Marshall's and Stephan's postings). I request to merge my last commits (on branch master) from boost.context and boost.fiber into boost-1.63 (rc 2?) - as well as commit 13f5d9c88ae5363fe547f04c1d272b2a772a8b4d from boost.config. Otherwise the build will fail for gcc-7.1, clang-4.0 and mingw64. best regards, Oliver

1 0

[fiber] Boost.Fiber 1.63.0 RC1 tries to use std::mutex which MinGW doesn't have
by Stephan T. Lavavej 13 Dec '16

13 Dec '16

In both 1.62.0 and 1.63.0 RC1, building Boost.Fiber with my MinGW-w64 distro fails. That's because libstdc++ doesn't natively support the Clause 30 multithreading headers (std::mutex etc.) on Windows, and I make no attempt to build wrappers between the Windows and POSIX APIs (which is my personal choice). Boost's build system should detect this, and use the perfectly valid Boost.Thread implementation. Indeed, "C++11 mutex : no" is printed during the build's configuration, but Fiber's build fails anyways. My configuration output, and the errors emitted by a typical translation unit, are recorded here: https://github.com/StephanTLavavej/mingw-distro/issues/28 Thanks, STL

1 0

copied boost files in other projects
by Oliver Kowalke 12 Dec '16

12 Dec '16

I encountered some projects that have copied files from boost and replaced the copyright and license notice by their own. Other projects have added their own license (for isntance MIT, LGPL ...) beside the Boost license notice in the copied files - does this mean that the code is dual licensed now?. How does the boost community deal with this? Oliver

9 16

Review period has ended for the Synapse library
by Edward Diener 12 Dec '16

12 Dec '16

The review period has officially ended for the Synapse library by Emil Dotchevski. I have received one e-mail specifying a review that will come sometime today and therefore will wait before making my decision as Review Manager for that review and Emil's possible response. I would like to thank all those who took part in the review during the review period, and Emil for responding to the remarks of those who have participated. I know another library will shortly begin its review, but I will not rush my final analysis and decision regarding Synapse and intend to make it sometime by the end of this week. Edward Diener, review manager

1 0

Re: [boost] [synapse] Synapse library review starts today December 2
by Barrett Adair 12 Dec '16

12 Dec '16

On Fri, Dec 2, 2016 at 8:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > - What is your evaluation of the design? I don't know anything about Signals2, but I find the "non-intrusive" argument to be compelling. I don't like that the invocation mechanism is single-threaded by default. I think the thread_local approach is interesting, but it sounds ripe for confusion in application code. > - What is your evaluation of the implementation? This code style is quite foreign to me, but it seems consistent. The mix of Boost and std libraries seems arbitrary (e.g. boost::shared_ptr and <thread>). The Boost.Function dependency appears redundant. The callback is effectively being erased twice. std::invoke or equivalent could serve as a replacement. I don't much like signal_traits.hpp and the limitations it imposes. Arity is capped at 4 parameters, and the signal type must be passed explicitly. The latter is surely good for compile times, but I think it would be nice to have a deduced signal type version that could still support stateful lambdas and member functions. I browsed the test cases, and they seem rather in-depth. I think some comments in this code are warranted. > - What is your evaluation of the documentation? The tutorial is very well done. Overall, the documentation is very solid. I enjoyed reading it. Quickbooks and syntax highlighting would be nice. This line was disappointing: "requires compiler support for the following C++11 features" I have seen this in existing Boost library documentation, so there is precedent, but I do not like it at all. I much prefer to see a range of tested compiler versions, even if it's only a couple. Continuous integration services like Travis and Appveyor are free, and very useful toward this end. > - What is your evaluation of the potential usefulness of the > library? It appears that it could be useful to Qt users. I personally would not find this useful. > - Did you try to use the library? With what compiler? Did you > have any problems? I ran the logger example with GCC 5.3 on Ubuntu 16.04. No problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? 4 hours combined of reading the documentation and playing around with the implementation code. > - Are you knowledgeable about the problem domain? My experience with C++ signal libraries is limited. I am comfortable using the Intel TBB flow graph library, which has some degree of overlap. I have a bit of experience with event-driven programming in other languages. I am knowledgeable about C++ callable types and compiler support for their variations. > - Do you think the library should be accepted as a Boost library? This is my first formal review participation, I don't have a library in Boost, I'm not familiar with Signals2, and I do not have a use case for Synapse, so I'm not going to answer this question. Please consider this message as a "technical comment" instead. P.S. For whatever it's worth, I did fork the Synapse code and implement tentative variadic support in connect.hpp and emit.hpp (though I did not get around to translate.hpp). https://github.com/zajo/boost-synapse/compare/master...badair:master It appears to work as-is with the logger example, but similar work would need to be done in translate.hpp to make it fully variadic. I used my proposed CallableTraits library with the intention of implementing deduced signal types, but I ran out of willpower. Please forgive the aggressive formatting.

2 1

Boost.IOStreams mapped_file_sink missing flush() functionality
by AB 11 Dec '16

11 Dec '16

Hello, I wish to bring to your attention two issues regarding mapped_file_sink from Boost.IOStreams (release 1.62.0): 1. There is no member function `mapped_file_sink::flush()` which I would like to use in my program. I believe it could be implemented portably by using `msync()` for POSIX and `FlushViewOfFile()` for Windows; was the omission of this function a deliberate choice or a minor oversight? 2. The member functions `begin()` and `end()` are implemented for mapped_file_sink but are not documented! This will lead to programmers relying strictly on the docs to use `data()` and `data()+size()` instead. Please update the documentation for the next release 1.63.0.

3 3

[1.63.0] Master is closed for beta release + release notes
by Daniel James 10 Dec '16

10 Dec '16

Hello everyone, The master branch is now closed for the beta release. Please can you add any remaining entries to the release notes, either by emailing me, or by creating a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… To do so, click on the little pencil icon at the top right of the code. thanks, Daniel

4 3