- Boost - lists.preview.boost.org

Boost Log 1.65.1 Linking Issue
by Karmethia Thompson 16 Sep '20

16 Sep '20

Good morning, I am trying to create a logger that uses Boost Log. I was successful getting my code to compile with 1.63.0, so I know that I am not too far off of the mark. cmake/make throws a linking issues whenever I attempt to create a sink: typedef sinks::synchronous_sink< sinks::text_ostream_backend > text_sink; boost::shared_ptr< text_sink > sink = boost::make_shared< text_sink >(); or create file sink logging::add_file_log ( keywords::file_name = log_specs.log_file, keywords::rotation_size = 10 * 1024 * 1024, keywords::time_based_rotation = sinks::file::rotation_at_time_point(0, 0, 0), keywords::filter = min_severity || severity >= file_severity, keywords::format = ( expr::stream << expr::format_date_time<boost::posix_time::ptime>("TimeStamp", "%Y-%m-%d_%H:%M:%S.%f") << ": [" << severity << "]" << expr::smessage ), keywords::auto_flush = true //flush to file.. ); My code will compile 95% and then produce the following: CMakeFiles/main.dir/src/Logger.cpp.o: In function `boost::enable_if_c<(boost::log::v2_mt_posix::aux::is_character_type<wchar_t>::value&&boost::log::v2_mt_posix::aux::is_character_type<char>::value)&&((sizeof (wchar_t))!=(sizeof (char))), bool>::type boost::log::v2_mt_posix::aux::code_convert<wchar_t, char, std::char_traits<char>, std::allocator<char> >(wchar_t const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned long, std::locale const&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix3aux12code_convertIwcSt11char_traitsIcESaIcEEENS_11enable_if_cIXaaaasrNS2_17is_character_typeIT_EE5valuesrNS8_IT0_EE5valuenestS9_stSB_EbE4typeEPKS9_mRNSt7__cxx1112basic_stringISB_T1_T2_EEmRKSt6locale[_ZN5boost3log11v2_mt_posix3aux12code_convertIwcSt11char_traitsIcESaIcEEENS_11enable_if_cIXaaaasrNS2_17is_character_typeIT_EE5valuesrNS8_IT0_EE5valuenestS9_stSB_EbE4typeEPKS9_mRNSt7__cxx1112basic_stringISB_T1_T2_EEmRKSt6locale]+0x37): undefined reference to `boost::log::v2_mt_posix::aux::code_convert_impl(wchar_t const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned long, std::locale const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::recursive_mutex, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char> >(boost::log::v2_mt_posix::record_view const&, boost::recursive_mutex&, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::recursive_mutex, boost::log::v2_mt_posix::sinks::text_file_backend>(boost::log::v2_mt_posix::record_view const&, boost::recursive_mutex&, boost::log::v2_mt_posix::sinks::text_file_backend&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS_15recursive_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::text_file_backend::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::log::v2_mt_posix::aux::fake_mutex, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char> >(boost::log::v2_mt_posix::record_view const&, boost::log::v2_mt_posix::aux::fake_mutex&, boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_26basic_text_ostream_backendIcEEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::basic_text_ostream_backend<char>::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/main.dir/src/Logger.cpp.o: In function `void boost::log::v2_mt_posix::sinks::basic_formatting_sink_frontend<char>::feed_record<boost::log::v2_mt_posix::aux::fake_mutex, boost::log::v2_mt_posix::sinks::text_file_backend>(boost::log::v2_mt_posix::record_view const&, boost::log::v2_mt_posix::aux::fake_mutex&, boost::log::v2_mt_posix::sinks::text_file_backend&)': Logger.cpp:(.text._ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_[_ZN5boost3log11v2_mt_posix5sinks30basic_formatting_sink_frontendIcE11feed_recordINS1_3aux10fake_mutexENS2_17text_file_backendEEEvRKNS1_11record_viewERT_RT0_]+0x141): undefined reference to `boost::log::v2_mt_posix::sinks::text_file_backend::consume(boost::log::v2_mt_posix::record_view const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' collect2: error: ld returned 1 exit status make[2]: *** [main] Error 1 make[1]: *** [CMakeFiles/main.dir/all] Error 2 Can someone please help? I have tried everything from trying to dynamically and statically link. I've added both "log" and "log_setup" to the find_packages in cmake and have also explicitly specified the locations of those libraries as well. Please let me know if there is anything else to try. Thanks -- Karmethia Thompson Applied Mathematics, PhD

4 6

Re: [boost] Boost Log 1.65.1 Linking Issue
by Peter Dimov 15 Sep '20

15 Sep '20

Although, now that I think of it, the shown CMakeLists.txt file didn't use imported targets, so perhaps the order of libraries is literal and putting log_setup before log may indeed solve things. -----Original Message----- From: Peter Dimov Sent: Tuesday, September 15, 2020 20:28 To: boost(a)lists.boost.org Subject: Re: [boost] Boost Log 1.65.1 Linking Issue Andrey Semashev wrote: > I'm not sure, but I think the above would generate incorrect order of > libraries in the linker command line. You need to ensure that boost_log > comes after boost_log_setup, and their dependencies come after still. CMake automatically orders libraries so that the dependencies come after. Unfortunately, FindBoost has a bug and declares log as depending on log_setup, rather than vice versa. https://github.com/Kitware/CMake/blob/bdcde7762c71cd27fcba6dc1a3efe12fa7a09… No matter how you order the libraries in target_link_libraries, the order between these two will never be correct. Not sure if this is the problem here though.

1 0

[Math] Adding prime sieves - design discussion
by John Maddock 15 Sep '20

15 Sep '20

Just a heads up, that Boost.Math has an open PR for adding prime sieves, and there is an ongoing design discussion on interface etc. If anyone has any strong feelings on the matter, usage requirements etc, then comments would be most welcome. See https://github.com/boostorg/math/pull/400. Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

[JSON][review] Some early feedback
by Andrzej Krzemienski 15 Sep '20

15 Sep '20

Hi Everyone, The formal review of Boost.JSON has not started yet, but I thought I could offer some feedback from my playing with the library earlier in the process. Documentation --------------- Very well written. It makes it easy to grasp quickly the spirit and the potential of the library, and the reference section makes it easy to navigate through the features and their interfaces. Some minor issues: 1. Section "Using Numbers" is missing content. 2. Description of storage_ptr's destructor and move constructor is missing noexcept. 3. Docs in a couple of places call `storage_ptr` a "smart pointer container". Is it intentional? "Container" has a very specific meaning in C++. Design. ----------- It is generally sound, and well explained in the rationale. Here are a couple of minor remarks. 1. The usage of `nullptr` for null values. `nullptr` has been introduced to mean "a pointer with null value" and is only used in the standard library for smart pointers, with an ignoble exception of `std::function<>`. Using it for `json::value` is not an obvious choice for me. On the other hand, we do not have a universal type representing a missing value. A library could provide its own `json::null`, although I am not sure if this is an ideal solution either. 2. Why is json::value Semiregular rather than Regular? Equality comparison has a natural interpretation and application for checking if the produced JSON looks exactly as expected, or for checking if some two subtrees are the same. Is it because of efficiency issues with json::object comparison? 3. The library is using a custom string type. We get a rationale for this, and I accept it. But there are still some concerns about it that I would like to mention. 3.1. It is not the first library reviewed his year to have a custom type with std::string-compatible interface. It looks like the idea of having a "vocabulary" string type is unrealistic. If this should be the case, maybe we need a concept specifying what a string-compatible type should provide. It is obvious that json::string does not literally provide the same interface as std::string. Nor does anyone expect 100% compatibility. 3.2. Docs say that json::string is like std::string *except for* a number of things. For instance it does not provide the controversial assignment from `char`. Given that you are "fixing" the shortcomings of std::string, maybe it is an opportunity to fix other things in it also. For instance, std::string has been criticised for having too big an interface. That it mixes an iterator-based interface with an indexed-based one. Myb functions like `find_first_not_of()` are not necessary, given that users can use all sorts of iterator-based algorithms? 3.3. The rationale for json::string says that inisializer_list constructor is unnecessary, because string literal can always be used instead. This does not take into account that initializer_list does not necessarily operate on constant values. There is no concise substitute for: ``` std::string arrange(char a, char b, char c) { return {c, a, b, c}; } ``` I would not miss this construction much, I guess, but I would expect this to be mentioned in the rationale. 4. One thing one often expects of a JSON library is to be able to pretty-print a JSON document. The docs give an example how to do it, but the library does not provide this feature out of the box. Is pretty-printing not compatible with the design goals of the library? Implementation -------------- I didn't look much at it yet, but here is something I found. 1. `json::string_view` is convertible from `std::stirng`, but it is not convertible from `std::string_view`. I think there is no harm in enabling this conversion, and it seems useful. 2. The following piece of code ``` json::value v = 50.0; std::cout << json::serialize(v); ``` oututs: 5E1 which is technically compliant with JSON specification, but quite surprising. Is there a reason for this? Can serialization be controlled to output 50.0 or 50? 3. It is confusing for me to see member function serializer::read. I would think that the action that a serializer does is *write* rather than read. Am I missing something? 4. I really appreciate the ability to use the library in header-only mode with <boost/json/src.hpp>. This makes library testing much simpler. Regards, &rzej;

7 10

[json][review] A review from an embedded perspective
by Brooks Prumo 15 Sep '20

15 Sep '20

Hi everyone, this is my first time mailing the Boost developer list, and also submitting a review. Thank you in advance for understanding any issues it may have! I'm writing to review Boost JSON. I've been using it very lightly for the last week or so. My usage has been exclusively on embedded MCUs (ARM Cortex M4, compiling with ARM GCC 9 with C++17), which I'm guessing hasn't been the common case so far. Here's a list of things that matter a lot to me: - Compile from source. Boost JSON passes. - No exceptions. C++ exceptions are turned off, so all libraries I use must support not throwing. Boost JSON passes. - No iostreams/locale. If a library uses iostreams, my binary jumps ~220 KB which is a deal breaker. Boost JSON passes. - Binary size matters a lot, since onboard Flash is very limited. I am using a "big" MCU, and that means my whole binary must be under ~512 KB. Right now Boost JSON is not great. In doing a simple serialization and parse, the library itself adds ~58 KB to my .text section. This is OK for now, but surprisingly big. I know the team is aware of this and has some ideas to reduce the binary size. I will likely need those fixes to actually port my app to Boost JSON. - Control over the sizes of any "large" stack buffers. Boost JSON passes. - No external dependencies that do not meet the above requirements. Boost JSON passes. With this, Boost JSON is an ACCEPT from me. THe biggest reason for me is that the API is nice to work with. I started off with Nlohmann, but the binary size was too big due to iostreams. I'm currently using RapidJSON, and it's definitely not easy to use. In my app, JSON is not in the hot path. I want a library that is easy to use and meets my requirements above. I greatly appreciate being able to use a modern C++ library. And answers to the other questions: - What is your evaluation of the design? So far so good. I do not have complicated JSON uses though. - What is your evaluation of the implementation? I've only looked at the implementation when it comes to binary size. - What is your evaluation of the documentation? Documentation is nice. I personally would enjoy more examples, as that is how I commonly learn new libraries. - What is your evaluation of the potential usefulness of the library? HUGE! I haven't come across another modern C++ JSON library that'll work in the embedded space I live in. It's really exciting! - Did you try to use the library? With which compiler(s)? Did you have any problems? Yep! I used ARM GCC 9.2.1 with C++17. No issues with compilation. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I'd say my evaluation is "initial". I've used it in a way that mimics my real usage, but haven't used many aspects of the whole library. - Are you knowledgeable about the problem domain? Minimally. Just basic JSON knowledge. Thank you! Brooks

3 2

[preprocessor] Appveyor weirdness
by Edward Diener 14 Sep '20

14 Sep '20

In my appveyor.yml file for preprocessor one of the b2 command lines for a test run uses an explicit alias for the target. When run in appveyor.yml I get the messages: notice: could not find main target preprocessor_limits notice: assuming it is a name of file to create . and don't know how to make <e>preprocessor_limits Yet when I run the same test locally using the preprocessor_limits target, everything works fine. Is Appveyor somehow different when running Boost Build tests than when I run it locally ?

1 0

No doc for qvm in 1.74 distro
by Edward Diener 12 Sep '20

12 Sep '20

There is no doc for the qvm library in the 1.74 distro.

2 1

[JSON][review] Should there be an equality operator/function?
by Hadriel Kaplan 12 Sep '20

12 Sep '20

Howdy, I’ve been testing Boost.JSON in preparation for writing a review, and one thing that I found surprising might be better discussed in a separate thread, so here goes… There’s currently no comparison function or operator to compare one json::value with another. While I appreciate that a deep comparison isn’t cheap - it’s O(N) for the average case but O(N^2) in the worst case I believe - I still think it’ something a JSON-based container value type should have out-of-the-box. It’s something other popular JSON libraries offer; usually with equality operators, although a named function would be ok too if that was required instead. I hit the lack of it almost immediately, since test code/assertions frequently check equality. I’m not sure how frequently it’s used for run-time code in general, however. -hadriel

1 1

Looking for a review manager for Real
by Damian Vicino 10 Sep '20

10 Sep '20

Hi, GSOC finished and we are almost-ready for proposing to review a new library, Real. We are looking for a volunteer to be a review manager for it. Best regards, Damian

9 15

Do I need to use boost::mutex in deadline_timer?
by Jupiter 10 Sep '20

10 Sep '20

Hi, I used boost::asio::io_service for a single thread implementation but with multiple boost::asio::deadline_timer objects, because it is a single thread, I don't think I need to use boost::mutex to lock and unlock tasks running by deadline_timer, am I wrong about it? Thank you. Kind regards, jupiter

3 4

Re: [boost] boost.real
by Kostas Savvidis 09 Sep '20

09 Sep '20

Hi Damian, Laouen, I have been able to compile the test programs with your library after making some simple changes. The patch is below the message. However the example program from your documentation still does not compile, unless I comment out some lines - you can see the listing below. I ran a tricky calculation which is from the Aberth book, your program is able to give the answer and moreover the true value is indeed between the upper and lower bounds that your program gives. This is good! The conclusion is that your library can do useful work, but it is very limited in capability. No special functions, trig is there but not working well, and no simple way to interface with linear algebra. I may want to use it at some point, but I would need at least the ability to cast int and double to your boost::real::real type, because as it is now, the only way to import numbers into your software seems to be through std::string. Finally what seem to be some bugs: 1) unsigned int real::maximum_precision = 10; // error: specializing member 'boost::real::real<int>::maximum_precision' requires 'template<>' syntax 2) auto it = e.cbegin(); // error: 'using real = class boost::real::real<int>' {aka 'class boost::real::real<int>'} has no member named 'cbegin' 3) real::sin(f) // enters infinite loop 4) real c = (std::string)"0.999999"; prints: c: [0.99999899999999999999999999999999999999999999999999999999999999999999999999999999999999999933600778729, 0.99999899999999999999999999999999999999999999999999999999999999999999999999999999999999999982691714296] as far as i can see the interval is incorrect ! Best Regards, Kostas ============================================================================================= diff -r -u real.orig/integer_number.hpp real/integer_number.hpp --- real.orig/integer_number.hpp 2020-09-07 16:22:04.000000000 +0300 +++ real/integer_number.hpp 2020-09-08 14:11:22.000000000 +0300 @@ -103,7 +103,8 @@ } // this function always expects (*this) to bigger than other, so if borrow is not zero at the end // there should be error - if(borrow != 0); + if(borrow != 0) + ; //throw subtraction_number_required_lower_exception(); diff -r -u real.orig/real_rational.hpp real/real_rational.hpp --- real.orig/real_rational.hpp 2020-09-07 16:22:04.000000000 +0300 +++ real/real_rational.hpp 2020-09-08 11:59:51.000000000 +0300 @@ -262,7 +262,7 @@ // constructor to generate get number from string constexpr explicit real_rational(std::string_view num){ // searching for "/" in string - size_t pos; + size_t pos=0; bool found = false; std::string_view num1, num2; pos = num.size(); ============================================================================================= #include <iostream> #include <string> #include <real/real.hpp> using real = boost::real::real<int>; //unsigned int real::maximum_precision = 10; //unsigned int real_algorithm::maximum_precision = 10; int main() { real c = (std::string)"0.999999"; real d = (std::string)"0.999999"; real e = c + d; std::cout << "c: " << c << std::endl; std::cout << "d: " << d << std::endl; std::cout << "e=c+d: " << e << std::endl; // ANSWER IS WRONG ??!!! // for(auto it = e.cbegin(); it != e.cend(); ++it) { // std::cout << "e iteration " << it.approximation_interval << std::endl; // } real g = (std::string)"0.999998"; std::cout << "g: " << g << std::endl; if (g < d) { std::cout << "g < d --> true" << std::endl; } else { std::cout << "g < d --> false" << std::endl; } real h = d - g; std::cout << "h=d-g: " << h << std::endl; std::cout << "h++ is: " << h+real("1.0") << std::endl; { // Example from Aberth 1992, Precise Computation Using Range Arithmetic real a("77617.0"); real b("33096.0"); std::cout << "\n\n" << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; real f = real("333.75")*b*b*b*b*b*b + a*a*(real("11.0")*a*a*b*b-b*b*b*b*b*b - real("121.0")*b*b*b*b-real("2.0")) + real("5.5")*b*b*b*b*b*b*b*b + a/(real("2.0")*b); // should be -0.827396 std::cout << "f: " << f << std::endl; //std::cout << "sin(f): " << real::sin(f) << std::endl; // doesn't come out of the loop } return 0; }

