June 2020 - Boost-users - lists.boost.org

Boost.Numeric.Interval: Please specify rounding control mechanism
by Bastien Commelongue 01 Dec '20

01 Dec '20

Hello, I am building an app for IOS (ARM) and I had this issue while compiling: *Boost.Numeric.Interval: Please specify rounding control mechanism.* C99 version should be used in this case but __USE_ISOC99 is not defined. Modifying the condition with this code (using __cplusplus) fixed the issue: *boost/numeric/interval/hw_rounding.hpp(36)* *#if defined(BOOST_NUMERIC_INTERVAL_NO_HARDWARE) && (defined(__USE_ISOC99) || defined(__MSL__) || (defined __cplusplus && __cplusplus >= 201103L))# include <boost/numeric/interval/detail/c99_rounding_control.hpp>#endif* Let me know if I missed something or if you plan to integrate this modification in a next version. Cheers, Bastien Commelongue

2 1

[serialization] Backward compatibility problem with 1:73
by Kai Benndorf 25 Jun '20

25 Jun '20

Hi all, we are using boost serialization for writing and reading data and just switched from boost 1:67 to boost 1:73. We now cannot read back the data written with boost 1:67 or prior. We get an archive_exception::input_stream_error exception. Examining the files shows the difference. The old files are starting with 22 serialization::archive 16 The new files are missing this data. Removing it from the files enabled the reading with boost 1:73. But strangely, if trying a small example program (the gps example from the documentation) also boost 1:73 produces this data: 22 serialization::archive 18 Any idea what has changed in between these versions and could cause this problem? Thanks in advance for any hint. Our application uses an own derived archive class. Maybe I have to changed something there? Best regards Kai Benndorf ---------------------------------------------------------------- Kai Benndorf E-Mail: kai.benndorf(a)web.de Zur Maibolte 44 MOBILE: 0151 55627946 32657 Lemgo WORK: 05251 150623 Germany PHONE: 05261 14465 ----------------------------------------------------------------

1 1

[boost][mp11][GIL]
by Debabrata Mandal 18 Jun '20

18 Jun '20

Hi, I am trying to implement a histogram class that will be able to store tuples of any data type. Most likely, I chose std::tuple for the job. So, in brief I used std::tuple as the key type in an unordered_map. I used boost::hash_value to supply the hasher in place of std::hash in the third template argument to unordered_map. Now, fast forwarding to my problem, I want to be able to provide a sub-histogram based on a few axes of the histogram. The code below, quite similar to what I want, refuses to work with msvc-14.0 (coming to it shortly). ----Sample Code---- #include <boost/mp11.hpp> template<typename... T> struct histogram { using type_list = boost::mp11::mp_list<T...>; template<std::size_t... D> void d() { // Error in below line histogram<boost::mp11::mp_at_c<type_list, D>...> f; } }; int main() { histogram<int, int, int, int> f; f.d<1,2>(); return 0; } ---END--- So, msvc-14.0 gives the error (after tracing to the last function call in stack) at the position specified above. The error message which is coming from the AppVeyor logs (since I do not have msvc-14.0) ... C:\projects\boost-root\boost/mp11/utility.hpp(53): error C2971: 'boost::mp11::detail::mp_if_c_impl': template parameter 'C': 'C': a variable with non-static storage duration cannot be used as a non-type argument C:\projects\boost-root\boost/mp11/utility.hpp(38): note: see declaration of 'boost::mp11::detail::mp_if_c_impl' C:\projects\boost-root\boost/gil/histogram.hpp(247): note: see declaration of 'C' ... I am not sure if the issue is with mp11 or the msvc-14.0, but I did find some references which claim a similar issue with the latter case. This links <https://developercommunity.visualstudio.com/content/problem/719235/erroneou…> to a very similar case of the error C2971 which seems to be fixed in the future releases. Also, the code above compiles fine with GCC and Clang. Any comments or suggestions on this are most welcome. Thanks, Deb GSOC 2020 student in Boost.GIL

2 1

Re: [Boost-users] [boost] [review] [text] Text formal review
by Vinnie Falco 17 Jun '20

17 Jun '20

