- Boost - lists.preview.boost.org

Re: [boost] [stacktrace] review (changing vote to NO)
by Artyom Beilis 26 Dec '16

26 Dec '16

> > 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding > > the use of the library. > > Those flags are not required because addr2line can extract information > from debug sections of the binary. Yes.. this is exactly the issue - I don't think that addr2line should be used by default. Getting the stack trace using dladdr works very well - so no need to use add2line unless absolutely required. I also want to hear regarding inefficiency of add2line use - creating the process for each stack frame you wanted to trace. It is very inefficient so I suggest not to use one. Finally reviewing your code once again I realized following: 1. Instead of using adde2line to get the object name you can just call add2line with /proc/12345/exe (works with dynamically loaded shared objects as well - i tested it) 2. Use of addr2line for every each frame must be fixed But what is most important that I understood that you don't even use dladdr to get function names even if you can - which is very bad decision. Additionally I realized that with_trace and traced aren't parts of the library! These should be built in there by default. -------------------------- After using the library and running couple of tests on Linux with GCC.. I have to revoke my "Conditional YES" vote and change it to "NO": And the reason is following: 1. Linux/*nix backend is poor - instead of using dladdr to get function names easily as I do in the backend I written and use on CppCMS [1] you call external exe in very inefficient way. 2. I realized that the library does not provide the basic functionality like collecting strack trace on throw (what I thought was built in but I was mistaken) 3. No answer for non MSVC compilers built in. But the most important reason that the library does not feel mature enough in terms of both backends and frontends. I strongly strongly strongly recommend to continue the work on the library as it provides important functionality. The frontend should be adjusted a little to couple with common cases. The backend must be modified to not to fork/exec by default and optimize one significantly. I clearly understand you to want to use addr2line as it gives more power but it can't be used by default. I searched for a long time for a lightweight solution for converting addresses to the function names for CppCMS including trying to use debug information but couldn't find anything suitable besides dlfunc. However addr2line is by no means can be accepted as "default" solution. I also recommend to take a look on cppcms's backtrace library it is very simple and provides critical information in production environment. Regards, Artyom Beilis [1] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/lib… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

6 11

[root_ptr] Potential support from Qt & QtQuickCompiler
by Phil Bouchard 25 Dec '16

25 Dec '16

Greetings, As you know the WebKit project has a very complex memory manager that cannot be swapped easily but The Qt Project might be interested for a faster alternative than the garbage collector: http://lists.qt-project.org/pipermail/development/2016-December/028199.html This is just a head's up in case anybody is interested into the subject and is aware of Qt. I know by experience garbage collectors will always let you down for complex projects so I think there is no other solution. Thanks & Merry Christmas, -Phil

1 0

Boost 1.63.0 Release Candidate 2
by Marshall Clow 25 Dec '16

25 Dec '16

The second release candidate for the 1.63.0 release is now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The only changes are in Boost.Config, Boost.Context, and Boost.Fiber. The SHA256 checksums are as follows: 25db3956a8d58187ac7a0702cc917e9bab47ff90baafc35e4e789dca1ce5f423 boost_1_63_0_rc2.7z beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 boost_1_63_0_rc2.tar.bz2 fe34a4e119798e10b8cc9e565b3b0284e9fd3977ec8a1b19586ad1dec397088b boost_1_63_0_rc2.tar.gz 97ce6635df1f44653a597343cd5757bb8b6b992beb3720f5fc761e3644bcbe7b boost_1_63_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

5 6

Re: [boost] Boost 1.63.0 Release Candidate 2
by Stephan T. Lavavej 24 Dec '16

24 Dec '16

[Marshall Clow] > The second release candidate for the 1.63.0 release is now available at: > https://sourceforge.net/projects/boost/files/boost/1.63.0/ > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. 1.63.0 RC2 successfully built for mingw-w64, without any workarounds. (Boost.Fiber is detecting my lack of std::mutex and simply not building, which is fine by me.) Notably, this is the first time that I've ever been able to build Boost without patches or workarounds. This is after bootstrap.sh was fixed for mingw-w64/msys2, Context/Coroutine/Coroutine2 were fixed to build for mingw-w64, and Python auto-detection started working again. Yay! Thanks, STL

2 1

Stacktrace review: concern, probable solution and review news
by Antony Polukhin 23 Dec '16

23 Dec '16

