- Boost-users - lists.boost.org

[Stacktrace] Second review begins today 17th Mar ends 26th Mar
by Niall Douglas 17 Mar '17

17 Mar '17

I am pleased to announce the second review of the proposed Boost.Stacktrace library running from today until Sunday 26th. Stacktrace is an optionally header-only library providing multiple implementation backends. 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 ================= This is a second review of this library with many changes implemented in response to feedback from the previous review. My previous review report can be found at http://lists.boost.org/boost-announce/2017/01/0486.php where I made the following conditions for acceptance: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. Antony hasn't entirely met my conditions, hence this second review. He has instead implemented this changelog: * Reimplemented boost::stacktrace::basic_stacktrace class to accept allocators and to have a small size * Added outputting of the path to the binary object into the stacktrace, when source location is not available * Allowed to use `libbacktrace` - a defacto standard for GCC/CLANG backtracing that does not fork and has a permissive license * Optimized stacktrace and frames ostreaming * Removed backends and made the default tracing to have only platform basic functionality. Added macros to enable additional functionality. * Fixed (theoretically) MinGW compilation * Added functions for async-safe dumping into memory or descriptor * Changed signal handling example to be async-signal-safe * Allowed users to choose how many frames to skip during stack capture * Removed `boost::stacktrace::stacktrace` functions and other internals from printed stack traces * Updated docs: * examples now use Boost.Exception * removed all the references to "backend" * reduced macro count * "Build, Macros and Backends" section was rewritten and became "Configuration and Build" * added note that library is C++03 * added examples on storing traces into shared memory * updated all the human readable dumps It is up to the Boost community as to whether this revised library is now acceptable without any conditions, or with conditions. Reviews should be submitted to the developer list (boost_at_[hidden]), 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? - 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Compiling Boost on MSYS2
by Andrej Georgi 16 Mar '17

16 Mar '17

Hello Boost Users, why does Boost use a 32-Bit API for multithreading on a 64 bit system? The Win32 API header on MSYS2 uses 64-Bit Windows API and the Boost implementation (win32_api.hpp) uses 32-Bit which makes my compiler (gcc 6.3.0) complain. Do I have to configure Boost to be 64-Bit? Regards Andrej

1 0

compilation failed with error due to boost thread library
by Jack Kumba 11 Mar '17

11 Mar '17

Hello, the compilation of my library failed with the following error: make[1]: *** Waiting for unfinished jobs.... /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libboost_coroutine.a(stack_traits.o): undefined reference to symbol '_ZN5boost13thread_detail18commit_once_regionERNS_9once_flagE' /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status What do you think can be the source of error? It used to compile well before... Cheers, Jack

2 1

SSL client boost::asio::ssl::stream handshake hang up in reconnection
by jupiter 09 Mar '17

09 Mar '17

Hi, When it was the first time to connect to server, the following code works fine. s.lowest_layer().connect(*endpoint_iterator++, error); s.handshake(boost::asio::ssl::stream_base::client, error); When the server connection lost then resumed, the client try to run above code again, the s.lowest_layer().connect(*endpoint_iterator++, error); returned no error of success, but the s.handshake(boost::asio::ssl::stream_base::client, error); hang up. Appreciate any helps? Thank you. - j

1 0

[type_erasure] member function return any
by Mikhail Strelnikov 06 Mar '17

06 Mar '17

Hello! I want to return type_erasure::any from a member function of a struct adapted by that same any. How can I do this? #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/callable.hpp> using my_any = boost::type_erasure::any< boost::mpl::vector< boost::type_erasure::copy_constructible<>, boost::type_erasure::assignable<>, boost::type_erasure::callable<? ? ?> > >; struct s { my_any operator()(my_any v) { return v; } }; int main() { my_any t = s{}; t = t(t); } Thanks.

2 1

[boost] Unbounded integers and shared memory
by Antony Polukhin 04 Mar '17

04 Mar '17

Hello, One of the ISO WG21 C++ Study Groups is investigating the usecases of shared memory usage with wide arithmetics (Boost.Interprocess, Boost.Multiprecision, in-house solutions?). Particularly interesting: * Are there users that store unbounded numbers in shared memory? * Will bounded integers satisfy need of those users? Informal glossary: * "unbounded numbers" - numbers (integral, relational, floating point and others) that can store and operate on any huge value by dynamically allocating memory as necessary to maintain a representation of operation results. * "bounded types" - Numbers (integral, relational, floating point and others) which bounds are specified in number of bytes/bits/words at compile time and that do not allocate memory. Please, response if you are one of such users. Great thanks in advance! -- Best regards, Antony Polukhin

1 0

[spirit-qi] [attr] Invalid static_cast error
by 含露月含露月 03 Mar '17

03 Mar '17

Hi, I try to generate a string using qi::attr, and the following is the code. #include <boost/spirit/include/qi.hpp> namespace qi = boost::spirit::qi; int main(){ // ok qi::rule<char const *, std::string()> world = qi::attr("world"); qi::rule<char const *, std::string()> rule = qi::eps > world; // error: invalid static_cast from type 'const char [6]' to type 'char' // qi::rule<char const *, std::string()> rule = qi::eps > qi::attr("world"); } Do I miss something or it is a bug? How can I fix it without using extra rules or semantic actions. Platform: win7 64bit Compiler: gcc 4.9.1 Boost 1.63 Since I typed on my phone, forgive me if there are errors. Best regards, Yuan Yao

