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

JSON and no-alloc
by Marc Oscar Singer 14 Aug '23

14 Aug '23

Greetings, I'm targeting the boost JSON library for an embedded target. There appears to be one place where there could be either a beneficial new feature, or the feature exists and I'm not seeing it. The section about Avoiding Dynamic Allocation is close to what we'd like to see, except that we don't want to depend on a stack buffer for value data. All of the text of the JSON message is present in the string view. It would be desirable to reference the values from there. Let me be a little more explicit. We receive a message in JSON format. The whole of this message must be received before we can pass it to the JSON parser. It's /possible/ to let the JSON parser manage the message as it arrives and manage both the parse and storage of the content. Doing so would require shifting some responsibilities within the firmware that are difficult to change. We parse out the fields we care about and then want to hold onto these values for some time without retaining the memory necessary for the parse itself. Since all of the values and keys are present in the original source buffer passed to parse() as a string_view, we could simply save the string_views for the values and discard the JSON parser. Except, this parser copies the value to another buffer s.t. discarding the parser invalidates the value string_views. Alternatively, if the values themselves were returned as string_views into the source buffer, these string_views would (could) survive destruction of the parser. If we are missing the method by which this can be implemented with the current parser, we'd be delighted to hear it. Cheers -- /Marc Oscar Singer/ *Woollysoft* +1.206.328.1718

3 4

Abwesenheitsnachricht: JSON and no-alloc
by Sören Textor 14 Aug '23

14 Aug '23

Derzeit bin ich nicht im Hause Ihre E-Mail wird nicht weitergeleitet. In dringenden Fällen bitte support(a)ditec-gmbh.de oder Telefonhotline +49-6221-31698-110 oder die Zentrale +49-6221-31698-0 kontaktieren. Mit freundlichen Grüßen Dr. Sören Textor ----------------------------------------------- DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielfältigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere für den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights.

1 0

Full-Text Search is LIVE!
by Vinnie Falco 10 Jul '23

10 Jul '23

Greetings. I am proud to announce that Mohammad’s excellent work on implementing a full-text search which looks into all the Boost libraries and their documentation is now complete, and has been published to the live website. You can access the search by pressing the Search button in the top right of the page: https://boost.org Please note that this is only the first iteration of this search tool and as such it will probably not give the perfect results that everyone expects every time. But now that we have something in place we can feedback, brainstorm on how to make it better, and iterate on it so that it evolves into something that consistently enhances the Boost user experience. To report problems or suggestions related to the search including the user interface, and the indexed contents, please open an issue in the Boost website repository: https://github.com/boostorg/website/issues There is also a “Report Issue” button in the search UI. Thanks!

1 0

[Boost.TypeErasure] - Issue compiling under Windows with Embarcadero C++ Builder 11.3
by Andy Bell 07 Jul '23

07 Jul '23