Hi, The biggest concern with the stacktrace library is it's usability in async-signal-handlers. Here are some facts: * users definitely want to use the library in async-signal-handlers to print stacktraces on SIGSEGV/SIGBUS/SIGABRT * the only cross-platform async-signal-safe thing that can be done - is to print function addresses (without names and source line locations) * reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations). So, the solution: * Change `basic_stacktrace<size_t>` to `basic_stacktrace<class Allocator = std::allocator<void*>>` and make it's constructor async-unsafe and add additional runtime parameter for stack depth. * Provide async-safe functions that dump addresses separated by whitespace (format also acceptable by addr2line and atos): * `void dump_stacktrace(int fd)` * `void dump_stacktrace(HANDLE fd)` * `void dump_stacktrace(const char* filename)` * Provide an example with dumping callstack to a file and printing it on program restart Does it seem reasonable? Does it satisfy your needs? Review news: * User named LogicalKnight tested the library on MacOS and it works well. A few issues in examples must be fixed: https://github.com/apolukhin/stacktrace/issues/10 My list of TODOs for the library: * Fix the async unsafe code in signal catching example * ? Provide a low-level API for getting stacktrace as array of void pointers * MinGW fails to compile, because of missing "Dbgeng.h" headers. This must be fixed by manyally forward declaring required functions using the boost.winapi way. * Add a note about the Boost.Exception usage to the example with embedding stack into exception. * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to produce a non-forking solution * ? Deserialization/inspection of stacktrace on other machine * BOOST_NOINLINE inline trick to avoid printing internals in the stacktrace + fix Intel warnings * At github one of the users was complaining about the performance of ostreaming operations. There is a way to significantly speedup ostreaming without changing the interface of the library. I'll do the optimization after the Boost Review. * Improve docs for the "Build, Macros and Backends" sections (say that library is using system headers, no 3rd party libraries must be installed or manually linked; backtrace() is LINUX specific, not POSIX) * Add a note to the docs that library is header only by default and usable in C++98/C++03. Things NOT to do ever: * Integration with BOOST_THROW_EXCEPTION and Boost.Exception - those ideas are out of the library scope * Callbacks to do things on stacktraces - no way to satisfy all the needs and make them optimal on all the platforms. Do some caching instead -- Best regards, Antony Polukhin

5 11

Re: [boost] [Stacktrace] review
by Barrett Adair 23 Dec '16

23 Dec '16

On Wed, Dec 14, 2016 at 2:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > The formal review of the Stacktrace library by Antony Polukhin starts > today 14th Dec and will conclude before Christmas. I appreciate we > are likely a bit tired out from the many library reviews recently and > of course it's Christmas, but given the lack of a portable way to > work with stack backtraces, which you inevitably need to do > eventually in any non-toy production application, Stacktrace needs > your review! > > For your review you may wish to consider the following questions: > > What is your evaluation of the design? I like it. > What is your evaluation of the implementation? I've never implemented a stacktrace reader, so I don't have much to add. The code did not raise any red flags for me, though. > What is your evaluation of the documentation? Documentation is solid. > What is your evaluation of the potential usefulness of the library? Very useful. I will likely use this at work. > Did you try to use the library? With what compiler? Did you have any problems? Yes, GCC 5.3, no problems. This stacktrace made me smile: 0# boost::stacktrace::detail::backend::backend(void**, unsigned long) 1# s::~s() 2# void __gnu_cxx::new_allocator<s>::destroy<s>(s*) 3# void std::allocator_traits<std::allocator<s> >::destroy<s>(std::allocator<s>&, s*) 4# std::_Sp_counted_ptr_inplace<s, std::allocator<s>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() 5# std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() 6# std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() 7# std::__shared_ptr<s, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() 8# std::shared_ptr<s>::~shared_ptr() 9# hello()::{lambda()#1}::~hello() 10# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) 11# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_manager(std::_Any_data&, std::_Function_base::_Base_manager<hello()::{lambda()#1}> const&, std::_Manager_operation) 12# std::_Function_base::~_Function_base() 13# std::function<void ()>::~function() 14# void std::_Destroy<std::function<void ()> >(std::function<void ()>*) 15# void std::_Destroy_aux<false>::__destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 16# void std::_Destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 17# void std::_Destroy<std::function<void ()>*, std::function<void ()> >(std::function<void ()>*, std::function<void ()>*, std::allocator<std::function<void ()> >&) 18# std::vector<std::function<void ()>, std::allocator<std::function<void ()> > >::~vector() 19# hello() 20# main 21# __libc_start_main 22# _start > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 45 minutes total. I skimmed the code, the documentation, and the test cases. Then, I made a little test program. > Are you knowledgeable about the problem domain? No. > Do you think the library should be accepted as a Boost library? Yes, unequivocally. The concerns about async safety are interesting, but ultimately this library is useful to me (and likely many others) regardless of signal support. Barrett

