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

[interprocess] Determine size of managed_shared_memory
by Kai Benndorf 12 Oct '19

12 Oct '19

Hi all, I want to create a managed_shared_memory in exactly the size I needed. Therefore I do something like this: size = sizeof( common_managed_shared_memory ); size += sizeof( MyClassInSharedMem ); managed_shared_memory segment(create_only, "name", size ); MyClassInSharedMem allocates itself some memory by segment->allocate(). I added this also to the size, but get a boost::interprocess::bad_alloc exception on allocating this additional memory. Are there some magic bytes I forgot to add? Many thanks in advance Kai

3 2

[Range, Phoenix] What am I missing...
by Robert Jones 25 Apr '17

25 Apr '17

Hi Folks Can anyone explain the output of this program... #include <iostream> #include <boost/range/algorithm/copy.hpp> #include <boost/range/counting_range.hpp> #include <boost/range/adaptor/reversed.hpp> #include <boost/range/adaptor/transformed.hpp> #include <boost/phoenix/bind/bind_function.hpp> #include <boost/phoenix/core/argument.hpp> int f( int i ) { return i * 2; } int main( ) { using boost::adaptors::reversed; using boost::adaptors::transformed; using boost::counting_range; using boost::copy; using boost::phoenix::arg_names::_1; copy( counting_range( 1, 5 ) | reversed | transformed( f ), std::ostream_iterator<int>( std::cout, " " ) ); std::cout << std::endl; copy( counting_range( 1, 5 ) | reversed | transformed( bind( f, _1 ) ), std::ostream_iterator<int>( std::cout, " " ) ); std::cout << std::endl; } Which is... 8 6 4 2 1768406272 1768406272 1768406272 1768406272 I'm using Gcc 4.6.2 & Boost 1.53 Thx All.

3 4

[statechart] Passing parameters from event to State Local Storage
by Christophe Bourez 16 Nov '16

16 Nov '16

