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

Clarification on statechart post_event vs process_event within react()
by John McCabe 10 Jan '22

10 Jan '22

Hi, Apologies if this has already been answered/clarified, but my search of the internet to try to get a definitive answer, at least one I recognised as being definitive, was unsuccessful. Below I have posted some source code, based on the stopwatch example from the tutorial, but using an 'external' object to delegate the actual handling of event stuff to and using the state, rather than simple_state base class, and some other tweaks. This is a cut down version of something that someone I work with has devised, but I just wanted to get a clear answer on whether process_event() should be getting called in cases like this. I think it probably should not since, in the code below, you change state (with a state object's destructor being executed) whilst you're executing that state's react(EvStartStop) function. If someone can confirm this is the correct interpretation that would be very much appreciated. Any questions, feel free to ask (BTW - I'm compiling for C++17) John PS - In case it's of any use, the output from running this code is: ------ Entered Active Entered Stopped Stopped - payload2 m_charValue: a Exited ~Stopped <<<--- This is the bit I don't like the look of because... Entered Running Active - payload2 m_charValue: a <<<--- ... this happens from the forward_event() call payload1 value1: 20 payload1 value2: 200.2 Exited ~Running Entered Stopped Exiting Program Exited ~Stopped Exited ~Active ------ If I swap the //*** comments to the doProcess() lines instead of doPost(), the output seems more sensible ------ Entered Active Entered Stopped Stopped - payload2 m_charValue: a Exited ~Stopped Entered Running Active - payload2 m_charValue: a payload1 value1: 20 payload1 value2: 200.2 Exited ~Running Entered Stopped Exiting Program Exited ~Stopped Exited ~Active ------ ========== code =========== #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/state.hpp> #include <boost/statechart/transition.hpp> #include <boost/statechart/custom_reaction.hpp> #include <boost/mpl/list.hpp> #include <iostream> #include <string> namespace sc = boost::statechart; namespace mpl = boost::mpl; // Forward declare a handler 'class' that's going to have activity delegated to it struct Handler; // Normal example start/stop and reset events struct EvStartStop : sc::event<EvStartStop> {}; struct EvReset : sc::event<EvReset> {}; // A couple of events that carry data with them struct EvPayload1 : sc::event<EvPayload1> { EvPayload1(int value1, double value2) : m_value1 { value1 }, m_value2 { value2 } {}; int m_value1 { 0 }; double m_value2 { 0.0 }; }; struct EvPayload2 : sc::event<EvPayload2> { EvPayload2(const char& charValue) : m_charValue { charValue } {}; char m_charValue { false }; }; // Back to the example bits struct Active; struct StopWatch : sc::state_machine<StopWatch, Active> { typedef sc::transition<EvReset, Active> reactions; // The extra 'handler' stuff void setHandler(Handler* handler) { m_handler = handler; }; Handler* getHandler() const { return m_handler; }; Handler* m_handler { nullptr }; // Used to make post_event() accessible from an external class...seems unpleasant, but... using sc::state_machine<StopWatch, Active>::post_event; }; // The implementation of the Handler class; created with a reference to a StopWatch object struct Handler { Handler(StopWatch& stopWatch) : m_stopWatch { stopWatch } {}; void doPost() { m_stopWatch.post_event(EvStartStop()); } void doProcess() { m_stopWatch.process_event(EvStartStop()); } StopWatch& m_stopWatch; }; struct Stopped; struct Active : sc::state<Active, StopWatch, Stopped> { Active(my_context ctx) : my_base { ctx } { std::cout << "Entered Active" << std::endl; }; ~Active() { std::cout << "Exited ~Active" << std::endl; }; typedef mpl::list<sc::custom_reaction<EvPayload1>, sc::custom_reaction<EvPayload2>, sc::transition<EvReset, Active>> reactions; sc::result react(const EvPayload1& payload1) { std::cout << "payload1 Event NOT HANDLED" << std::endl; return discard_event(); } sc::result react(const EvPayload2& payload2) { std::cout << "Active - payload2 m_charValue: " << payload2.m_charValue << std::endl; return discard_event(); } }; struct Running : sc::state<Running, Active> { Running(my_context ctx) : my_base { ctx } { std::cout << "Entered Running" << std::endl; }; ~Running() { std::cout << "Exited ~Running" << std::endl; }; typedef mpl::list<sc::custom_reaction<EvPayload1>, sc::transition<EvStartStop, Stopped>> reactions; sc::result react(const EvPayload1& payload1) { std::cout << "payload1 value1: " << payload1.m_value1 << std::endl; std::cout << "payload1 value2: " << payload1.m_value2 << std::endl; //***context<StopWatch>().getHandler()->doPost(); context<StopWatch>().getHandler()->doProcess(); return discard_event(); } }; struct Stopped : sc::state<Stopped, Active> { Stopped(my_context ctx) : my_base { ctx } { std::cout << "Entered Stopped" << std::endl; }; ~Stopped() { std::cout << "Exited ~Stopped" << std::endl; }; typedef mpl::list<sc::custom_reaction<EvPayload2>, sc::transition<EvStartStop, Running>> reactions; sc::result react(const EvPayload2& payload2) { std::cout << "Stopped - payload2 m_charValue: " << payload2.m_charValue << std::endl; //***context<StopWatch>().getHandler()->doPost(); context<StopWatch>().getHandler()->doProcess(); return forward_event(); } }; int main() { StopWatch myWatch; Handler myHandler(myWatch); myWatch.setHandler(&myHandler); myWatch.initiate(); myWatch.process_event(EvPayload2 { 'a' }); myWatch.process_event(EvPayload1 { 20, 200.2 }); std::cout << "Exiting Program" << std::endl; return 0; }

1 1

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

01 Dec '20

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

2 1

[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

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