On Fri, Jun 12, 2020 at 10:36 AM Rainer Deyke via Boost <boost(a)lists.boost.org> wrote: > String layer: overall, a solution looking for a problem. I created boost::json::string to use instead of std::string for a couple of reasons: 1. It uses a type-erased, reference counted memory resource instead of Allocator template parameter 2. The class is laid out a certain way to greatly minimize its size 3. The class layout is optimized to keep the size of the enclosing variant (the JSON DOM value type) small 4. The API is the same for all C++ versions (unlike std::string) 5. It is not a class template I would like to know what are the exact _technical_ benefits of Boost.Text's String layer, beyond "because I don't like std::string" Thanks

3 4

Re: [Boost-users] Boost in xeus-cling jupyter kernel
by Giorgino R 16 Jun '20

16 Jun '20

> Ηi there, > > I ve been using boost (geometry) with xeus-cling kernel without any > issues, so far. I install boost from conda forge: > > conda install boost -c conda-forge > > I tried to include odeint.hpp without any issues on my cling environment: > > see also > https://stackoverflow.com/questions/61205040/how-do-i-use-boost-with-the-xe… > > BW > G > > > On Fri, 12 Jun 2020, 19:46 A. de Windt via Boost-users, < > boost-users(a)lists.boost.org> wrote: > >> Hi everyone, >> >> As my first post in this mailing list I would like to ask, has anyone >> tried using boost in a xeus-cling jupyter kernel? Or just cling? >> >> My plan is to use odeint in the jupyter notebook for some simulations. >> However I had issues when I tried to run one of the odeint examples. I >> originally posted my issue on stackoverlfow but didn;t get any feedback. So >> I'm going to mostly copy my original question in this email. >> >> >> https://stackoverflow.com/questions/61205040/how-do-i-use-boost-with-the-xe… >> >> I'm running Pop!_OS (ubuntu derivative) and apt installed boost >> (libboost-all-dev) from the default repositories. I know it has been >> installed properly since I can compile and run the simple boost odeint >> example with GCC. >> >> However when I tried to run the same example inside a jupyter notebook >> using the zeus-cling kernel I got an error while including the odeint >> header. I can recreate the error while executing this code: >> >> #pragma cling add_include_path("/usr/include")#include <boost/numeric/odeint.hpp> >> >> The error message I get is: >> >> In file included from input_line_8:1: >> In file included from /usr/include/boost/numeric/odeint.hpp:22: >> In file included from /usr/include/boost/numeric/odeint/config.hpp:44: >> In file included from /usr/include/boost/config.hpp:48: >> In file included from /usr/include/boost/config/stdlib/libstdcpp3.hpp:78: >> /usr/include/unistd.h:756:28: error: expected function body after function declarator >> extern __pid_t fork (void) __THROWNL; >> ^ >> /usr/include/unistd.h:869:11: fatal error: 'bits/getopt_posix.h' file not found >> # include <bits/getopt_posix.h> >> ^~~~~~~~~~~~~~~~~~~~~ >> Interpreter Error: >> >> From what I understand bits/getopt_posix.h is a GCC only header, thus I >> think the problem might be because the boost headers are configuring >> themselves as if they are compiling under GCC instead of cling/clang. >> >> My solution so far has been to submodule the boost super project into my >> repository and add all the include paths necessary to get odeint and it's >> dependencies to compile. This is fine since odeint is a header only library >> anyways. But I'm pretty sure there is a better solution to this problem. >> >> Thanks in advance and hope to hear from someone back soon. >> >> >> Cheers, >> Aaron M. de Windt >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> https://lists.boost.org/mailman/listinfo.cgi/boost-users >> >

1 0

Boost in xeus-cling jupyter kernel
by A. de Windt 13 Jun '20

13 Jun '20

