- Boost - lists.preview.boost.org

Boost MSM attribute sharing problem
by Christophe Henry 28 Jun '17

28 Jun '17

>Hello everyone, > >I have an issue with* Boost MSM*. >Using *Boost MSM eUML* I have created a >state machine. Actually I created *HSM* (Hierarchical State Machine) or >Composite State Machine as second name. >And I faced with issue: How to >share attributes between Parent State Machine and Sub-State Machines >(or Child State Machine) ?? > >I have not found an answer on this question ... >Could anyone possibly help me ? > >*Thanks,* > >*Best RegardsDenis Kotov* Hi Denis, I think the best way is to have your attributes owned by the top-level state machine, then passed to the composite as say, a pointer. The top-level can call get_state, then set the attribute. For example, with eUML, supposing you declared the attribute with BOOST_MSM_EUML_DECLARE_ATTRIBUTE (or without for other front-ends): get_state<Composite&>().get_attribute(some_attribute) = &top_attribute; HTH, Christophe

1 0

Boost.Build and Microsoft C2 clang
by Niall Douglas 28 Jun '17

28 Jun '17

Can someone who has this working right please tell me how they persuaded Boost.Build to correctly invoke Microsoft C2 clang as the compiler and get it to link properly? My GSoC student has tried: - Configuring clang-win, this is a no-go, C2 clang comes in GCC arguments accepting form, not MSVC arguments accepting form. And no there is no clang-cl program supplied by Microsoft. - Configuring mingw gcc but with the C2 clang executable, this compiles code okay but fails at the link stage for some reason, probably it's trying to invoke the mingw linker and we want the Microsoft linker. Any help much appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 17

[thread] Interaction between interruption points and condition_variable
by David Stone 28 Jun '17

28 Jun '17

Assume 1) A thread is waiting on a condition_variable 2) That condition_variable has been notified that its condition is now true 3) The thread has been interrupted Given this, the interruption is processed rather than the condition_variable unblocking normally regardless of the order in which the notify and the interruption occur. That means that this program would eventually fail even though the notify always comes before the interrupt. #include <boost/thread/condition_variable.hpp> #include <boost/thread/lock_types.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/thread.hpp> #include <cassert> struct flag_t { using lock_type = boost::unique_lock<boost::mutex>; void notify() { auto lock = lock_type(m_mutex); m_flag = true; m_cv.notify_one(); } void wait() { auto lock = lock_type(m_mutex); m_cv.wait(lock, [=]{ return m_flag; }); } private: bool m_flag = false; boost::mutex m_mutex; boost::condition_variable m_cv; }; struct test_t { unsigned value = 0; ~test_t() { assert(value != 0); assert(value != 1); assert(value == 2); } }; int main() { while (true) { flag_t flag; test_t test; auto thread = boost::thread([&]{ test.value = 1; boost::this_thread::interruption_requested(); flag.wait(); test.value = 2; }); flag.notify(); thread.interrupt(); thread.join(); } } If we move the `flag.notify()` line before the thread creation, this program never terminates. This is because `boost::condition_variable::wait(lock_type &, function)` is defined as only blocking when the function returns false. The only way this program can terminate is if `thread` begins execution and executes `flag.wait()` before `flag.notify()` is called, then `thread.interrupt()` runs before `thread` is unblocked. It seems more intuitive to me that if a thread is blocked on a condition_variable and it is interrupted that it would unblock normally rather than throwing boost::thread_interrupted. Under that behavior, users who want the current behavior can always check after they leave a condition_variable::wait using `boost::this_thread::interruption_requested()` and throw rather than processing data. Under the current behavior, I do not believe there is any way to process the data in a function that does not have access to the thread object without losing the fact that an interruption was requested. This would only be possible if we had a function like `boost::this_thread::interrupt()`, but that does not exist. I do not know what code (if any) depends on the current behavior of interruptions always taking precedence over notifications, but it appears that the current behavior is undocumented. Is there a justification for the current behavior or is it just the way it happened to be implemented? Is this something we could change, or at least allow users to implement the behavior I outlined?

3 5

Reminder: 1.65 closes for major changes tomorrow
by Marshall Clow 28 Jun '17

28 Jun '17

Upcoming release dates: 28-Jun: Boost 1.65.0 closed for major changes 5-Jul: Boost 1.65.0 closed for all changes, except by permission of a release manager. 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release -- Marshall

6 12

Testing for ML Admin
by Alexander Zaitsev 28 Jun '17

28 Jun '17

Hello. Â I am simple letter and i want to be a part of boost mailing list. Â Hey, see - i have body. Head and body. Â --Â Best regards, Alexander Zaitsev Â

1 0

[sort] pdqsort mini-review
by Александр Зайцев 27 Jun '17

27 Jun '17

Hello. Try to send my thoughts from another email. 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort? 1. Only that pdqsort is really better than std::sort's Introsort 2. Yes, it does. 3. Pdqsort is much faster than std::sort. 4. Yes, i do. I think that pdqsort is really good sort algorithm - it's really fast and pdqsort is already implemented sort algorithm in Rust's libcore as sort_unstable. 5. No, i have not. Best regards, Alexander Zaitsev zamazan4ik(a)gmail.com

1 0

[sort] pdqsort mini-review
by Александр Зайцев 27 Jun '17

27 Jun '17