1 0

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Remi Chateauneu 22 Dec '16

22 Dec '16

Maybe the RDTSC instruction might help for x86 processors, as it returns a number of ticks which is reset at startup. It is also extremely fast. Le 22 déc. 2016 13:04, "Thomas Dahms" <thomas.dahms(a)native-instruments.de> a écrit : Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 1

[interprocess] Getting boot-up time is unreliable on Windows
by Thomas Dahms 22 Dec '16

22 Dec '16

Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com

1 0

Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

The release candidates for the 1.63.0 release are now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The SHA256 checksums are as follows: 010699561c6011e6d97dc453d55bc5e54cdc192622434eff7b8ac559efac846c boost_1_63_0_rc1.7z d8ebf8d90b2f823f04119445ac339d704395d655907333ec0fab863040119d24 boost_1_63_0_rc1.tar.bz2 dabe29b8a60369ae7c15c20681a32717f3c37d97e5dc6d39c5b2fd0494b8e995 boost_1_63_0_rc1.tar.gz 1683942022fd63c205c48fb2155af6094c67ef67aa13ffb3e1db78fecf817efe boost_1_63_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

12 25

Please update Track config
by Antony Polukhin 21 Dec '16

21 Dec '16

Hi, Please, change the default owner for variant issues from ebf to apolukhin (it's me, I'm taking care of the library for last few years). This change will help me to react faster on variant issues. Also, please add the dll component into the list of components so that people could properly report Boost.DLL issues https://github.com/boostorg/dll. Make me (apolukhin) the default responsible for the issues. Thanks in advance! -- Best regards, Antony Polukhin

1 0

Re: [boost] [Boost] [Stacktrace] review
by Nat Goodspeed 21 Dec '16

21 Dec '16

On Wed, Dec 14, 2016 at 3:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > I'm generally pleased with the design. There's a documentation section "Exceptions with stacktrace" that discusses techniques for incorporating stacktrace data into your own exceptions. I see a real possibility for integration with Boost.Exception, perhaps even a mechanism to make BOOST_THROW_EXCEPTION embed the stacktrace at the throw point. This is not an objection to accepting the library, but rather a feature request for when we do. I do have a question about use of a template parameter to constrain the number of entries, rather than a runtime parameter. Presumably that's necessary to permit certain backend implementations to be async-signal-safe? (Whatever the rationale, a note in the documentation explaining it would be nice.) My objection to that is that apparently, with the present design, if I want to write a function that accepts any specialization of basic_stacktrace, that must itself be a template function. If I'm correct about the reason for using a template parameter, would it be reasonable to split the class into a non-template base class supporting all the methods, with a template subclass that provides the storage? The base class could store a (pointer, length) passed by the subclass constructor. Without having looked at the implementation, I expect that you wouldn't even need virtual-function dispatch: the only indirection would be through the data buffer pointer. That would even permit a subclass that provides dynamic storage, for async-signal-unsafe use. Then a processing function could accept reference-to-base-class and handle any stacktrace instance. > - What is your evaluation of the implementation? Sorry, I haven't looked at the implementation. > - What is your evaluation of the documentation? > Generally good. It could stand a cleanup pass; there are a few typos here and there. I do like that each method explicitly states both complexity and async signal safety. The description of the nullary frame() constructor says that source_line() will return both empty string and 0. > - What is your evaluation of the potential usefulness of the > library? > VERY! I want this. > - Did you try to use the library? With what compiler? Did you > have any problems? > No, I haven't tried to use it. (A deadline is coming up fast.) > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I read through the documentation. > - Are you knowledgeable about the problem domain? > I have occasionally used platform-specific tactics to try to achieve the same thing, on a couple different platforms. Each time it's been painful enough to make me wish that this problem were solved, once and for all. > And finally, every review should attempt to answer this question: > > - Do you think the library should be accepted as a Boost > library? > Yes I do. I would like to see the non-template base class, but that's not a showstopper: I would rather have this library without than not have it at all. As I mentioned, I would like to see integration with Boost.Exception. That just seems like a natural next step. I see further opportunities for integration with Boost.Context, Boost.Fiber...