I need to maintain a parameter into the state local storage. This parameter is initially contained in the event that causes the transition to the target state. I give hereafter a small illustrative example. typename sc = boost::statechart; class EvTest : public sc::event<EvTest> { public: EvTest(std::size_t val) : value(val) {} std::size_t getValue() const { return this->value; } private: std::size_t value; }; class MyStateMachine; class StSource; class StTarget; class StSource : public sc::simple_state<StSource, MyStateMachine> { public: typedef sc::custom_reaction<EvTest> reactions; sc::result react(const EvTest &event) { // How to pass event.getValue() to the target state ? transit<StTarget>(); } }; class StTarget : public sc::simple_state<StTarget, MyStateMachine> { public: StTarget(std::size_t val) : val(value) {} private: std::size_t value; }; Thanks, Christophe

5 6

Re: [Boost-users] lexical_cast between double and string slow in Visual Studio 2013
by David Roberts 07 May '15

07 May '15

> That issue is unknown. I'd really appreciate the investigation. I have done some more investigation, and there are two factors that only cause the slowness when they both occur together. > Try excluding the lexical_cast from test, I have a feeling that this is only MSVC related issue: > > #include <sstream> > #include <string> > > int main (int, char **) > { > for (double count = 0.0; count < 1000000.0; count += 1.41) > { > std::stringstream ss; > ss << count; > std::string result = std::move(ss.str()); > ss.str(std::string()); > > ss << result; > ss >> count; > } > > return 0; > } > Running your test program does not exhibit the problem. It runs in around 3 seconds on my machine when built with either Visual Studio 2010 or Visual Studio 2013. However, changing it very slightly to match more closely what lexical_cast does internally does recreate the problem: #include <sstream> #include <string> int main (int, char **) { for (double count = 0.0; count < 1000000.0; count += 1.41) { std::stringstream ss; ss.unsetf(std::ios::skipws); ss.precision(17); ss << count; std::string result = std::move(ss.str()); ss.str(std::string()); ss << result; ss >> count; } return 0; } The effect of setting the precision to 17 is that lots of 9s appear in the string representations. (The number 17 is what boost::detail::lcast_get_precision(double*) chooses.) Without the precision call the contents of the string called result start off like this: 0 1.41 2.82 4.23 5.64 7.05 8.46 9.87 11.28 12.69 With precision set to 17 they start off like this: 0 1.4099999999999999 2.8199999999999998 4.2299999999999995 5.6399999999999997 7.0499999999999998 8.4599999999999991 9.8699999999999992 11.279999999999999 12.69 This happens for both Visual Studio 2010 and Visual Studio 2013. Then the next difference is that Visual Studio 2013 spends a lot longer handling all the extra 9s. Changing the program so that the double is converted to a string using std::stringstream without a precision call and then back to double using lexical_cast takes about 3 seconds for both Visual Studio 2010 and Visual Studio 2013. It is the combination of having all the extra 9s to parse and using Visual Studio 2013 that makes the test using lexical_cast to go both ways slow. Both Visual Studio 2010 and Visual Studio 2013 do the conversion by calling std::num_get<char,std::istreambuf_iterator<char,std::char_traits<char> > >::do_get() which then calls a function called _Stodx() which is implemented in xstod.c. This function is very different for the two versions. In Visual Studio 2010 it's a relatively thin wrapper around the C function strtod(). In Visual Studio 2013 _Stodx() has got a completely new implementation that's generated by #including xxstod.h with some macros defined. The original C function strtod() is much faster than the new _Stodx() when there are lots of 9s at the end of the strings being parsed. This modification to the program: #include <sstream> #include <string> #include <stdlib.h> int main (int, char **) { for (double count = 0.0; count < 1000000.0; count += 1.41) { std::stringstream ss; ss.unsetf(std::ios::skipws); ss.precision(17); ss << count; std::string result = std::move(ss.str()); ss.str(std::string()); ss << result; char *endptr; count = strtod(ss.str().c_str(), &endptr); } return 0; } has a runtime of about 3 seconds even though it's got to cope with all the 9s. I guess only someone from Microsoft or Dinkumware could comment on why _Stodx() was reimplemented. But the other thing is that by setting precision to 17 lexical_cast is bloating the string representations of the doubles with lots of 9s in both Visual Studio 2010 and Visual Studio 2013. Setting precision to 15 instead prevents this, and makes the original test run faster even with Visual Studio 2013 (about 4 seconds rather than 10). Regards, David

5 4

Statechart serialization
by mbrodeur65 04 Mar '15

04 Mar '15

Hi, I'm looking for a solution to serialize boost::statechart objects. I'm aware that this feature is on the statechart library todo list but was wondering if there are any workaround to achieve this with the latest boost release (1.34) ? thanks for your help ! mbrodeur65 -- View this message in context: http://www.nabble.com/Statechart-serialization-tf4131326.html#a11749139 Sent from the Boost - Users mailing list archive at Nabble.com.

4 4

[endian] Boost.Endian library added for 1.57.0
by Beman Dawes 14 Dec '14

14 Dec '14

The library provides integer and floating point types and conversion functions for portable byte ordering regardless of processor endianness. Although the primary uses are for file or network I/O, it is also useful for unaligned integers or floats, or for 3, 5, 6, and 7 byte integers. The library's predecessors have been in use for thirty years and developed independently multiple times. The repository is https://github.com/boostorg/endian The documentation is online at https://boostorg.github.io/endian/ See https://boostorg.github.io/endian/index.html#Release-history for changes since the Formal Review. No need to report "Inspection Report" problems; those will be cleaned up before 1.57.0 ships. Please do report any other problems or concerns, since the time between now and when the 1.57.0 beta ships in effect acts a mini-review period. If anyone has access to a big-endian platform with a modern C++ compiler, please, please run the endian test suite and report the results. All testing and use in recent years has been on little-endian platforms, so big-endian platform testing is a worry. Thanks for you patience, --Beman

3 2

Fusion Move Semantics
by Ovanes Markarian 04 Dec '14

04 Dec '14

Hi! I would like to ask does fusion supports move semantics, or are all the values going to get copied. I use C++11 (clang with libstdcxx) and boost 1.54 (but can upgrade). In my use case I have boost::fusion::map and was wondering, that in case of moving of that map, is it going to forward the move call to contained values or not. Many thanks for help, Ovanes

3 2

NT² 3.0 and Boost.SIMD - Stable release
by Joel Falcou 21 Nov '14

21 Nov '14

The first stable release of the 3.x series of MetaScale’s open-source software is available: NT² 3.0. It also includes its spin-off project, Boost.SIMD (not yet a Boost library). Many Issues have been closed since last beta. The main focus of this release cycle was to fix performances issues and to stabilize some parts of the API. Next step will be to separate NT2 and Boost.SIMD into separate repositories, thus making one more step toward Boost.SIMD submission into review. [ http://www.metascale.org/nt%C2%B2-3-0-and-boost-simd ] *Changes & Bug Fixes:* - Major performance improvements in both libraries - Added experimental support for the HPX runtime for parallelization on shared memory systems - Optimizations of many elemental functions, in particuler log/ex, frexp/ldexp and cbrt - More advanced shuffle pattern recognition for SIMD - Fixed issues with Visual Studio 2013 - More functions are force-inlined to ensure good performance - New functions for conversion between types and mixing of vectors of different sizes - Demo applications usable as benchmarks - Better handling of errors when an unsupported function is called - New API for custom memory allocators Full changelog is available at https://github.com/MetaScale/nt2/releases/tag/3.0.0. *How to get it ?* - Source and binary packages can be downloaded here: http://nt2.metascale.org/downloads - The release is also available on Github : https://github.com/MetaScale/nt2/releases - The main master branch is still under development : https://github.com/MetaScale/nt2

4 4

[property_tree] Failure with Boost 1.56
by beet 10 Oct '14

10 Oct '14

Dear all, with the release of Boost 1.56, on Ubuntu 14.04 (g++ 4.8.2, 64 bit), code like the following suddenly fails to compile: pt::xml_writer_settings<char> settings('\t', 1); pt::write_xml(someFileName, ptr_out, std::locale(), settings); "pt" is obviously an alias for boost::property_tree. The error message I'm getting is /opt/boost156/include/boost/property_tree/detail/xml_parser_writer_settings.hpp:38:35: error: 'char' is not a class, struct, or union type typedef typename Str::value_type Ch; I can see the following possibly relevant change in property_tree: In Boost 1.55, from xml_parser.hpp: ----------------------------------- template<typename Ptree> void write_xml( const std::string & , const Ptree & , const std::locale & = std::locale() , const xml_writer_settings<typename Ptree::key_type::value_type >& = xml_writer_settings<typename Ptree::key_type::value_type >() ); In Boost 1.56, same header: --------------------------- template<typename Ptree> void write_xml( const std::string & , const Ptree & , const std::locale & = std::locale() , const xml_writer_settings<typename Ptree::key_type > & = xml_writer_settings<typename Ptree::key_type >() ); So xml_writer_settings is now given a Ptree::key_type instead of a Ptree::key_type::value_type which I assume is the reason for the above error. Is there a portable way to specify the type of indention character in write_xml ? Best Regards, Beet

2 1

[thread] memory synchronization multiple mutexes
by firespot 19 Sep '14

19 Sep '14

Hi, How does memory synchronization and visibility behave when multiple mutexes are involved? I have two groups of threads (boost::thread_group) and two mutexes (boost::mutex m1, boost::mutex m2) + associated condition variables, with each thread group being responsible to write to some variables (here Ptr, run) and consistently using "its" mutex for locking. However there is a piece of code that looks - much simplified - like this: void f() { { boost::unique_lock<boost::mutex> Lock(m1); Ptr = someAddress; // set the Ptr from 0 to some memory address } { boost::unique_lock<boost::mutex> Lock(m2); run = 1; // was 0, inform that execution can proceed condVar2.notify_all(); } ... // wait until Ptr has been reset to 0 { boost::unique_lock<boost::mutex> Lock(m1); while (Ptr != 0) condVar1.wait(Lock); } } and another function: void g() { { boost::unique_lock<boost::mutex> Lock(m2); while (run == 0) condVar2.wait(Lock); } // run the execution, e.g. std::copy(Ptr, Ptr + 100, Target); // finally all finished, signal back that Ptr is not needed any more { boost::unique_lock<boost::mutex> Lock(m1); Ptr = 0; condVar1.notify_all(); } } f() is only invoked from a thread of the first group, and g() only from a thread of the second group. Whenever Ptr might get changes the first mutex (m1) and its associated condition-variable is used, and whenver run might get changed the second mutex and its associated conditional variable is used. The control flow guarantees that run is not set to 1 prior to Ptr being set, and thus in g() the "running" itself (here the std::copy) cannot commence earlier. However, what puzzles me now: I used a different mutex for setting Ptr and setting/checking run. Does this have any impact whatsoever on memory visibility across the threads in the two thread-groups? Specifically, is it always guaranteed that when g() continues its execution (because run == 1) that it must see the correct value of Ptr (a non-NULL value)? Or is it possible that it still sees 0 and I'd have to make a separate locking involving m1 to guarantee a proper read for Ptr as anything written under a lock of m1 is also only guaranteed to be later properly read if the locking also used m1? thanks!

2 1