2 1

[LEAF] Review Results
by Michael Caisse 09 Sep '20

09 Sep '20

I want to thank Emil for his patience for the publishing of the review results as life got in my way. Thank you Emil for submitting LEAF to be reviewed for inclusion into Boost. As an already-Boost-author, you knew what you were getting into and continued into the process. I also want to thank you for once again pushing our thoughts on error handling. -------- Result -------- This is the part everybody scrolls to the bottom to read, so let’s just put it at the top. Boost.LEAF is ACCEPTED into Boost. After the following modifications are made to the library, the repository can be transitioned to Boost for inclusion into the next release (with the release cycle timing constraints): Specify the TLS requirement sooner in the documentation. Optional usage of Boost.Config to perform all of the Boost Configy things. (further discussion on this below) Macro naming and general Boostification clean-up. -------- Reviews -------- There was a good amount of discussion about the library on both the dev and user mail lists. I want to personally thank those who got involved in the review. You make the process work! Result summary: Accept: 7 Reject: 1 No-decision: 3 The no-decision reviews provided valuable input and discussion threads. While it would be my preference to have the review authors provide a final verdict, I was grateful for the time and energy they spent with the library and formulating thoughts into emails for discussion. Some comments from reviews: “I find function preload() really great and novel. … This really makes the error reporting code brief, clean and bug-free.” “I like LEAF very much and there's a lot offered here…” “I like it.” “...it allows bridging multiple error handling strategies and usage patterns in an efficient way.” About the docs: “They look good and manage to explain hard concepts in a very approachable fashion.” “The documentation is great -- in terms of styles it's probably the best I've seen for a C++ library.” “Clear, friendly and complete.” -------------- Some Thoughts -------------- While there was overwhelming consensus that LEAF should be included into Boost, the process is not democratic. I have spent considerable time understanding the concerns raised in each of the reviews and in particular the singular rejection. Emil took time responding to each of the reviews. The exchanges were fruitful and both “conditional accept” and “reject” reviewers changed their verdicts to accept along the way. Most of the concerns were amicably resolved. I am comfortable with the design choices and implementation made by the author for the remaining items. One reviewer brought up the re-implementation of Boost.Config type facilities. This of course is a complex issue for a library with zero dependencies. The ability to simply drop the Boost.LEAF directory into a project and run is a definite plus for a specific user segment. Being able to modify a single Boost.Config repository to support WackyCompiler14 targeting LEG Core and get a bunch of libraries for the ride is also a plus. Emil and I have discussed these concerns and the best choice seems to be defaulting to zero dependencies and the option to pull in Boost.Config to provide configuration type facilities if needed. Accepting a library into Boost is as much about the library as it is bringing the author into a group. While Emil is already part of the author crowd, it was clear to me through his careful, informative, and patient responses that the addition of Boost.LEAF brings professional maturity that strengthens the community. A user with more than a year of experience with the library voted acceptance based on the “qualities of the library itself and the responsiveness and openness for feedback of its author.” Throughout the review period, Emil integrated feedback to both the documentation and code in another branch. It was wonderful to see the community provide input and the author respond so quickly to produce a better final result. Thank you Emil for your vision of better error handling and striving to bring us along! -- Michael Caisse Ciere Consulting ciere.com