11 121

Stacktrace library starts review today 14th Dec
by Niall Douglas 21 Dec '16

21 Dec '16

The formal review of the Stacktrace library by Antony Polukhin starts today 14th Dec and will conclude before Christmas. I appreciate we are likely a bit tired out from the many library reviews recently and of course it's Christmas, but given the lack of a portable way to work with stack backtraces, which you inevitably need to do eventually in any non-toy production application, Stacktrace needs your review! Stacktrace is an optionally header-only library providing four implementation backends, libunwind (POSIX only), windbg (Windows only), backtrace (from the C library on most POSIX implementations) and a null backend. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[stacktrace]' 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 's_sourceforge at nedprod 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? Most of my personal concerns with this library are with the implementation and I would hugely appreciate feedback from others with substantial experience of using stacktracing "in anger" in non-trivial use case scenarios. - 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. Finally, thanks to Edward whose announcement of the Synapse library review I borrowed heavily from as I thought it very well structured. Hopefully the above is just as clear. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 21

Re: [boost] [EXTERNAL] Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

On Tue, Dec 20, 2016 at 2:51 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > On Tue, Dec 20, 2016 at 12:49 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: > >> >> >>>>>> >> >>>>>> As I mentioned to Marshall, the results here: >> >>>>> http://www.boost.org/development/tests/develop/developer/ >> config.html >> >>>>> are >> >>>>> horribly outdated - are they actually being run and updated? >> >>>>> >> >>>>> >> >>>> It appears that all 'develop' tests are at least one week late if not >> >>>> much >> >>>> more. >> >>>> >> >>> >> >>> >> >>> I was not aware of the stalled results.. Investigating now. >> >>> >> >> >> >> I think Sandia testers on Darwin and Linux are cycling okay in both >> >> develop and master, there’s results up there from Dec 20th. Are the >> Sandia >> >> config test results wrong or unexpected? >> >> >> > >> > The latest results from Sandia that I can see are from 12th. The report >> > info[1] also says it was run last time on 12th. >> > >> > [1]: http://www.boost.org/development/tests/develop/developer/ >> index.html >> >> >> The report generation issue is now addressed. The results are current and >> show tests from today. >> >> > I see lots of new results for "master", but none for "develop". (yet) > > Interesting. This page: http://www.boost.org/development/tests/develop/developer/config.html shows new results, but this one http://www.boost.org/development/tests/develop/developer/summary.html does not. -- Marshall

3 3

[test] Really deactivate test
by Florian Lindner 19 Dec '16

19 Dec '16