Hi I'm using the type erasure library but have an issue (which I can workaround) when compiling in Windows 10 using Embarcadero C++ Builder 11.3. My problem is that C++ Builder brings in the Windows SDK Windows.h include file in every Windows VCL UI project it creates *before* any of my code has compiled and it's causing conflicts in boost header member11.hpp. This code is enough to cause the error: #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/any_cast.hpp> #include <boost/type_erasure/builtin.hpp> #include <boost/type_erasure/operators.hpp> #include <boost/type_erasure/member.hpp> #include <boost/type_erasure/free.hpp> #include <boost/mpl/vector.hpp> namespace mynamespace { BOOST_TYPE_ERASURE_MEMBER(ReadStatus) } The error is because Windows.h defines 'interface' but this code from member11.hpp also uses 'interface': template<class P, template<class ...> class interface, class Sig, class Concept, class Base, class ID> using choose_member_interface = typename ::boost::mpl::if_c< ::boost::is_reference<P>::value, typename ::boost::mpl::if_c< ::boost::type_erasure::detail::is_non_const_ref<P>::value, interface<Sig, Concept, Base, const ID>, Base >::type, interface<Sig, Concept, Base, ID> >::type; and the compiler complains of conflicts. Embarcadero support have told me that I can't prevent Windows.h being included in my project before my boost-using code is compiled and attempts I've made to circumvent the problem, such as adding these lines to codegear.hpp: #ifdef interface #undef interface #endif don't work because C++ Builder is still including Windows.h before my code is compiled. To get around the problem, I changed member11.hpp in my boost installation to template<class P, template<class ...> class interface_, class Sig, class Concept, class Base, class ID> using choose_member_interface = typename ::boost::mpl::if_c< ::boost::is_reference<P>::value, typename ::boost::mpl::if_c< ::boost::type_erasure::detail::is_non_const_ref<P>::value, interface_<Sig, Concept, Base, const ID>, Base >::type, interface_<Sig, Concept, Base, ID> >::type; which I don't think will have side effects as 'interface/interface_' here is self-contained, but it doesn't feel like a good long term solution. Embarcadero support said: "Boost brings windows.h in because boost pulls it, *IF* the application is compiled for multi-threading then boost needs to access the OS threading functions, this is when you compile *without* the VCL." and I have confirmed this by creating a simple, multi-threaded Windows console application in C++ Builder... My question is: Is there a better way to work around this issue? My tests indicate that the Type Erasure library is working properly with my change, but it feels more like a hack than a fix... Thanks, Andy Bell Control Systems & Software Engineer Tel: +44 (0)1903 891700 Fax: +44 (0)1903 893888 Web: www.thermcosystems.com<http://www.thermcosystems.com/> www.csd-epi.com<http://www.csd-epi.com/> [cid:image002.png@01D9ADAA.693C8600] [Logo, company name Description automatically generated] P Please consider the environment before printing this email. This email and any files transmitted with it are confidential and intended solely for the intended recipient. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Tetreon Technologies Limited. Warning: Although Tetreon Technologies Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. Tetreon Technologies Ltd is a limited company registered in England and Wales. Company Registration No. 4966845 Registered Offices: Highfield, Rock Road, Washington, West Sussex, RH20 3BH, England

2 1

[asio] monitoring io_context load
by Dmitry 07 Jul '23

07 Jul '23

Hello, I would like to have a metric that measures time spent for work (executing completion handlers) vs time spent waiting for work in thread pool executing io_context::run(). It will help to estimate service capacity (i.e. how many more requests per second it can handle). It is similar to the system's CPU usage metric but CPU usage metric does not include waiting for mutex locks or sync io performed from completion handlers. In our performance tests io_context becomes overloaded (the queue grows faster than it's processed) when CPU usage is about 85%. I would like to have a metric that shows 100% in this case. There is BOOST_ASIO_CUSTOM_HANDLER_TRACKING macro that allows to intercept handler invocations and to measure execution time. But in the case of many lightweight handlers measuring time can bring significant overhead. I'm considering adding similar macros before and after waiting for the condition variable and epoll to measure wait time and then calculate execution time. I'm writing to ask if there is a better alternative? If not, would you be interested in a patch that adds "Handler Tracking" macros around wait calls? Thank you, Dmitry

3 6

Please remove me from this list
by Vitaly Budovski 03 Jul '23

03 Jul '23

The web and email unsubscribe methods do not seem to work.

1 0

[python][shared_ptr_from_python.hpp] looks like copy/paste or merge error
by Ran Regev 29 Jun '23

29 Jun '23

Hi, The code in construct() seems to surfer from copy/paste or merge error. It seems as though the following lines are duplicated in the else clause: void *const storage = ((converter::rvalue_from_python_storage<SP<T> >*)data)->storage.bytes; // Deal with the "None" case. if (data->convertible == source) new (storage) SP<T>(); Please take a look at: https://www.boost.org/doc/libs/1_82_0/boost/python/converter/shared_ptr_fro… Ran.

1 0

[multiprecision] why 128 bit numbers isn't used in msvc?
by shar yashuv Giat 29 Jun '23

29 Jun '23

