- Boost-users - lists.preview.boost.org

[format] warning...warning...warning
by Arnaud RICHARD 24 Mar '17

24 Mar '17

Hello, I'm a complete Boost newbie. I've been told very often that boost is the way to go for serious C++ coding, and I was not surprised to see such emphasis on the home page: "We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization" So when I used the format library on my existing (non-trivial) project and first compiled... I was very very surprised to get my neat compilation console flooded with hundreds of warnings ! I acknowledge I activate many many warnings: CXXFLAGS+=-Wall -Wextra -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization \ -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs \ -Wnoexcept -Woverloaded-virtual -Wredundant-decls -Wshadow \ -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 \ -Wswitch-default -Wundef -Wunused The warnings were as trivial as (for example): ../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22: warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined [-Wundef] #if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700) ../ext/boost/boost/format/parsing.hpp:435:67: warning: conversion to 'std::vector<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> >, std::allocator<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> > > >::size_type {aka unsigned int}' from 'int' may change the sign of the result [-Wsign-conversion] string_type & piece = (cur_item==0) ? prefix_ : items_[cur_item-1].appendix_; I understand they are only warning and the code is functionally correct and standard-wise correct. Personally when I face such false warnings in my code, I change the code to remove the warning so that if a warning does make sense, I can notice it. I thought a reference implementation would be written with such policy. There's no way I'm gonna read each of the hundreds of messages to understand if it is a mistake in my source code or a "shortcut" in boost library. So this is my first user experience. Not impressed at all. Boost will not be my reference.

6 8

boost asio client socket connection to servers behind a public IP address
by jupiter 24 Mar '17

24 Mar '17

Hi, I need to run boost asio client socket connections to remote servers via a remote proxy server, the remote proxy server has a public IP address, but none of remote servers have public IP addresses. Appreciate any clues or samples. Thank you.

1 0

[TypeErasure] efficiency problem
by Mikhail Strelnikov 24 Mar '17

24 Mar '17

Hello! In following code TypeErasure creates two copies of s, while Boost.Any creates no copies at all. any x{ s{} }; any y{ std::move(x) }; any z; z = std::move(y); There is move constructor for type_erasure::any, but it does allocate memory and calls copy constructor for s. Why? And why there is no move assignment operator in type_erasure::any? Thanks. Full source: https://wandbox.org/permlink/iHs5a0bjzXsBtpwC

3 3

Re: [Boost-users] [boost] [release] Boost 1.64.0 Beta 1
by Rene Rivera 23 Mar '17

23 Mar '17

On Thu, Mar 23, 2017 at 11:04 AM, Olaf van der Spek <ml(a)vdspek.org> wrote: > VS2015 / W10: > > boost_1_64_0>bootstrap.bat > > Building Boost.Build engine > HRESULT was unexpected at this time. > Could you try building b2.exe directly: === cd tools\build\src\engine built.bat === And posting the output? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

Re: [Boost-users] [boost] [release] Boost 1.64.0 Beta 1
by Mateusz Loskot 23 Mar '17

23 Mar '17

On 23 March 2017 at 17:04, Olaf van der Spek via Boost <boost(a)lists.boost.org> wrote: > VS2015 / W10: > > boost_1_64_0>bootstrap.bat > > Building Boost.Build engine > HRESULT was unexpected at this time. bootstrap.bat bootstrap.bat vc14 bootstrap.bat vc141 All succeed for me on W10 w/ VS2015 and VS2017 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Iterator] zip iterator with std::tuple or std::pair
by Matthias Wohlgemuth 23 Mar '17

23 Mar '17

Hello, as far as I understand the zip_iterator is compatible also with STL tuple and pair. However, when I try to create a zip_iterator with std::pair it fails to compile. Here, a simple test code: #include <vector> #include <utility> #include <boost/iterator/zip_iterator.hpp> int main () { std::vector<int> v(4); boost::make_zip_iterator(std::make_pair(v.begin(), v.begin())); return 0; } compiled with gcc 4.9.2 and boost 1.62 returns me (tested also with 1.63): In file included from /software/boost-1.62/include/boost/iterator/zip_iterator.hpp:26:0, from test.cpp:3: /software/boost-1.62/include/boost/mpl/at.hpp: In instantiation of ‘struct boost::mpl::at_c<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > >, 0l>’: /software/boost-1.62/include/boost/iterator/zip_iterator.hpp:180:17: required from ‘struct boost::iterators::detail::zip_iterator_base<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > > >’ /software/boost-1.62/include/boost/iterator/zip_iterator.hpp:237:9: required from ‘class boost::iterators::zip_iterator<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > > >’ test.cpp:8:64: required from here /software/boost-1.62/include/boost/mpl/at.hpp:42:8: error: no class template named ‘apply’ in ‘struct boost::mpl::at_impl<boost::mpl::non_sequence_tag>’ struct at_c ^ In file included from test.cpp:3:0: /software/boost-1.62/include/boost/iterator/zip_iterator.hpp: In instantiation of ‘struct boost::iterators::detail::zip_iterator_base<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > > >’: /software/boost-1.62/include/boost/iterator/zip_iterator.hpp:237:9: required from ‘class boost::iterators::zip_iterator<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > > >’ test.cpp:8:64: required from here /software/boost-1.62/include/boost/iterator/zip_iterator.hpp:180:17: error: no type named ‘type’ in ‘struct boost::mpl::at_c<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > >, 0l>’ >::type difference_type; ^ /software/boost-1.62/include/boost/iterator/zip_iterator.hpp:198:11: error: no type named ‘type’ in ‘struct boost::mpl::at_c<std::pair<__gnu_cxx::__normal_iterator<int*, std::vector<int> >, __gnu_cxx::__normal_iterator<int*, std::vector<int> > >, 0l>’ > type; I get a similar results for std::tuple compiled c++11 enabled gcc. I did not find any solution, except a 3 year old patch, which is said to be applied to the boost::iterator library. Any suggestions? Best regards, Matthias

3 3

Is Boost API 32Bit only?
by Andrej Georgi 19 Mar '17

19 Mar '17

I try to build Boost on MSYS2-64Bit which includes 64-Bit headers of windows. Boost is calling a 32-Bit variant of windows API even when Boost is configured to build 64-Bit. There is a 64Bit pre build variant of Boost on sourceforge. That seems to run only in visual studio? Does it use a 32 Bit API as well? Is there any reason for this design? I personaly prefer any variant of GCC over visual studio due to time consuming experiences with visual studio. Kind regards Andrej

4 4

[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 15 Mar '17

15 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