Hello, I need to conditionally decativate tests and use a custom decorator for that, like that: virtual void apply(bt::test_unit& tu) { [...] if (std::find(_ranks.begin(), _ranks.end(), rank) == _ranks.end()) { std::cout << rank << " Disable, because of rank, test: " << tu.full_name() << std::endl; tu.p_default_status.value = bt::test_unit::RS_DISABLED; return; } } (i'm happy to provide full source code, if anyone is interested) As you can see it's deativated on some MPI ranks only. However, if a user uses -t "testname" it is activated again. Is there a way to really deactivate the test? Or delete it from the test tree? Thanks, Florian

2 5

[variant] gcc crash
by Igor R 18 Dec '16

18 Dec '16

Consider the following snippet (trying to compile with Boost 1.62): ///////////////////////////////////////////////////////////// #include <boost/variant.hpp> template<class Node> struct node1_type; struct var_type; using var_base = boost::variant<int, boost::recursive_wrapper<node1_type<var_type>> >; template<class Node> struct node1_type { Node child; }; struct var_type : var_base { using var_base::var_base; }; int main() { var_type v1 = 1; } /////////////////////////////////////////////////////////////////// It crashes GCC: http://melpon.org/wandbox/permlink/A6BuYqqrG4COcfFl and produces compilation error with any released version of Clang: http://melpon.org/wandbox/permlink/1JQ7OVLV3crERRJX (Although it does compile with Clang-4 trunk). I'd appreciate if Variant maintainers could take a look at it. Thanks.

3 2

Re: [boost] [Boost-users] Stacktrace library starts review today 14th Dec
by Antony Polukhin 18 Dec '16

18 Dec '16

2016-12-15 3:44 GMT+03:00 Edward Diener <eldiener(a)tropicsoft.com>: > In the documentation for stacktrace I do not see anything about what level > of C++ is required for a compiler using the stacktrace library or any > information on what compilers have been tested when using the library. It's C++98. Tested on latest clang(c++03, c++11), gcc(c++98, c++11, c++1y), msvc. > In the section of "Build, Macros and Backends" I do not think there is > enough information about using a particular backend, other than saying that > you need to link with such-and-such. Does stacktrace "automatically" find > the header files it needs from these backends ? Even so I think some > information about where it looks for the backend header files need to be > given. I also think that some information of what libraries it looks to link > with needs to be given. I am assuming it links with the static versions of > these backend libraries unless I define either BOOST_STACKTRACE_LINK and > BOOST_ALL_DYN_LINK, or BOOST_STACKTRACE_DYN_LINK. What if I want to use the > header-only version but I want to link with the shared library backend ? I > also assume that if I link with the static library backend I should probably > be linking with the RTL static library, while if I link with the shared > library backend I should also be linking with the RTL shared library. > > What about 32-bit versus 64-bit use of stacktrace ? Do they both work as > advertised with the correct backends, whether static or shared ? I think the > "Build, Macros and Backends" need rto be expanded to cover alol these > topics. All the headers are found automatically and the library is header only if you do not define BOOST_STACKTRACE_LINK or BOOST_STACKTRACE_DYN_LINK. Backend is chosen automatically in header only mode. You need to do nothing, unless you encounter some problems on default setup (like you OS is POSIX but not LSB Core Specification 4.1) or unless you wish to disable stacktraces. If you define BOOST_STACKTRACE_LINK or BOOST_STACKTRACE_DYN_LINK you have to manually link with one of the backends. I'll try to improve the "Build, Macros and Backends" section to be more clear. -- Best regards, Antony Polukhin

3 3

[iterator][type_traits] A test is failing with gcc in c++03 mode
by Edward Diener 17 Dec '16

17 Dec '16

The zip_iterator_test_std_pair is failing with gcc in c++-03 mode. The problem reduces viqa Boost type traits to the fact that in gcc c++03 mode the expression: __is_abstract(std::pair<int&, std::string&>) where __is_abstract is a compiler intrinsic, gives an error of: error: forming reference to reference type 'std::__cxx11::basic_string<char>&' pair(const _T1& __a, const _T2& __b) ^~~~ Is this a valid error according to the C++ 2003 standard ? The test works in c++11 or c++14 mode.

4 8

Synapse library review result
by Edward Diener 14 Dec '16

14 Dec '16

The Decision --- -------- There were a total of 9 people, outside of the library author Emil Dotchevski, who reviewed/commented about the Synapse library during the review period and the Monday following where I accepted a late review and people's responses to that late review. The voting in the Synapse review is: 0 for YES 2 for NO, with one of the two a provisional NO. Among the other people who commented but did not vote I have 2 people who said they definitely liked the library and 2 people who said they definitely did not like the library. Among other commenters I interpreted 2 other people as probably approving of the library as it now is and 1 other person as probably not approving of the library as it now is. Given the actual YES or NO vote, and the small amount of people who took part in the review, and the even smaller amount of people who decided to vote YES or NO for the library, the Synapse library is NOT accepted into Boost. My decision as review manager is based on the review of the library by others and not on my own personal view of whether the library should be accepted or not. Issues ------ I want to use the next part of this decision to summarize the issues brought up largely, but not exclusively, by those who did not see the Synapse library as currently being worthwhile to become a part of Boost. This issues I summarize below may or may not be seen as relevant or not by others but they do represent the areas of criticism of the library made during the review. All the issues were answered by Emil during the review, and I think he did an excellent job of answering reviewers based on how he sees these issues. Some of these issues may be seen as unimportant or trivial or already well answered, but I want to list them all nonetheless. The issues are presented in no particular order of importance. I will refrain from making my own comments about these issues until my own general summary at the end of this review decision: 1) The current Boost signals/signals2 library is adequate for signal/slot processing and another signal/slot library such as Synapse does not provide enough of a usage argument to be added to Boost along with what already exists. 2) The documentation needs to be more expansive on the difference between Boost signals/signals2 and the Synapse library. 3) The end-user should have some sort of control where Synapse stores its information regarding the connection between signal emitters and slots ( signals handlers ). 4) Since Synapse is a C++11 library it should use C++11 standard library constructs across the board rather than their Boost equivalents. 5) There should be some "natural" way in which slots can return a value, ala the signals2 library. 6) A more flexible way of handling the slot lifetimes should be created as an addition to the shared_ptr/weak_ptr way the library currently employs. 7) A means by which a particular thread can be specified ( thread-affinity ) for a particular slot when connected should be created; or a dispatching mechanism, perhaps using asio, for connecting a slot to an emitter. 8) The ability to have signals emitted with more than four parameters should be created. 9) The fact that emitters are identified strictly by address was seen as a weakness in the design since at least theoretically, if not very often practically, it is possible for two different variables to have the same address. Connected to this is that the address of emitters is noted with a "void *" in the public interface, and that was criticized as not C++-like. 10) Connection objects should be movable rather than using shared_ptr. 11) The central dispatching mechanism is too slow for large scale continuous changes which emit signals to be handled by slots in some systems ( a stock market changes type of application was brought up as such an example ). 12) The use of only Boost function as a callable slot is too inflexible. 13) The signal type ( pointer to function whose return type identifies signals ) was seen both as cryptic and inflexible, and a deduced signal type was suggested. 14) Having more than one signal type in Boost in general was seen as a bad situation. 15) More specific information on which compilers should work with Synapse. Summary ------- First of all, thanks to everyone who participated in the review and for Emil for answering and providing explanations for his design and coding decisions. I cannot say it enough but I really hope that more people can be encouraged to look at libraries up for review and make comments, even if they do not want to make an official vote or comment on any particular area in which they do not feel they have adequate knowledge. All comments and personal or technical evaluations are important and help a review manager make a final decision, as well as telling a library author what others think of what he has done. With that said I will not try to hide the fact that I personally view the Synapse approach to signal/slot processing as different enough, and useful enough due to its non-intrusive nature, from signals/signals2 to be a valuable addition to Boost, even while I recognize that there was not enough of a consensus or enough of an interest among others during the review to have that happen now. Among the issue brought forth by others my personal view for possibly improving Synapse to where it might be more acceptable to reviewers and might draw more people's interest as a possibly Boost library in the future pending another review, lies mainly in these numbered issues above: 2), 4), 5), 7), 8), 12), 15). I also feel having the documentation discuss in more detail the major concepts of the library, as a bridge between the Tutorial and the Synopsis, would be very helpful for interesting programmers In Synapse. Of course other people's views may vary greatly, and further discussion of Synapse on the Boost developers mailing list or the Boost users mailing list is, I am sure, welcome to the author of Synapse Emil Dotchevski.