msvc added 128 bit numbers(in the header __msvc_int128.hpp). I know multiprecision uses __128 to improve performance so why doesn't it use msvc version? it's seems easy to change and will probably improve performance.

2 1

assign a large integer to a cpp_int
by Matthew Mawson 27 May '23

27 May '23

I want to assign a large number to a cpp_int variable like this: cpp_int large = 30414093201713378043612608166064768844377641568960512000000000000; and I get this: error: integer literal is too large to be represented in any integer type. Thanks!

2 1

Abwesenheitsnachricht: assign a large integer to a cpp_int
by Sören Textor 27 May '23

27 May '23

Derzeit bin ich nicht im Hause Ihre E-Mail wird nicht weitergeleitet. In dringenden Fällen bitte support(a)ditec-gmbh.de oder Telefonhotline +49-6221-31698-110 oder die Zentrale +49-6221-31698-0 kontaktieren. Mit freundlichen Grüßen Dr. Sören Textor ----------------------------------------------- DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielfältigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere für den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights.

1 0

[boost::locale::generator] Calling boost::locale::generator results in an exception in EnterCriticalSection
by M L 24 May '23

24 May '23

Hello, calling boost::locale::generator results in an exception in EnterCriticalSection. Does anybody have a hint to the cause of this problem? Every small clue is welcome. What could be a possible workaround? What is usually the reason for an exception in EnterCriticalSection? Code snippet: boost::locale::generator generator; generator.add_messages_path("..."); generator.add_messages_domain(".."); std::string lngCode = "en"; std::locale = generator(lngCode + ".WINDOWS-1252"); // this line crashes -> 0x0000005 EnterCriticalSection Boost Version: (boost_1_60_0) Visual Studio 2013 Some more hints: - it seems that there is a problem reading the translation file, which works fine in other applications. - there are no threads in the code - the problem is project dependent. Same code works in a different project. - the problem only appears if a specific header is included, but nothing in this header is ever executed before the crash. Removing the header/cpp removes the problem. - some C code is present in the code - the problem even appears when moving the snipped in main. Thanks for help.

2 1

Boost ASIO: Problems building a conditional variable using io_context / strand
by Suraaj K S 23 May '23

23 May '23