3 2

[log] logfile not created where expected
by Barend Gehrels 08 Sep '20

08 Sep '20

hi, I encountered a bug, most probably, in Boost.Log It is reproduceable in the tutorial_logging.cpp : https://www.boost.org/doc/libs/1_74_0/libs/log/example/doc/tutorial_logging… The short code should create a file named "sample.log". But it does not, instead it creates a file called "00000.log", with the expected lines logged in that file. If I compile and run exactly the same tutorial in Boost 1.70, the file sample.log is indeed created with the same content. The problem is already there in Boost 1.73 What is the problem? Is there a workaround for it? Thanks, regards, Barend

3 2

Re: [boost] Review Manager needed for Boost.Lambda2
by Mateusz Loskot 08 Sep '20

08 Sep '20

Bjorn, thank you for reminding me about it. I've been offline for several weeks and I might have missed it happened already (lots of communication moved to Slack too). Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting) On Tue, 8 Sep 2020, 20:39 Bjorn Reese, <breese(a)stofanet.dk> wrote: > On 2020-09-08 19:39, Mateusz Loskot via Boost wrote: > > On Tue, 8 Sep 2020 at 17:02, Peter Dimov via Boost > > <boost(a)lists.boost.org> wrote: > >> > >> I turned this into a mini-library, https://github.com/pdimov/lambda2, > and > >> I'd like to submit that to Boost. > >> > >> I'm looking for a review manager. > > > > FYI, added to the schedule. > > Strictly speaking, he needs an endorsement first. >