Hello. Try to send my thoughts from another email. 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort? 1. Only that pdqsort is really better than std::sort's Introsort 2. Yes, it does. 3. Pdqsort is much faster than std::sort. 4. Yes, i do. I think that pdqsort is really good sort algorithm - it's really fast and pdqsort is already implemented sort algorithm in Rust's libcore as sort_unstable. 5. No, i have not. Best regards, Alexander Zaitsev mazahaka2009(a)list.ru

1 0

Interest in another formatting library ?
by Roberto Hinz 27 Jun '17

27 Jun '17

Hi, Is there space for another formatting library in Boost? Anyone interest in this one? doc: https://robhz786.github.io/stringify/doc/html/index.html code: https://github.com/robhz786/stringify

5 11

Cmake
by Peter Dimov 26 Jun '17

26 Jun '17

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios: 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). 2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them. 3. The user uses CMake to install an individual Boost library, which is then available for find_package. 4. The user uses CTest to run the tests of an individual Boost library. 5. CMake is supported as a way to build and install the entire Boost, in place of b2. 6. CTest is supported as a way to run the tests for the entire Boost, in place of b2. At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck. 5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works. I've done a proof of concept for (2), which can be seen here: https://github.com/pdimov/boost-cmake-demo-2 This repository uses git submodules in ext/ to bring in Boost.System (our guinea pig) and its dependencies, then uses them via add_subdirectory in https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt The required CMake infrastructure is on branch feature/cmake in those six libraries (assert, config, core, predef, system, winapi.) It consists of CMakeLists.txt in the root: https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b6… and supporting .cmake files in cmake/ : https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b6… The goal here is for Boost library developers to be able to remain ignorant of CMake if they so choose; so of those files, only sources.cmake requires their input (it's empty for header-only, so those require nothing at all.) BoostVersion.cmake and default.cmake are common for all libraries and are copied from the superproject. dependencies.cmake is automatically generated with boostdep. There is a Jamfile in cmake/ that updates these three files: https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b6… and the intent is for this to be done automatically in a superproject script that invokes "b2 cmake" for the superproject: https://github.com/pdimov/boost-cmake-demo/blob/master/cmake/Jamfile which in turn invokes "b2 cmake" in each library having "cmake/Jamfile". Copying BoostVersion.cmake and default.cmake, instead of referring to them, allows libraries to be used without a superproject, to support scenarios (2) and (3) above. (Scenario (3) is also supported by default.cmake.) What remains to be done is (a) to extend this to the rest of the Boost libraries, if we decide to do so, which would require figuring out a way to cope with the numeric/ irregular libraries, and (b) support for scenario (1) above. Scenario (1), that is, `b2 install` making the installed Boost available for CMake find_package use, is an entirely separate undertaking, completely independent of what I've done - except for possibly reusing the dependencies.cmake files. It would entail generating boost_libname-config.cmake and boost_libname-config-version.cmake files for each library, and boost_libname-config-<suffix>.cmake subconfiguration files for each build variant (toolset, variant=debug/release, link=static/shared, runtime-link=static/shared, runtime-debugging=on/off, threading=single/multi, and possibly python-debugging=on/off.) This would probably require us to define CMake variables controlling these features, such as BOOST_BUILD_TOOLSET, BOOST_BUILD_VARIANT, BOOST_LINK_TYPE, BOOST_RUNTIME_LINK, and so on, with them having appropriate default values inferred from the CMake environment. Then, boost_system-config-vc141-mt-gd-1_65.cmake will check these values and if BOOST_BUILD_TOOLSET is "vc141", BOOST_LINK_TYPE is SHARED, BOOST_RUNTIME_LINK is SHARED and BOOST_RUNTIME_DEBUGGING is ON, it will declare an imported target pointing to boost_system-vc141-mt-gd-1_65.lib/dll, otherwise it would do nothing. (Not sure how relevant is threading=single/multi today, but in principle, it should also check BOOST_THREADING == MULTI.) Generating these -config.cmake files would ideally be done as part of the `b2 install` procedure and require no changes to the individual libraries. The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen. At this point, I know what needs to be done, but not how to bring it about.

16 67

Re: [boost] What's wrong with top-posting?
by Brian Wood 26 Jun '17

26 Jun '17

David Abrahams writes: > At Tue, 26 Jan 2010 10:09:43 -0800, > Robert Ramey wrote: >> > > I thought I was familiar with the guidelines and never remembered this. >> >> I top-post all the time. It seems much more natural to me when >> it's not convenient to intersperse comments into the previous >> message. Why I like top posting: >> >> a) It means that I don't have to scroll to the bottom of a message >> which is sometimes pretty long. >> b) To me it is more natural to follow the style >> of other communications (artilcle, books, etc) which make >> their point in the main text and refer to footnotes, bibliographies, >> etc at the end of the main text. > > c) You don't confuse or even *upset* (as I've discovered the hard way) > many people in the business world, where top-posting and > overquoting is the accepted standard. Every message drags along > the entire thread history with it, and you keep a record of > everything by storing the final message. (yuck) It's a cultural > thing, and Boost fits into the open-source programmer weenie > culture much more than the business culture. I was getting annoyed by some top-posting here recently, so I dug up this thread. Is an "open-source programmer weenie culture" like a nerdy culture? Anyway, please stop top posting and trim the old parts of the thread that are no longer needed. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

4 3