Hi all, In boost-asio, I realized that there was no easy way to have something that resembles a condition variable. However, I realized that I could get something very similar using stackful coroutines ( https://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/overview/core/spa…) while using an io_context as a 'queue' for completion tokens. Below is my approach: *#include "asio_types.hpp"#include <atomic>#include <iostream>class async_pending_queue {public: async_pending_queue() : pending_handlers_(0), strand_(pending_queue_), wg_(asio::make_work_guard(pending_queue_)) {} template <typename CompletionToken> auto async_submit( CompletionToken &&token, std::function<void(void)> atomic_action = [] {}) { auto init = [this, &atomic_action](auto completion_handler) { auto posted_lambda = [handler = std::move(completion_handler), this]() mutable { pending_handlers_--; asio_sys_err ec; handler(ec); }; post(strand_,std::move(posted_lambda)); pending_handlers_++; atomic_action(); }; return asio::async_initiate<CompletionToken, void(asio_sys_err)>(init, token); } int pending_count() { return pending_handlers_.load(); } // It may not run 1 and run 0 bool try_run_one() { auto cnt = pending_queue_.poll_one(); std::cout << "completion token result" << cnt << std::endl; bool ret = (cnt == 1); return ret; }private: std::atomic<unsigned int> pending_handlers_; asio_ioctx pending_queue_; asio_ioctx::strand strand_; decltype(asio::make_work_guard(pending_queue_)) wg_;};* Here, one simply uses calls `my_async_pending_queue.async_submit(yield)`, if calling from a stackful coroutine. The coroutine can be continued by calling `my_async_pending_queue.try_run_one()`. Using this, I wanted to build a 'memory checker'. It has two functions -> `request_space` and `free_space`. A coroutine calls `request_space`, which may block if there is no space left. Meanwhile, another thread / coroutine can call `free_space`, which will run blocked coroutines if possible. I built a toy memory checker wrapper as follows: *#ifndef MEM_CHECK_HPP#define MEM_CHECK_HPP#include <cstddef>#include <mutex>#include <queue>#include <boost/asio.hpp>#include <boost/asio/spawn.hpp>namespace asio = boost::asio;using asio_ioctx = asio::io_context;using asio_sys_err = boost::system::error_code;using asio::yield_context;#include "async_pending_queue.hpp"class MemoryChecker {public: using bytes_cnt = size_t; MemoryChecker(asio_ioctx &ioctx, bytes_cnt total_mem = 1024, bytes_cnt initial_fill = 0); // This requests some space, and possibly yields; void request_space(bytes_cnt cnt, yield_context yield); void free_space(bytes_cnt cnt);private: bytes_cnt get_available_mem(); const bytes_cnt total_mem_; bytes_cnt mem_used_; std::queue<bytes_cnt> request_queue_; async_pending_queue request_routines_; std::mutex lock_; asio_ioctx::strand fifo_strand_; asio_ioctx &completion_ioctx_;};inline MemoryChecker::MemoryChecker(asio_ioctx &ioctx, bytes_cnt total_mem, bytes_cnt initial_fill) : total_mem_(total_mem), mem_used_(initial_fill), request_queue_{}, lock_{}, request_routines_{}, completion_ioctx_(ioctx), fifo_strand_(ioctx) {}inline MemoryChecker::bytes_cnt MemoryChecker::get_available_mem() { assert(total_mem_ >= mem_used_); return total_mem_ - mem_used_;}inline void MemoryChecker::request_space(bytes_cnt cnt, yield_context yield) { // if (cnt > total_mem_) throw logic_error lock_.lock(); assert(cnt <= total_mem_); assert(cnt > 0); if (request_queue_.empty()) { assert(request_routines_.pending_count() == 0); if (get_available_mem() >= cnt) { // We bypass the pending queue mem_used_ += cnt; lock_.unlock(); return; } } assert(request_queue_.size() == request_routines_.pending_count()); std::cout << "Pushing " << cnt << std::endl; request_queue_.push(cnt); auto wg = asio::make_work_guard(completion_ioctx_); request_routines_.async_submit(yield, [this] { lock_.unlock(); }); auto oldest_req{request_queue_.front()}; assert(cnt == oldest_req); request_queue_.pop(); mem_used_ += cnt; assert(request_queue_.size() == request_routines_.pending_count()); asio::post(fifo_strand_, yield);}inline void MemoryChecker::free_space(bytes_cnt cnt) { { std::lock_guard<std::mutex> lg{lock_}; mem_used_ -= cnt; // Here, we own the lock, and free as many coroutines as we can while (true) { if (request_queue_.size() == 0) { std::cout << "No pending requests. Bailing" << std::endl; break; } assert(request_queue_.size() == request_routines_.pending_count()); auto oldest_req{request_queue_.front()}; auto available_mem{get_available_mem()}; if (available_mem < oldest_req) { std::cout << "Oldest request is larger than available_mem. Bailing" << std::endl; break; } assert(request_routines_.try_run_one() == true); } }}#endif /* MEM_CHECK_HPP */* Here is a test program that can run it: *#include "mem_check.hpp"#include <thread>#include <unistd.h>constexpr size_t mc_size{4};asio_ioctx ioctx;size_t total{0};MemoryChecker mc{ioctx, mc_size};void requestor_coroutine(size_t rq,yield_context yield) { asio::steady_timer t(ioctx); while (true) { total += rq; mc.request_space(rq, yield); std::cout << "Got requested space "; asio_sys_err ec; }}int main() { asio::spawn(ioctx, [](yield_context yield) { requestor_coroutine(1,yield); }); asio::spawn(ioctx, [](yield_context yield) { requestor_coroutine(2,yield); }); asio::spawn(ioctx, [](yield_context yield) { requestor_coroutine(3,yield); }); asio::spawn(ioctx, [](yield_context yield) { requestor_coroutine(4,yield); }); std::thread t([] { ioctx.run(); }); while (true) { getchar(); std::cout << total << std::endl; if (total > 0) { std::cout << "freeing" << std::endl; mc.free_space(1); total -= 1; } } t.join();}* Finally, the problem we face is as follows. When we run the program, the assertion `total_mem >= mem_used_` fails. On some further investigation, I realized that our completion token was being called even when we do not call `try_run_one`, which was very weird. Finally, somewhat more surprisingly, If I replace *post(stand_,std::move(posted_lambda));* by *post(pending_queue_,std::move(posted_lambda));*, things seem to work. However, the asio documentation says that only strands guarantee a FIFO execution order. I am not sure if using a simple `io_context` will work as a FIFO queue (even though it seems to in these examples). Any inputs would be helpful - I am happy to hear the problem in this implementation, as well as other implementations (for example, using a std::queue as a proper queue instead of this io_context hack). This question has also been posted here: https://stackoverflow.com/questions/76310252/c-boost-asio-building-a-condit… . Thanks, Suraaj

3 2

Re: [Boost-users] New Website !
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 8:08 AM Damien via Boost-users <boost-users(a)lists.boost.org> wrote: > This looks really good. Congratulations to the team. Thank you very much for the kind words! Regards

1 0

Re: [Boost-users] New Website !
by Damien 11 May '23

11 May '23

This looks really good. Congratulations to the team. Damien

1 0

New Website !
by Vinnie Falco 11 May '23

11 May '23

Hey, it’s Vinnie here again! I have some very exciting news to share with you. The renovated website for Boost that we’ve been working on for far too long is now going into its Public Beta phase! Feel free to poke around and kick the tires but keep in mind this is a piece of software and it is still under development. Some parts are missing, incomplete,or buggy. Without further ado: https://boost.revsys.dev This public beta will extend for at least 10 weeks as we finish the last remaining features, and put a few more rounds of polish on the artwork, visual styling, and user interface. After that if you like what you see then we will reset the database, move the repositories and the site to their new homes, and then deploy it for real! If you have suggestions or wish to report problems please feel welcome to open an issue here: https://github.com/cppalliance/temp-site/issues This is a Django site written and maintained in Python by a great group of folks from https://www.revsys.com/. The project is coordinated by Frank Wiles (https://www.revsys.com/about/bio/frankwiles) who shares the same deep commitment to open source that we Boost people do. We chose Django because it is well understood and supported, and because Python composes well with ease of maintenance. This technology stack allows us to execute on our future plans with confidence. Some cool things about this website include: * Log in with GitHub or Google * Light and Dark themes with selector * Asciidoc markdown for dynamic content * Antora content sources for site documentation * Data-driven dynamic pages for libraries and releases * Integrated control panel for producing Boost releases * Full-text search across the documentation and library headers * Professionally designed logo to evoke identity and instant recognition The layout of the site is carefully thought out to make sure that information can be found quickly. Fundamental topics each get a dedicated word in the top level navigation, visible on every page including the site and library documentation. Most of the information which is not library-specific is warehoused in “site docs” which is a collection of individual Antora content sources each authored in Asciidoc. Anyone can update the information on the website simply by contributing to the site-docs via pull request: https://github.com/cppalliance/site-docs Antora and Asciidoc are potent technologies that offer Boost plenty of room to grow to make our site documentation and library documentation more effective for users. While the initial release of the website after the beta will only have the basic functionality, we have many future plans. Some of these you have heard about already and some are new: * A web-based forum which interacts seamlessly with the mailing list * Polls and surveys for measuring the sentiment of Boost users and stakeholders * News section for aggregating off-site links, blog posts, and release progress messages * Integrated Review process. Outcomes go in the database and become dynamic content. * User Profiles record and show activity such as review participation or library submission We’re all very excited and proud of the work that went into this thing and hope that it really fulfills the positive impact that we intended. Thanks! Vinnie

1 0

b2 error in nvidia enviroment
by Cho-Kuen Ng 26 Apr '23

26 Apr '23

I tried to build under nvidia environment and got the following b2 error: ../boost_1_73_0/tools/build/share/boost-build/src/build/toolset.jam:44: in toolset.using ERROR: rule "nvc.init" unknown in module "toolset". I put the following line in the site-config file using nvc : : CC ; What compiler toolset should I use under nvidia? Thanks.

1 0

Re: [Boost-users] errors in multiprecision
by John Maddock 21 Apr '23

21 Apr '23

On 20/04/2023 18:28, Gero Peterhoff via Boost-users wrote: > Am 20.04.23 um 18:38 schrieb John Maddock via Boost-users: >> On 20/04/2023 16:58, Gero Peterhoff via Boost-users wrote: >>> Hi John, >>> some functions do not work with multiprecision-integer-types, e.g. >>> >>> using T = boost::multiprecision::int256_t; >>> using ::std::isinf; >>> >>> const auto x = T{5}; >>> const auto y = isinf(x); // ct error >>> std::cout << y << std::endl; >>> >>> gives a CT error. >>> >> Correct. Those functions are pretty meaningless in the context of >> integer types, and no one has ever asked for them. >> >> John. > > > Ok, herewith I ask for it then :-) Finally this is relevant in the > template context or a functions with std- AND multiprecision-types > should/must work. I'll add it to the list, but be aware that this is not always supported for regular integer types: https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:6,positionColumn:2,positionLineNumber:6,selectionStartColumn:2,selectionStartLineNumber:6,startColumn:2,startLineNumber:6),source:'%23include+%3Ccmath%3E%0A%0Aint+main(int+argc)%0A%7B%0A++++return+std::isinf(argc)%3B%0A%7D%0A'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:33.333333333333336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:vcpp_v19_33_x64,deviceViewOpen:'1',filters:(b:'0',binary:'0',binaryObject:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:15,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'-O2',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x64+msvc+v19.33+(Editor+%231)',t:'0')),k:33.333333333333336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x64+msvc+v19.latest',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x64+msvc+v19.33+(Compiler+%231)',t:'0')),k:33.33333333333333,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4 John.

1 0

Re: [Boost-users] errors in multiprecision
by Gero Peterhoff 20 Apr '23

20 Apr '23

Am 20.04.23 um 18:38 schrieb John Maddock via Boost-users: > On 20/04/2023 16:58, Gero Peterhoff via Boost-users wrote: >> Hi John, >> some functions do not work with multiprecision-integer-types, e.g. >> >> using T = boost::multiprecision::int256_t; >> using ::std::isinf; >> >> const auto x = T{5}; >> const auto y = isinf(x); // ct error >> std::cout << y << std::endl; >> >> gives a CT error. >> > Correct. Those functions are pretty meaningless in the context of integer types, and no one has ever asked for them. > > John. Ok, herewith I ask for it then :-) Finally this is relevant in the template context or a functions with std- AND multiprecision-types should/must work. thx Gero

1 0

Re: [Boost-users] errors in multiprecision
by John Maddock 20 Apr '23

20 Apr '23

On 20/04/2023 16:58, Gero Peterhoff via Boost-users wrote: > Hi John, > some functions do not work with multiprecision-integer-types, e.g. > > using T = boost::multiprecision::int256_t; > using ::std::isinf; > > const auto x = T{5}; > const auto y = isinf(x); // ct error > std::cout << y << std::endl; > > gives a CT error. > Correct. Those functions are pretty meaningless in the context of integer types, and no one has ever asked for them. John.

1 0

errors in multiprecision
by Gero Peterhoff 20 Apr '23

20 Apr '23

Hi John, some functions do not work with multiprecision-integer-types, e.g. using T = boost::multiprecision::int256_t; using ::std::isinf; const auto x = T{5}; const auto y = isinf(x); // ct error std::cout << y << std::endl; gives a CT error. cu Gero

1 0

Re: [Boost-users] Much slower compilation time with boost-1.81 than boost-1.80 + much bigger .text section
by Niall Douglas 18 Apr '23

18 Apr '23

On 17/04/2023 14:33, Dominique Pellé via Boost-users wrote: > Hi > > 1) Compiling the attached "brands.cpp" file which uses > boost::container::flat_set is very slow with clang when using > boost-1.81.0. It was much faster with boost-1.80.0 somehow. Thanks for reporting this. Peter Dimov looked into this and found that the cause is recently added use of __forceinline. A suitable workaround until the next Boost release is -DBOOST_CONTAINER_DISABLE_FORCEINLINE I can't speak for Ion, but I'd assume it'll be fixed next Boost release. Once again thanks for reporting this, it wasn't noticed by the usual release testing. Niall