2 1

buffer_size behavior in boost::iostreams::filtering_istream
by Justin McManus 07 Sep '20

07 Sep '20

I have some code that works as intended, but it requires setting a buffer_size parameter to zero on a std::ifstream pushed onto a filtering chain, and I'd like to understand why, to ensure I'm not introducing a bug or a hack. I have essentially the following code: -------------------------------------------------------------------------------------------------------- std::ifstream m_jf("json_filename", std::ios_base::in | std::ios_base::binary); std::locale utf8_locale("en_US.UTF-8"); m_jf.imbue(utf8_locale); boost::iostreams::filtering_istream m_inbuf; m_inbuf.push(boost::iostreams::bzip2_decompressor()); m_inbuf.push(m_jf); std::string m_line; while (std::getline(m_inbuf, m_line)) { // Process the current line from the JSON file } -------------------------------------------------------------------------------------------------------- What I find is that the std::getline call will fail before the code has reached the EOF. It will always fail at the same line in a given JSON file, but it will fail on different lines in different JSON files. It's perfectly reproducible. However, if I change lines 4 and 5 to m_inbuf.push(boost::iostreams::bzip2_decompressor(), *0*); m_inbuf.push(m_jf, *0*); then the problem goes away. My question is, Why does setting the buffer_size parameter to zero solve the issue? What does this do, exactly? I saw the suggestion to set the buffer size this way from an old post in 2009, and it appears to work, but I'd like a deeper understanding of what's happening under the hood. If the buffer size is set to zero, what does the underlying implementation do, and how might this influence whether std::getline fails before the EOF? Thanks very much, Justin -- Justin McManus, Ph.D. Principal Scientist Lead Computational Biologist and Statistical Geneticist Kallyope, Inc. 430 East 29th Street, Suite 1050 New York, NY 10016

3 4

type detection macros + multiprecision + io
by Gero Peterhoff 07 Sep '20

07 Sep '20

Hello Developer, I noticed that some type detection macros and boost::float128_type or numeric_limits do not work reliably: - BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok - BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE or BOOST_NO_TYPE should be defined; see later - with clang there is no boost::float128_type and an error when including boost/multiprecision/float128.hpp (quadmath.h) - with clang and icc the numeric_limits<float128_t> are not available (gcc ok) see https://godbolt.org/z/95PfTG In general it would make sense: - convert the detection macros to a uniform naming scheme: always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not mixed/both - in multiprecision and math: 1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d: decimal) 2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked) 3) based on this, renaming boost::float/int128_type to boost::float/int128_t so that it is always clear and there is no confusion. You can do that for all types, e.g. some DSP/microcontrollers do not support u/int8/64_t etc. I did that quickly for gcc (has_type.hpp) - of course that has to be in the corresponding boost/config/compiler/* and platform/* headers are implemented. Building on this, feature test macros can then be made available (features.hpp). Can you please implement the io-operators and string-conversions for u/int128 (in e.g. boost/math/cstdint/cstdint_iostream.hpp)? thx and regards Gero

5 4

[sync] Documentation ?
by Edward Diener 06 Sep '20

06 Sep '20

There is a 'sync' library in the Boost build tree as a submodule, but I see no documentation for it in Boost 1.74 itself. Is this currently a Boost library, or what is it ?

2 1

Cryptography for Boost. Boost.Crypto3.
by Mikhail Komarov 04 Sep '20

04 Sep '20

Hello! Some time ago I promised to show something about cryptography library architecture and implementation for Boost (https://lists.boost.org/Archives/boost//2020/02/248205.php <https://lists.boost.org/Archives/boost//2020/02/248205.php>), so here I am. I’m actually glad my two innocent letters triggered such a conversation. That is what I wanted to see! Please, read this letter very carefully, because some explaining needs to be done before you go to the code. By the way. The code: https://github.com/NilFoundation/boost-crypto3 <https://github.com/NilFoundation/boost-crypto3>. Warning. This letter contains mentioning of my non-commercial organizations I develop Boost.Crypto3 with. Don’t consider that as advertising. It is not supposed to be an advertisement. So, what cryptography for Boost (and probably STL some time after) should look like? 1. It should definitely be simple to use and implemented with some generic programming spirit. That is exactly what was done. Remember std::transform? Typical usage technique for all of the modules of a suite looks as follows. Classic iterator pair with output iterator: using namespace boost::crypto3; std::string input = “Weird German 2 byte thing: Ã.“, out; encode<codec::base64>(input.begin(), input.end(), std::inserter(out, out.end())); Classic iterator pair with output value return: using namespace boost::crypto3; std::string input = “00112233445566778899aabbccddeeff”; std::string key = “000102030405060708090a0b0c0d0e0f”; std::string out = encrypt<block::rijndael<128, 128>>(input.begin(), input.end(), key.begin(), key.end()); C++20 Ranges (or Boost.Range) usage: using namespace boost::crypto3; std::vector<std::uint8_t> input = {0x27, 0x0f, 0xb1, 0x89, 0x82, 0x80, 0x0d, 0xa6, 0x40}; std::string out = encode<codec::base32>(input); // or encode<codec::base32>(input, out); What about generic encoding/encryption/signing/hashing/%name_your_action% interface for classes? You can definitely do that in case you define implicit conversion of your class to integral type. I’m thinking of introducing Inspectable concept which will require for the developer to have a function in his class which would return every class member which developer thinks needs to be encrypted/hashes/encoded/etc, converted to the particular algorithm’s format. (e.g. satisfying Integral concept for ciphers/codes/hashes). 2. It should contain only time-proven schemes implemented with well-known and proven techniques. Yes. Boost.Crypto3 (https://github.com/NilFoundation/boost-crypto3 <https://github.com/NilFoundation/boost-crypto3>) is derived from =nil; Crypto3 C++ Cryptography Suite (https://github.com/NilFoundation/crypto3 <https://github.com/NilFoundation/crypto3>), which my non-commercial foundation designed and developed for it’s projects. A little bit of information on how exactly it was derived from the original suite you can get from the readme.md in both or repositories. As far as you can see in the original repository, the suite contains some very novel schemes (e.g. Verifiable Delay Functions: https://github.com/nilfoundaton/crypto3-vdf.git <https://github.com/nilfoundaton/crypto3-vdf.git>) and it is going to contain more (threshold cryptography, zero-knowlege cryptography, cryptographic accumulators etc.). But Boost-ified version has to be a solid one. No novel schemes. Only proven ones with proven implementation techniques. Which ones? This is what Boost community is up to decide. So, the question for the community. What schemes should be included? For now we only present small set of block ciphers, hashes and codecs listed in here https://crypto3.nil.foundation/projects/crypto3/db/d97/group__codec.html <https://crypto3.nil.foundation/projects/crypto3/db/d97/group__codec.html>, https://crypto3.nil.foundation/projects/crypto3/db/d97/group__hashes.html <https://crypto3.nil.foundation/projects/crypto3/db/d97/group__hashes.html>, https://crypto3.nil.foundation/projects/crypto3/d2/dba/group__block.html <https://crypto3.nil.foundation/projects/crypto3/d2/dba/group__block.html>. (Or you can find the list in the include directories of particular repositories: https://github.com/nilfoundation/crypto3-block.git <https://github.com/nilfoundation/crypto3-block.git>, https://github.com/nilfoundation/crypto3-codec <https://github.com/nilfoundation/crypto3-codec.git>.git <https://github.com/nilfoundation/crypto3-codec.git>, https://github.com/nilfoundation/crypto3-hash <https://github.com/nilfoundation/crypto3-hash.git>.git <https://github.com/nilfoundation/crypto3-hash.git>). Peter (Dimov), I’m aware of your abandoned hash library implementation (https://github.com/pdimov/hash2 <https://github.com/pdimov/hash2>) based on Vinnie’s paper. I would really like to see it’s contents and concepts (probably) adapted to hash module of Boost.Crypto3. Would be a great synergy. 3. It should have a concept-based architecture. Concept-based architecture supposes every reused type trait to be formalized, and standardized. This is what exactly has been done. In particular, concepts for contents of Boost.Crypto3 are listed in sufficient documentation chapters: https://crypto3.nil.foundation/projects/crypto3/df/d5d/block_ciphers_concep… <https://crypto3.nil.foundation/projects/crypto3/df/d5d/block_ciphers_concep…>, https://crypto3.nil.foundation/projects/crypto3/d7/da8/codec_concepts.html <https://crypto3.nil.foundation/projects/crypto3/d7/da8/codec_concepts.html>, https://crypto3.nil.foundation/projects/crypto3/d1/d1f/hashes_concepts.html <https://crypto3.nil.foundation/projects/crypto3/d1/d1f/hashes_concepts.html>. Long story short. We standardize stateless policies containing all the params as constexpr ones used for functions (interface-functions like encrypt/decrypt) and actual algorithms. We also figured out that most of cryptographic algorithms are about accumulation and only then processing. So we used Accumulator concept from Boost.Accumulator to accumulate (surprise surprise) data in a format, which is required by particular algorithm to be passed into. You can get the idea of how I’ve merged the Accumulator concept in from architecture and implementation notes (for Block Ciphers) in here: https://crypto3.nil.foundation/projects/crypto3/db/dee/block_ciphers_impl.h… <https://crypto3.nil.foundation/projects/crypto3/db/dee/block_ciphers_impl.h…>. Pretty drafty as well, but better than nothing. Yes, Hash concept should be made consent with currently existing Hash concept. This is in progress. Vinnie (Falco), I remember, you’ve mentioned some more generic concepts like OneWayFunction (in here: https://lists.boost.org/Archives/boost//2020/02/248228.php <https://lists.boost.org/Archives/boost//2020/02/248228.php>). I agree, we should do that, but we simply had no time to put this fine idea to our architecture. We would really appreciate any help with that. Cristopher (Kormanyos), I’m aware of your CRC catalog library (https://github.com/ckormanyos/crc-catalog <https://github.com/ckormanyos/crc-catalog>) I like it because of how in particular it is implemented. I would really like to merge it into our CRC implementation in Crypto3.Hash. By the way. I wonder if we could sometime remove separate Boost.CRC library and use CRC from more generic Boost.Crypto3? Hypothetically. Just asking. Yeah, we have checksums being implemented in Crypto3.Hash (and in Boost.Crypto3 as well), but they were simply not verified yet, so they are hanging in a PR (https://github.com/NilFoundation/crypto3-hash/pull/68 <https://github.com/NilFoundation/crypto3-hash/pull/68>). 4. Other modules? Roadmap? Yes, there will be other modules being proposed in some time. Public Key cryptography in Boost? Yes. Based on enhanced for cryptographic purposes Boost.Multiprecision (https://github.com/NilFoundation/crypto3-multiprecision <https://github.com/NilFoundation/crypto3-multiprecision>). SSL based on Boost.Crypto3? Yes. Why not. We are already in progress. Major updates are going to be performed with merging in the Boost-ified version of bunch of cross-dependent modules of the original suite. For example, public key cryptography would require enhancing Boost.Multiprecision (which is already in progress) and introducing finite fields library (https://github.com/NilFoundation/crypto3-algebra <https://github.com/NilFoundation/crypto3-algebra>). By the way. The original =nil; Crypto3 suite is highly modular. Every cryptography field is emplaced in separate submodule. There are more than 30 of them now in total (counting closed ones)(yeah, it is huge). Would you like to keep this modularity (like introducing Boost.BlockCiphers, Boost.Hashes and Boost.Codec instead of Boost.Crypto3)? Or do we need to keep everything in header-only Boost.Crypto3? I would vote for the second option. John (Maddock), do you understand now why I was attempting to get accepted those strange PRs in Boost.Multiprecision for the last year? Degski (Sorry, I’m not aware of your name), I remember you’ve mentioned some kind of compression library of yours. I would like to see the compression in the suite. Do you think I could fork it and fit into our architecture? 5. Why do we think we can implement properly design and cryptography? Ask me :). 6. Conclusion. In some time, this would definitely result in C++ Standardization Committee proposal. It is a long way, but I hope to bring it there. What we would like to hear from Boost community is some guidance about what in particular from this field would be useful for Boost, proposals and suggestions about architecture and concepts. Let us standardize some cryptography together (starting with this). Sincerely yours, Mikhail Komarov nemo(a)nil.foundation

6 8

Re: [boost] ASIO SSL Memory Leaks
by abrarov＠mail.ru 01 Sep '20

01 Sep '20

Hi John, Welcome to this mailing list! Doesn't Asio call SSL_shutdown here: https://github.com/chriskohlhoff/asio/blob/master/asio/include/asio/ssl/deta il/impl/engine.ipp#L325 ? Regarding memory leaks - cold you please provide a minimal example reproducing memory leak including the way you detect memory leak? Could chriskohlhoff/asio GitHub issue #368 (https://github.com/chriskohlhoff/asio/issues/368) be your case? Regards, Marat Abrarov.

1 0

ASIO SSL Memory Leaks
by John A 01 Sep '20

01 Sep '20

Hello y'all, This is my first post to this listserv though I've been on others for ~30 years. I have a Boost question, ob duh. Using the SSL_shutdown() outlined here: https://www.openssl.org/docs/man1.0.2/man3/SSL_shutdown.html from within Boost, there isn't an object to associate with this shutdown call. Secondly, we have memory leaks (~10k bytes) using the SSL library via Boost socket calls using the ASIO SSL streams. What am I missing? What advisement can be offered? Ideally, we want to call SSL_shutdown() from within Boost, though I am missing something. Best regards, John Aronetics.com We Speak ITR +1-216/307-5760

3 3

ASIO: Same code for tcp, unix domain sockets (websockets via beast)
by Matthias Loy 26 Aug '20

26 Aug '20

Hello, we are implementing a service that is to be available via tcp, unix domain sockets (and websocket). Websocket might be out of scope since it is not part of asio. All those protocols are streaming protocols and should behave in the same way: read some bytes, write some bytes. I would like to have the code implemented only once to handle several protocols. Not having one for local::stream_protocol::socket and another one for ip::tcp::socket. Until now I was not able to find something like base classes that allow me to do that. I only found code that works for tcp or unix domain sockets (local). The protocol is not to be decided at compile time but on runtime. Hence I'm having problems using templates here. The documentation of async_read states that the stream has to support the AsyncReadStream concept. Is there a way to get something supporting this concept from local::stream_protocol::socket and ip::tcp::socket? Best regards, Matthias

4 3

JSON library scheduled for review
by Mateusz Loskot 25 Aug '20

25 Aug '20

Hi, A brief announcement from the review wizards: Formal review of the JSON library has been scheduled to take place between October 9 and October 18, 2020. Details and links available here https://www.boost.org/community/review_schedule.html We'd like to thank Pranam Lashkari (Boost.GIL, [Boost.]Astronomy, Boost GSoC) for volunteering to act as the review manager. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Shallow Hal Needs A Gal!
by Vinnie Falco 25 Aug '20

25 Aug '20

And Boost.JSON needs a review manager! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

3 4

Modules
by Damian Vicino 24 Aug '20

24 Aug '20

Hi, Are there any guidelines on the use of modules inside boost? Are we planning any steps for adoption of them?

9 18

You Won't Believe This!
by Vinnie Falco 23 Aug '20

23 Aug '20

But Boost.JSON needs a Review Manager! Don't be shy now! Repository: https://github.com/cppalliance/json Documentation: http://vinniefalco.github.io/doc/json/index.html -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

7 10