Hi everyone, As my first post in this mailing list I would like to ask, has anyone tried using boost in a xeus-cling jupyter kernel? Or just cling? My plan is to use odeint in the jupyter notebook for some simulations. However I had issues when I tried to run one of the odeint examples. I originally posted my issue on stackoverlfow but didn;t get any feedback. So I'm going to mostly copy my original question in this email. https://stackoverflow.com/questions/61205040/how-do-i-use-boost-with-the-xe… I'm running Pop!_OS (ubuntu derivative) and apt installed boost (libboost-all-dev) from the default repositories. I know it has been installed properly since I can compile and run the simple boost odeint example with GCC. However when I tried to run the same example inside a jupyter notebook using the zeus-cling kernel I got an error while including the odeint header. I can recreate the error while executing this code: #pragma cling add_include_path("/usr/include")#include <boost/numeric/odeint.hpp> The error message I get is: In file included from input_line_8:1: In file included from /usr/include/boost/numeric/odeint.hpp:22: In file included from /usr/include/boost/numeric/odeint/config.hpp:44: In file included from /usr/include/boost/config.hpp:48: In file included from /usr/include/boost/config/stdlib/libstdcpp3.hpp:78: /usr/include/unistd.h:756:28: error: expected function body after function declarator extern __pid_t fork (void) __THROWNL; ^ /usr/include/unistd.h:869:11: fatal error: 'bits/getopt_posix.h' file not found # include <bits/getopt_posix.h> ^~~~~~~~~~~~~~~~~~~~~ Interpreter Error: >From what I understand bits/getopt_posix.h is a GCC only header, thus I think the problem might be because the boost headers are configuring themselves as if they are compiling under GCC instead of cling/clang. My solution so far has been to submodule the boost super project into my repository and add all the include paths necessary to get odeint and it's dependencies to compile. This is fine since odeint is a header only library anyways. But I'm pretty sure there is a better solution to this problem. Thanks in advance and hope to hear from someone back soon. Cheers, Aaron M. de Windt

2 1

Re: [Boost-users] [boost] [review] [text] Text formal review
by Emil Dotchevski 13 Jun '20

13 Jun '20

On Fri, Jun 12, 2020 at 10:36 AM Rainer Deyke via Boost < boost(a)lists.boost.org> wrote: > String layer: overall, a solution looking for a problem. I tend to agree with this but I had assumed there is a reason why it exists. Zach indicated that he doesn't care much about it, so it probably should be deleted, but I don't feel strongly about this because there are plenty of C++ APIs which define their own string type, and I don't see this as a problem. In C++, we have many of everything.

1 0

[review] [text] Text review begins June 11
by Glen Fernandes 12 Jun '20

12 Jun '20

The Boost formal review of Zach Laine's Unicode library, Text, commences on June 11th and concludes June 20th. We welcome the participation of Boost developers and users, and the C++ community. Quote: This library includes three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides Try the library today, and please consider submitting a review, or even contributing to the discussion next week. Glen

4 3

[asio] tcp non blocking sync read query (bug?)
by Keith Robinson 11 Jun '20

11 Jun '20

Hi, I'm sending data from one process to another using a tcp connection. Sender use scatter-gather to send the data using 3 buffers (total just over 2000 bytes). The reader uses 2 separate sync reads to read the data (using the asio free function read()) using a non blocking socket. Sometimes everything is fine, the 2 reads return the amount of data requested, but sometimes I see strange behaviour. I'm trying to work out whether I am doing something wrong, or whether I've stumbled across a bug. When it goes wrong for me, the second read always returns less data than I requested, along with the error code 'would_block'. I then loop, performing further reads (using the same buffer as before), eventually (one read, or multiple reads later) the read function returns the remainder of the data, but still with the error code 'would_block' set. However, when I check the contents of the buffer, it is not what I expected. I think, but haven't been able to confirm, that the start of the buffer is not the start of the data. 1. Is it expected that the read() free function, when the socket is non blocking, can return less data than requested, along with the error code 'would_block'? 2. If it is expected, does the buffer passed in subsequent reads have to be adjusted to read only the remaining about of data? 3. If the buffer does have to be changed to only read what is left, how does this work with scatter-gather reads using multiple buffers? As a little bit of extra info, I confirmed using tcpdump that the correct data is sent/received, although it arrives in 2 chunks (MTU size of 1500). This is on Linux using Boost 1.73.0. Cheers, Keith

3 3

[review] [text] Text formal review
by Glen Fernandes 11 Jun '20

11 Jun '20

Dear Boost community, The formal review of Zach Laine's Unicode library, Text, begins today (June 11th) and ends on June 20th. The library provides three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text The master branch of the repository will be frozen for the duration of the review. Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Any conditions for acceptance - Your name and knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Even if you are not submitting a formal review, your feedback on the library is welcome. Glen

1 0