1 0

Much slower compilation time with boost-1.81 than boost-1.80 + much bigger .text section
by Dominique Pellé 18 Apr '23

18 Apr '23

Hi 1) Compiling the attached "brands.cpp" file which uses boost::container::flat_set is very slow with clang when using boost-1.81.0. It was much faster with boost-1.80.0 somehow. 2) Furthermore, the size of the .text section is much bigger when using boost-1.81.0 than with boost-1.80.0 when using clang. The source file is a simplification of an actual file in my project. Note that the code is in anonymous namespace (removing the anonymous namespace makes the compilation time much faster, presumably because there are more optimizations in the anonymous namespace). Benchmarks with clang-16 + boost-1.81.0 (on Linux Ubuntu-22.04): ``` $ time clang++-16 -isystem boost-1.81 -O2 -DNDEBUG \ -std=c++14 -o brands.o -c brands.cpp real 1m46.638s user 1m46.090s sys 0m0.520s $ size brands.o text data bss dec hex filename 2403932 20032 48 2424012 24fccc brands.o ``` Compare with the older boost-1.80.0: ``` $ time clang++-16 -isystem boost-1.80 -O2 -DNDEBUG \ -std=c++14 -o brands.o -c brands.cpp real 0m2.163s user 0m2.122s sys 0m0.041s $ size brands.o text data bss dec hex filename 101280 20032 48 121360 1da10 brands.o ``` In other words: - file is 81 times slower to compile with boost-1.81 than with boost-1.80 - the .text section is 23 times bigger with boost-1.81 than with boost-1.80 This may be a clang compiler issue, but since the performance regression is introduced from boost-1.80.0 to boost-1.81.0 I'm, reporting it here (I may report it to clang later depending on how the discussion here goes). It's even worse with older clang compilers. The table below shows the compilation time of brands.cpp file and size of the .text section for with various compilers using boost-1.80 and boost-1.81: ``` compiler boost compilation time size .text section -------- ----- ---------------- ------------------ clang-16 1.81 106.638 sec 2,403,932 bytes clang-16 1.80 2.164 sec 101,280 bytes clang-15 1.81 137.508 sec 2,861,332 bytes clang-15 1.80 2.527 sec 107,944 bytes clang-14 1.81 153.504 sec 3,033,487 bytes clang-14 1.80 2.294 sec 111,599 bytes clang-5.0 1.81 276.031 sec 2,720,187 bytes clang-5.0 1.80 2.328 sec 126,811 bytes gcc-12.1 1.81 2.821 sec 139,833 bytes gcc-12.1 1.80 2.505 sec 140,217 bytes gcc-7.5 1.81 1.943 sec 121,497 bytes gcc-7.5 1.80 1.707 sec 122,050 bytes ``` Regards Dominique PS: full versions of compiler used in above table (--version option): - Ubuntu clang version 16.0.2 (++20230414073413+b5aa566a7e53-1~exp1~20230414073428.73) - Ubuntu clang version 15.0.7 - Ubuntu clang version 14.0.0-1ubuntu1 - clang version 5.0.2 (tags/RELEASE_502/final) - gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0 - gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0