1 0

[root_ptr] documentation fix
by Phil Bouchard 14 Dec '16

14 Dec '16

Greetings, I just realized that root_ptr is "container-oriented" and therefore I added this information to the documentation: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.roo… I think this summarizes it all with these few keywords and at some point people will get tired of the garbage collectors and "click" ;) Sincerely, -Phil www.fornux.com www.finitetheory.com www.loaapu.com (in progress)

1 0

[synapse] Review
by David Sankel 14 Dec '16

14 Dec '16

On Fri, Dec 2, 2016 at 9:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > > For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > The design looks reasonable. > - What is your evaluation of the implementation? > I found the use of typedef's to functions returning inline struct definitions to be overly clever and cryptic to new C++ developers. I also found the lack of static type checking in certain places to be objectionable. The unusual formatting is an important subjective turnoff to potential users. Presumably the goal of the library is to enable users to get the functionality they've been missing. The hurdle of a new formatting style to get used to goes against this goal. Fortunately, this is something easily remedied. > - What is your evaluation of the documentation? > Looked reasonable. > - What is your evaluation of the potential usefulness of the > library? > Given the prior existence of Boost.Signals I wouldn't find this library to be useful. There is an important aspect to this review that I want to call out. A signal is a "vocabulary type" in that it is pervasive through systems and frequently used in public interfaces. One of the most important qualities of a vocabulary type is that there be only one of them. Imagine the confusion if we had one thread-safe shared pointer class and another one optimized for single threaded usage, or if we had an suite of different variant types with different tradeoffs. No, there should only be one signal type and Boost.Signal made the correct choice of using a so-called intrusive design. - Did you try to use the library? > Nope. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I spent a few hours on the review. A small amount of time was reading the documentation and a much longer amount of time was spent pondering the implications of incorporating the library into Boost. - Are you knowledgeable about the problem domain? > Yes. I've used Qt signals, Boost.Signals1, and Boost.Signals2 extensively in various projects. > - Do you think the library should be accepted as a Boost library? > No. -- David Sankel

4 6

[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