1 0

error running boost book
by Clark Sims 02 Mar '17

02 Mar '17

I get the following error when I cd to BOOST_ROOT/doc and run ../bjam My ~/user-config.jam looks fine. I pasted it bellow the error. Does anyone know how to fix this? I have spent a great deal of time trying to fix this. It looks like the doxygen.jam in the boost_1_63_0/tools/build/src/tools directory does not like the syngax of the doxygen rule in ~/user-config.jam. ---------------------------------------------------------------------------------------------------------------------------------- Building the tti docs with automatic index generation disabled. Try building with --enable-index. /home/csims/boost_1_63_0/libs/dll/doc/Jamfile.v2:66: in modules.load *** argument error * rule doxygen ( target : sources + : requirements * : default-build * : usage-requirements * ) * called with: ( autodoc_shared_library_core : : <doxygen:param>HIDE_UNDOC_MEMBERS=YES <doxygen:param>HIDE_UNDOC_CLASSES=YES <doxygen:param>HIDE_SCOPE_NAMES=YES <doxygen:param>EXTRACT_ALL=NO <doxygen:param>EXTRACT_PRIVATE=NO <doxygen:param>BUILTIN_STL_SUPPORT=YES <doxygen:param>ENABLE_PREPROCESSING=YES <doxygen:param>MACRO_EXPANSION=YES <doxygen:param>ALIASES= \ "forcedlink{1}=\xmlonly<link linkend='boost.dll.\1'>boost::dll::\1</link>\endxmlonly" \ "forcedmacrolink{1}=\xmlonly<link linkend='\1'>\1</link>\endxmlonly" <doxygen:param>PREDEFINED= \ "BOOST_RV_REF(T)=T&&" \ "BOOST_RV_REF(shared_library)=shared_library&&" \ "BOOST_COPY_ASSIGN_REF(shared_library)=const shared_library&" \ "BOOST_MOVABLE_BUT_NOT_COPYABLE(shared_library)= \ shared_library(const shared_library&) = delete; \ shared_library& operator=(const shared_library&) = delete; " \ "BOOST_DLL_IMPORT_RESULT_TYPE=result_type" \ "BOOST_DLL_MANGLED_IMPORT_RESULT_TYPE=result_type" \ "BOOST_EXPLICIT_OPERATOR_BOOL()=explicit operator bool() const noexcept;" \ "BOOST_DLL_DOXYGEN" <xsl:param>boost.doxygen.reftitle=Shared Library Reference ) * missing argument sources /home/csims/boost_1_63_0/tools/build/src/tools/doxygen.jam:622:see definition of rule 'doxygen' being called /home/csims/boost_1_63_0/tools/build/src/build/project.jam:325: in load-jamfile /home/csims/boost_1_63_0/tools/build/src/build/project.jam:64: in load /home/csims/boost_1_63_0/tools/build/src/build/project.jam:145: in project.find Jamfile.v2:96: in modules.load /home/csims/boost_1_63_0/tools/build/src/build/project.jam:325: in load-jamfile /home/csims/boost_1_63_0/tools/build/src/build/project.jam:64: in load /home/csims/boost_1_63_0/tools/build/src/build/project.jam:145: in project.find /home/csims/boost_1_63_0/tools/build/src/build-system.jam:535: in load /home/csims/boost_1_63_0/tools/build/src/kernel/modules.jam:295: in import /home/csims/boost_1_63_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build /home/csims/boost_1_63_0/boost-build.jam:17: in module scope ---------------------------------------------------------------------------------------------------------------------

2 1

[serialize] using virtual inheritance causes compiler error
by Douwe Gelling 02 Mar '17

02 Mar '17

Hi all, When trying to serialize a class with a virtual base class, I'm getting compilation errors. It seems to be part of a bug in type_traits, but I'm wondering if anyone knows a workaround for making it work anyhow. ultimately, the error boils down to "error: virtual function 'A::foo' has more than one final overrider in 'boost_type_traits_internal_struct_X'", using the code listing below.. It's simplified as much as possible, but obviously I need virtual inheritance due to using diamond inheritance. #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include <boost/serialization/serialization.hpp> struct A { virtual ~A(){}; virtual void foo() = 0; template <class Archive> void serialize(Archive& ar, const unsigned int version) { } }; struct B : public virtual A { virtual void foo() { } template <class Archive> void serialize(Archive& ar, const unsigned int version) { ar& boost::serialization::base_object<A>(*this); } }; struct C : public B { template <class Archive> void serialize(Archive& ar, const unsigned int version) { ar& boost::serialization::base_object<B>(*this); } }; BOOST_CLASS_EXPORT(C); int main() { C c; return 0; }

4 7

How compile with clang ?
by Andy 02 Mar '17

02 Mar '17

I have installed Clang at "c:\Program Files\LLVM" try: b2 clean b2 toolset=clang cxxflags="-std=c++1y -stdlib=libc++" linkflags="-stdlib=libc++" --prefix=c:\boost -j 4 stage release b2 install toolset=clang cxxflags="-std=c++1y -stdlib=libc++" linkflags="-stdlib=libc++" --prefix=c:\boost but is error: fatal error: 'corecrt.h' file not found #include <corecrt.h>

2 1