1 1

Re: [Boost-users] Boost configuration errors and problems
by Gavin Lambert 17 Apr '23

17 Apr '23

On 18/04/2023 02:32, Klebsch, Mario via wrote: > Since the vast majority of boost are header-only libraries, my usual > advice is no NOT use precompiled libraries of boost but to use boost > as a kind of source code library. This way, the source code is always > compiled with the same compiler flags as the rest of your code. > > I usually have to include > .../libs/system/src/error_code.cpp > .../libs/thread/src/pthread/* (or .../libs/thread/src/win32/*) > .../libs/chrono/src/* > .../libs/filesystem/src/* > In my Makefile, CMakeLists.txt or .vxcproj. Note that while doing this sort of thing is a valid strategy for a single application, it will get you into trouble if you split your app into separate EXE and DLL files and want to have any Boost types in the interfaces between them.

1 0

Re: [Boost-users] Boost configuration errors and problems
by Klebsch, Mario 17 Apr '23

17 Apr '23

Hello, > No suitable build variant has been found. > The following variants have been tried and rejected: > * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) Since the vast majority of boost are header-only libraries, my usual advice is no NOT use precompiled libraries of boost but to use boost as a kind of source code library. This way, the source code is always compiled with the same compiler flags as the rest of your code. I usually have to include .../libs/system/src/error_code.cpp .../libs/thread/src/pthread/* (or .../libs/thread/src/win32/*) .../libs/chrono/src/* .../libs/filesystem/src/* In my Makefile, CMakeLists.txt or .vxcproj. On Windows I also have to #define BOOST_ALL_NO_LIB to prevent the magic from trying to pick up pre-built libraries at link time and sometimes BOOST_THREAD_BUILD_LIB or BOOST_ALL_STATIC_LINK are required. Klebsch Mario Funktion | R&D Tel: +49 (0) 531 38 701 718 Raum: Braunschweig, E20 Diese E-Mail und die an sie angehängten Dateien sind ausschließlich für Personen oder Institutionen bestimmt, deren Namen oben aufgeführt sind. Sie können Informationen enthalten, die durch das Berufsgeheimnis geschützt sind und deren Weitergabe strengstens untersagt ist. Jede elektronische Nachricht kann geändert werden. ACTIA lehnt jede Verantwortung für diese Nachricht ab. Der Inhalt dieser Nachricht stellt keine Verpflichtung seitens unseres Unternehmens dar. Wenn Sie kein Empfänger sind, weisen wir Sie darauf hin, dass das Lesen, Vervielfältigen oder Verteilen strengstens untersagt ist. Wir bitten Sie daher, uns umgehend über diesen Brief zu informieren und diese Nachricht sowie eventuell beigefügte Unterlagen aus Ihrem Postfach zu löschen. Danke. This e-mail and the files attached to it are intended exclusively for persons or institutions whose names are listed above. They may contain information that is protected by professional secrecy and the disclosure of which is strictly prohibited. Any electronic message can be modified. ACTIA declines all responsibility for this message. The content of this message does not represent a commitment on the part of our company. If you are not a recipient, we would like to point out that reading, copying or distribution is strictly prohibited. We therefore ask you to inform us immediately about this letter and to delete this message and any accompanying documents from your mailbox. Thank you.

1 0

Re: [Boost-users] Precompiled Windows ARM/ARM64 binaries
by Tom Kent 14 Apr '23

14 Apr '23

On Fri, Apr 14, 2023 at 12:39 PM Stephan Brunner via Boost-users < boost-users(a)lists.boost.org> wrote: > Hi, > > are there any plans to ship precompiled windows binaries for ARM and/or > ARM64 at some time on SourceForge [1]? > Currently only a x86 and a x64 build is available there. > If not, I'll look into building my own version for those architectures. > > Thanks a lot! > > [1] https://sourceforge.net/projects/boost/files/boost-binaries/1.81.0/ > > No, I don't have a good windows arm/arm64 machine to test on, so don't want to make binaries I can't at least run a smoke test on. Beyond that, it would make the build process a lot more complex to run on multiple machines. The nice thing about i368 and amd64 is that you can run them both on the same windows install! Tom

1 0