- Boost-users - lists.boost.org

[log]: Filter declaration in settings files, associativity and operator precedence
by Bill Somerville 18 Sep '20

18 Sep '20

Hi all, I am experimenting with using multiple channels with Boost.Log. I am using the boost::trivial severity levels, the common attributes, and logging using BOOST_LOG_SEV() using a mix of global and class specific loggers. I am also using boost::log::init_from_stream(std::istream&) to configure sinks from a settings file. I would like to be able to define a sink filter that allows increasing the logging verbosity on just one channel but I am struggling to write succinct filer expressions. E.g given three channels A, B, and C I would like to write: Filter="(%Channel% = \"B\" and %Severity% >= trace) or %Severity% >= warning" to increase the verbosity to trace only on channel B, but this doesn't work. I am finding I have to write: Filter="(%Channel% = \"B\" and %Severity% >= trace) or (%Channel% != \"B\" and %Severity% >= warning)" Is this expected behaviour? If so then declaring more complex filtering will become burdensome. Regards Bill Somerville.

1 0

[Urgent request] : Boost default_locale() is causing an application crash!
by kamallochan Jena 17 Sep '20

17 Sep '20

Hi All, Thank you for your kind support! In one of our applications, we are using Boost library and recently found an application crash because of the locale object return from below highlighted code from Boost source code (path.cpp). Boost library source code (File name: path.cpp and line No: 865) seems to return NULL locale object [image: image.png] As per call stack, Application is found to be crashed when std::use_facet() tried to Getfacet id from the passed locale object : [image: image.png] Please Note: At above line 934, path_locale() calls to the above default_locale() which return an locale object with NULL value. *Can someone please answer the below queries:* 1>> In which scenario the code at std::locale(global_loc, new windows_file_codecvt);", mentioned above will return a locale object with NULL values ?? 2>> How to enable BOOST_ASSERT_MSG, so below code will execute ?? Example: BOOST_ASSERT_MSG(&path_locale(), "boost::filesystem::path locale initialization error"); 3>> In which conditions a locale object can be null ?? Thank you in Advance!!, please let me know if any further details are required on this issue. Regards, Kamal

3 4

[multiprecision] 128 bit integer support on Windows
by Neill Clift 15 Sep '20

15 Sep '20

Hi, I managed to get boost multi-precision to work with 128 bit integers on Windows using clang. I had to change this in clang.hpp: #if defined(__SIZEOF_INT128__) && !defined(BOOST_NVCC_CXX03) && !defined(_MSC_VER) <--- remove this last thing # define BOOST_HAS_INT128 #endif Clang-cl defines _MSC_VER for compat I guess. I had to pull in the library clang_rt.builtins-x86_64.lib for two routines needed for division and remainder. For my particular application I only saw a 10% improvement in performance. I am wondering if there are other things that need to be changed to get better performance? My program deals with integers of various sizes so it might be an artifact of the sizes of integers I mostly do operations on. I was expecting a bigger return. I am seeing the most expensive routine being _udivmodti4 on profiling. Division wasn't showing up as much in the traces before I made the change. Thanks. Neill.

1 0

Can boost.asio read/write io of files asynchronously?
by lampahome 02 Sep '20

02 Sep '20

As title, I read boost.asio documents and generally said io about http/network. I don't see any info. of io of files. Does boost.asio support read/write io of files asynchronously?

5 11

Program-options and priority
by DV Henkel-Wallace 31 Aug '20

31 Aug '20

Hi. I'm finding program_options pretty handy but I have a usage question which is not clear from the documentation. Is a hierarchy of sources not possible if I use value<T>(&my_arg)? My use case is the following: I have a hierarchy of sources: command line, environment variables, user-specified config file or default config file, and lastly a system default. I just set my_arg to whatever default is appropriate and then let parse_command_line do all the work. This is convenient because I can have a module simply define an options_description for callers to use. This works fine unless the option is specified twice (say command line and then environment). The last of the two values is used rather than the first one. Is this hierarchy only possible if I use value<T>() and not value<T>(&my_var)? That will add some complexity for callers. Thanks, d

1 0

Re: [Boost-users] Beast for IMAP
by Kenneth Porter 29 Aug '20

29 Aug '20

--On Saturday, August 29, 2020 11:27 AM +0300 Zhivko Vasilev via Boost-users <boost-users(a)lists.boost.org> wrote: > And IMAP complexity by itself is a "Beast" compared with SMTP. > > Not from boost libraries, but have you look at these libraries if you need > IMAP support. > https://github.com/dinhviethoa/libetpan > https://github.com/MailCore/mailcore2 > > As far as I know, most of the "modern" email apps which haven't used > proprietary code are based on these libraries. Thanks. I'd seen those and also this one: https://www.vmime.org/ I'm coming from using Mulberry and Thunderbird, which have their own IMAP implementation, but neither of those look easy to extract as standalone libraries. In addition to the complexity of IMAP, there's the need for authentication and encryption support, so there's a stack of additional libraries like GnuTLS, cyrus-sasl, and openssl needed. Some of these are hard to build on Windows. Fortunately the new Windows Linux Subsystem allows one to run Linux-based GUI programs in a VM and display on the Windows desktop. So I may go that route.

1 0

Beast for IMAP
by Kenneth Porter 29 Aug '20

29 Aug '20

I've been thinking about writing some email utilities and have looked at various IMAP libraries. I'm wondering if I should roll my own using Beast. I've seen an SMTP library using Beast on GitHub. Has anyone else attempted an IMAP client with Beast?

5 6

Re: [Boost-users] Beast for IMAP
by Richard Hodges 29 Aug '20

29 Aug '20

I maintain boost.beast. If you need any guidance or help you can find me on the cpplang slack most days in the #beast channel. https://cppalliance.org/slack/ On Sat, 29 Aug 2020 at 01:48, Kenneth Porter via Boost-users < boost-users(a)lists.boost.org> wrote: > I've been thinking about writing some email utilities and have looked at > various IMAP libraries. I'm wondering if I should roll my own using Beast. > I've seen an SMTP library using Beast on GitHub. Has anyone else attempted > an IMAP client with Beast? > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

1 0

Re: [Boost-users] Beast for IMAP
by Zhivko Vasilev 29 Aug '20

29 Aug '20

SMTP build with HTTP library sounds very strange. Beast is an HTTP 1.1 protocol library. IMAP and SMTP are also protocols and have nothing related to their syntax with HTTP. I had worked on the IMAP/SMTP app, and I think it is better to build with Asio only. The only one related point between HTTP and IMAP/SMTP, is if you need OAuth auth integration. Regards, Zhivko On Sat, Aug 29, 2020 at 2:48 AM Kenneth Porter via Boost-users < boost-users(a)lists.boost.org> wrote: > I've been thinking about writing some email utilities and have looked at > various IMAP libraries. I'm wondering if I should roll my own using Beast. > I've seen an SMTP library using Beast on GitHub. Has anyone else attempted > an IMAP client with Beast? > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

[LEAF] Review Results
by Michael Caisse 28 Aug '20

28 Aug '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

1 0