August 2015 - Boost-users - lists.boost.org

Building Boost 1.59.0 on Solaris 11 with Solaris Studio 12.4
by Leo Carreon 21 Aug '15

21 Aug '15

Hi Boosters, I have been attempting to build Boost 1.59.0 on Solaris 11 using Solaris Studio 12.4 in C++11 mode. So far, I have managed to locate on the web solutions to 3 issues. Now I’m down to 22 targets failing to build. Has anyone else attempted to do the same? I would appreciate it if you could share some of your fixes if you have any. Has anyone reported that they have been able to cleanly build in this environment? Kind regards, Leo

2 7

Regarding dijkstra_shortest_path() in boost graph library
by Rohith Reddy 20 Aug '15

20 Aug '15

Hello there, I started using Boost graph library recently for one of my projects.I was trying to implement dijkstra's shortest path algorithm with the help of the following function, dijkstra_shortest_paths (G, vertex(a, G), distance_map(make_iterator_property_map(distance.begin(), vertex_id, distance[0])). predecessor_map(make_iterator_property_map(parent.begin(), vertex_id, parent[0])). visitor(make_dijkstra_visitor(copy_graph(G_copy, on_examine_edge())))); But while comparing the definition of the function as in http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/dijkstra_shortest_paths…, to the above written function,it doesnt make sense, especially the third argument of the above written function.Can anyone help me with this? Thanks in advance.

1 0

Encoding with read_xml()
by ashish g 20 Aug '15

20 Aug '15

Hi I was looking into using the function 'read_xml()' which parses an xml file and populates a ptree. However I had a couple of questions which I couldnt find documentation for. 1. Is the encoding of the xml file format preserverd when the data is stored into the ptree. i.e lets say I have an xml file in utf-8 format. Are the strings inside my ptree utf-8 encoded as well? Or is it converted to system default encoding? 2. Passing the locale information as an argument to read_xml(), what effect does it have? I believe it assumes the xml file is formatted using the locale encoding, or uses system locale encoding if no arg is passed. Is this true even if my xml 's first line explicitly states that it uses and encoding diff from the system encoding. for eg: lets say im on windows with 1252 encoding. My xml file is utf-8, and is specified on the first line. If i call read_xml() on this file, without passing a locale as arg, does it use system 1252 encoding to parse the file or utf-8? Any pointers would be very helpful. Thank you -- *Ashish Gudla*

1 0

[MSM] Stack blown with deferred events (1.59.0)
by Tom Gibson 20 Aug '15

20 Aug '15

Hi Boost-Users and Christophe, I'm having an issue when using MSM's deferred events feature. I've written a very basic example of a state machine, simulating batching upon receipt of events using the deferred message queue as a buffer, and then handling the events in another state once a watermark has been hit. This however, is not working as well as I'd hoped. I've made the batch size configurable with a constructor variable on the state machine, and am using guards in the transition table to do the checking. Whilst functionally this works, when I set a reasonably large batch size (10,000), the process cores. I've done a bit of digging in gdb, and it appears that the stack is being blown. `ulimit -s shows 8192` as my stack limit, raising this to 16384 with a 10k batch size works, although the performance is pretty bad. Raising the batch size to beyond the stack limit once again breaks MSM. I've attached my test program, and am compiling and running locally with: ``` clang++ -std=c++11 -o batcher -g batch_test.cpp ./batcher <batch size> [total events=100000] ``` To summarize, I've a few questions with my scenario. 1. Am I using the deferred events feature correctly? I believe I've followed the documentation, but it is entirely possible there's something I'm missing! 2. Is this a valid use case for the deferred events feature, or something that wouldn't be recommended? Handling of deferred events seems to be fine normally, but with a large number of events, the performance does seem to suffer significantly. For example, `time` shows a batch size of 10 taking 0.470s, with a batch size of 5000 taking 24.415s. This gap is closed significantly when built with with -02 due to inlining, but its still significant. 3. The stack blowing to me implies recursion when items are processed from the deferred events queue (rather than a linear iteration over the container (deque in my case)). I've tried to follow this in the MSM code, but it's heavy stuff. In this scenario, is it possible I would be better to implement my own queuing mechanism? Thanks, Tom

1 0

Errors and failed targets when building [filesystem]
by morbid code 19 Aug '15

19 Aug '15

Hi guys, I am extremely new at boost. I downloaded the latest version and I did the following: I am using windows7 64 bit and GCC 5.1. I opened command line, went to C:\boost\tools\build and ran the command: bootstrap gcc The output is: Bootstrapping the build engine execcmd.c: In function 'onintr': execcmd.c:120:5: warning: implicit declaration of function 'out_printf' [-Wimpli cit-function-declaration] out_printf( "...interrupted\n" ); ^ execnt.c: In function 'maxline': execnt.c:524:12: warning: type defaults to 'int' in declaration of 'result' [-Wi mplicit-int] static result; ^ make.c: In function 'make': make.c:132:13: warning: implicit declaration of function 'out_printf' [-Wimplici t-function-declaration] out_printf( "...found %d target%s...\n", counts->targets, ^ make.c: In function 'make0': make.c:735:13: warning: implicit declaration of function 'out_flush' [-Wimplicit -function-declaration] out_flush(); ^ modules/path.c: In function 'path_exists': modules/path.c:16:12: warning: implicit declaration of function 'file_query' [-W implicit-function-declaration] return file_query( list_front( lol_get( frame->args, 0 ) ) ) ? ^ Bootstrapping is done. To build, run: .\b2 --prefix=DIR install Then I ran: b2 --prefix=DIR toolset=gcc install According to the long output 322 targets have been updated. I put the path C:\boost\tools\build\DIR\bin to the environment variables. Lastly, I ran: b2 --build-dir=C:\boost-filesystem toolset=gcc --with-filesystem stage The output: ...found 8 targets... ...updating 5 targets... common.mkdir C:\boost-filesystem\boost common.mkdir C:\boost-filesystem\boost\architecture common.mkdir C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 common.mkdir C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\32. o libs\config\checks\architecture\32.cpp:9:36: error: size of array 'test' is negative int test[sizeof(void*) == 4? 1 : -1]; ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\32.o" "libs\config\checks\archi tecture\32.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\32.o... ...failed updating 1 target... ...updated 4 targets... Performing configuration checks - 32-bit : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\64. o ...updated 1 target... - 64-bit : yes ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\arm .o libs\config\checks\architecture\arm.cpp:13:2: error: #error "Not ARM" #error "Not ARM" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\arm.o" "libs\config\checks\arch itecture\arm.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\arm.o... ...failed updating 1 target... - arm : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\mip s1.o libs\config\checks\architecture\mips1.cpp:10:2: error: #error "Not MIPS1" #error "Not MIPS1" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\mips1.o" "libs\config\checks\ar chitecture\mips1.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\mips1.o... ...failed updating 1 target... - mips1 : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\pow er.o libs\config\checks\architecture\power.cpp:13:2: error: #error "Not PPC" #error "Not PPC" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\power.o" "libs\config\checks\ar chitecture\power.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\power.o... ...failed updating 1 target... - power : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\spa rc.o libs\config\checks\architecture\sparc.cpp:10:2: error: #error "Not SPARC" #error "Not SPARC" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\sparc.o" "libs\config\checks\ar chitecture\sparc.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\sparc.o... ...failed updating 1 target... - sparc : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\x86 .o ...updated 1 target... - x86 : yes ...found 3 targets... ...updating 3 targets... common.mkdir C:\boost-filesystem\boost\bin.v2 link.touch C:\boost-filesystem\boost\bin.v2\test-symlink-source link.mklink C:\boost-filesystem\boost\bin.v2\test-symlink symbolic link created for C:\boost-filesystem\boost\bin.v2\test-symlink <<===>> test-symlink-source ...updated 3 targets... - symlinks supported : yes ...found 1 target... ...updating 1 target... config-cache.write C:\boost-filesystem\boost\bin.v2\project-cache.jam ...updated 1 target... Component configuration: - atomic : not building - chrono : not building - container : not building - context : not building - coroutine : not building - coroutine2 : not building - date_time : not building - exception : not building - filesystem : building - graph : not building - graph_parallel : not building - iostreams : not building - locale : not building - log : not building - math : not building - mpi : not building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - timer : not building - wave : not building ...patience... ...found 690 targets... ...updating 51 targets... common.mkdir stage common.mkdir stage\lib common.mkdir C:\boost-filesystem\boost\bin.v2\libs common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0 common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ debug common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ debug\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ debug\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1 .0\debug\link-static\threading-multi\error_code.o gcc.archive C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\d ebug\link-static\threading-multi\libboost_system-mgw51-mt-d-1_59.a common.copy stage\lib\libboost_system-mgw51-mt-d-1_59.a C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\debug\link-st atic\threading-multi\libboost_system-mgw51-mt-d-1_59.a 1 file(s) copied. common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0 common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\debug common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\debug\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\debug\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\codecvt_error_category.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\operations.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\path.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\path_traits.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\portability.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\unique_path.o libs\filesystem\src\unique_path.cpp:28:0: warning: ignoring #pragma comment [-W unknown-pragmas] # pragma comment(lib, "Advapi32.lib") ^ gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\utf8_codecvt_facet.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\windows_file_codecvt.o gcc.archive C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1 .0\debug\link-static\threading-multi\libboost_filesystem-mgw51-mt-d-1_59.a common.copy stage\lib\libboost_filesystem-mgw51-mt-d-1_59.a C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1.0\debug\lin k-static\threading-multi\libboost_filesystem-mgw51-mt-d-1_59.a 1 file(s) copied. common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ release common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ release\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ release\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1 .0\release\link-static\threading-multi\error_code.o In file included from libs\system\src\error_code.cpp:16:0: ./boost/system/error_code.hpp:221:36: warning: 'boost::system::posix_category' d efined but not used [-Wunused-variable] static const error_category & posix_category = generic_category(); ^ ./boost/system/error_code.hpp:222:36: warning: 'boost::system::errno_ecat' defin ed but not used [-Wunused-variable] static const error_category & errno_ecat = generic_category(); ^ ./boost/system/error_code.hpp:223:36: warning: 'boost::system::native_ecat' defi ned but not used [-Wunused-variable] static const error_category & native_ecat = system_category(); ^ gcc.archive C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\r elease\link-static\threading-multi\libboost_system-mgw51-mt-1_59.a common.copy stage\lib\libboost_system-mgw51-mt-1_59.a C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\release\link- static\threading-multi\libboost_system-mgw51-mt-1_59.a 1 file(s) copied. common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\release common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\release\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\release\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\codecvt_error_category.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\operations.o libs\filesystem\src\operations.cpp:688:26: warning: '{anonymous}::create_symboli c_link_api' defined but not used [-Wunused-variable] PtrCreateSymbolicLinkW create_symbolic_link_api = PtrCreateSymbolicLinkW( ^ gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\path.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\path_traits.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\portability.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\unique_path.o libs\filesystem\src\unique_path.cpp:28:0: warning: ignoring #pragma comment [-W unknown-pragmas] # pragma comment(lib, "Advapi32.lib") ^ gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\utf8_codecvt_facet.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\windows_file_codecvt.o gcc.archive C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1 .0\release\link-static\threading-multi\libboost_filesystem-mgw51-mt-1_59.a common.copy stage\lib\libboost_filesystem-mgw51-mt-1_59.a C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1.0\release\l ink-static\threading-multi\libboost_filesystem-mgw51-mt-1_59.a 1 file(s) copied. ...updated 51 targets... So there are some warning while Bootstrapping the build engine, errors and failed targets when building the filesystem library. Should I be worried about them? What should I do?

1 0

Program Options and Filesystem ifstream
by Scott Morgan 19 Aug '15

19 Aug '15

Having a problem getting the following to compile under a Linux system (Mint 17.2, boost 1.54). It works okay with MSVC2010 and boost 1.57 though. **begin: main.cpp** #include <boost/filesystem/fstream.hpp> namespace fs = boost::filesystem; #include <boost/program_options.hpp> namespace po = boost::program_options; void test(fs::path& cfg_path, po::options_description& cfg_desc, po::variables_map& options) { po::store(po::parse_config_file(fs::ifstream(cfg_path), cfg_desc, true), options); } **end: main.cpp** Is this just a problem with 1.54's version of filesystem and/or program options? Scott **begin: GCC output** main.cpp: In function ‘void test(boost::filesystem::path&, boost::program_options::options_description&, boost::program_options::variables_map&)’: main.cpp:8:72: error: no matching function for call to ‘parse_config_file(boost::filesystem::ifstream, boost::program_options::options_description&, bool)’ po::store(po::parse_config_file(fs::ifstream(cfg_path), cfg_desc, true), options); ^ main.cpp:8:72: note: candidates are: In file included from /usr/include/boost/program_options.hpp:17:0, from main.cpp:3: /usr/include/boost/program_options/parsers.hpp:185:5: note: boost::program_options::basic_parsed_options<charT> boost::program_options::parse_config_file(std::basic_istream<charT>&, const boost::program_options::options_description&, bool) [with charT = char] parse_config_file(std::basic_istream<charT>&, const options_description&, ^ /usr/include/boost/program_options/parsers.hpp:185:5: note: no known conversion for argument 1 from ‘boost::filesystem::ifstream {aka boost::filesystem::basic_ifstream<char>}’ to ‘std::basic_istream<char>&’ /usr/include/boost/program_options/parsers.hpp:198:5: note: template<class charT> boost::program_options::basic_parsed_options<charT> boost::program_options::parse_config_file(const char*, const boost::program_options::options_description&, bool) parse_config_file(const char* filename, const options_description&, ^ /usr/include/boost/program_options/parsers.hpp:198:5: note: template argument deduction/substitution failed: main.cpp:8:72: note: cannot convert ‘boost::filesystem::basic_ifstream<char>((*(const boost::filesystem::path*)cfg_path))’ (type ‘boost::filesystem::ifstream {aka boost::filesystem::basic_ifstream<char>}’) to type ‘const char*’ po::store(po::parse_config_file(fs::ifstream(cfg_path), cfg_desc, true), options); ^ **end: GCC output**

2 3

multi_index member key extractors crash MSVC 2015
by Filip Konvička 19 Aug '15

19 Aug '15

Hi, it looks like using boost::multi_index::member<> crashes MSVC 2015 RTM when a const-qualified type is passed to it as the 2nd argument, but the member is actually non-const. #include <boost\multi_index_container.hpp> #include <boost\multi_index\member.hpp> #include <boost\multi_index\indexed_by.hpp> #include <boost\multi_index\ordered_index.hpp> struct X { int number; // non-const }; using namespace boost::multi_index; int main() { typedef multi_index_container<X, indexed_by<ordered_unique<member<X, const int, &X::number> > > > C; C c; c.find(1); // C1001 return 0; } ...\include\boost\multi_index\member.hpp(65): fatal error C1001: An internal error has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) I found the following on a related subject, but I'm not sure whether this is a separate issue or not. http://www.boost.org/development/tests/master/developer/output/teeks99-08l-… https://connect.microsoft.com/VisualStudio/feedback/details/1577162/vc-inte… https://groups.google.com/forum/#!topic/boost-devel-archive/gi-xGnCkvPI Thanks, Filip

2 1

[Asio] Measuring and improving SSL servier scalability
by Konrad Zemek 18 Aug '15

18 Aug '15

Hi all, I've built a few different Asio-based SSL servers in my career, but in my recent project the performance and resource-efficiency was paramount (as it's a library project), so I benchmarked it to make sure. Long story short, when benchmarking I found out that OpenSSL's error handling is a *very* serious bottleneck when scaling Asio+SSL over multiple threads. This can be "fixed", e.g. by using BoringSSL instead of OpenSSL, as BoringSSL uses thread-local storage for error data instead of locking a global mutex. As I didn't find any resources discussing bad Asio+SSL multithreaded performance (aside of one or two messages somewhere on this mailing list that complained about the problem; unfortunately I can't seem to find them right now), I've written up my knowledge into a blog post [1]. I believe it might be very useful to anyone who wants to build a multi-threaded SSL server/client on top of Asio. Konrad [1] https://konradzemek.com/2015/08/16/asio-ssl-and-scalability/

2 2

[units] implicit type conversions to specific unit quantity
by Michael Powell 17 Aug '15

17 Aug '15

Hello, I'd like to convert from an SI length quantity to a US inches quantity. I believe the following snippet will do what I want it to, but wanted to clarify if that was the case: http://www.boost.org/doc/libs/1_59_0/doc/html/boost_units/Quantities.html I am referencing the online docs, but needed some clarity in actually how to go about using it in practice: <code> using boost::units::si::meter_base_unit; using boost::units::us::inch_base_unit; // i.e. 0.3048 * 12 (inches/feet, feet/meter) BOOST_UNITS_DEFINE_CONVERSION_FACTOR(inch_base_unit, meter_base_unit, double, 3.6576); //... quantity<inch_unit> to_inches_length_quantity(quantity<length> const & L) { const quantity<inch_unit::unit_type> result_(L); return result_; } </code> Just besides that, there isn't a cleaner way of doing it? Some have mentioned going as far as creating a whole other system for my calculator's purposes, for example. Thank you... Best regards, Michael Powell

2 2

Re: [Boost-users] Building Boost 1.59.0 on Solaris 11 with Solaris Studio 12.4
by Leo Carreon 17 Aug '15

17 Aug '15

From: Leo Carreon Sent: Sunday, August 16, 2015 8:39 PM To: Boost Users Mailing List Subject: Building Boost 1.59.0 on Solaris 11 with Solaris Studio 12.4 >>Hi Boosters, >>I have been attempting to build Boost 1.59.0 on Solaris 11 using Solaris Studio 12.4 in C++11 mode. >>So far, I have managed to locate on the web solutions to 3 issues. >>Now I’m down to 22 targets failing to build. >>Has anyone else attempted to do the same? I would appreciate it if you could share some of your fixes if you have any. >>Has anyone reported that they have been able to cleanly build in this environment? >>Kind regards, >>Leo This is an update of my previous mail. I now have fixed 4 issues instead of 3. I also had a look at the build log generated from the above. It appears that the following issues are the cause of the remaining build problems which I haven’t figured out how to resolve yet: 1. ) "libs/thread/src/pthread/thread.cpp", line 103: Error: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && bool" is illegal. "libs/thread/src/pthread/thread.cpp", line 144: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())". "libs/thread/src/pthread/thread.cpp", line 150: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())". "libs/thread/src/pthread/thread.cpp", line 803: Error: The operation "bool && boost::shared_ptr<boost::detail::tss_cleanup_function>" is illegal. "libs/thread/src/pthread/thread.cpp", line 807: Error: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || bool" is illegal. "libs/thread/src/pthread/thread.cpp", line 817: Error: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || bool" is illegal. 2.) "./boost/thread/detail/nullary_function.hpp", line 125: Error: Cannot use std::shared_ptr<boost::detail::nullary_function<void()>::impl_base> to initialize bool. "./boost/thread/detail/nullary_function.hpp", line 125: Error: An expression of scalar type was expected. 3.) "libs/coroutine/src/posix/stack_traits.cpp", line 56: Error: Overloading ambiguity between "boost::call_once<void(&)(unsigned long*), unsigned long*>(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)" and "boost::call_once<void(*)(unsigned long*), unsigned long*>(boost::once_flag&, void(*)(unsigned long*), unsigned long*)". "libs/coroutine/src/posix/stack_traits.cpp", line 64: Error: Overloading ambiguity between "boost::call_once<void(&)(rlimit*), rlimit*>(boost::once_flag&, void(&)(rlimit*), rlimit*&&)" and "boost::call_once<void(*)(rlimit*), rlimit*>(boost::once_flag&, void(*)(rlimit*), rlimit*)". 4.) "./boost/proto/detail/preprocessed/make_expr_.hpp", line 73: Error: type is not a member of boost::proto::transform<boost::proto::switch_<boost::phoenix::phoenix_generator, boost::proto::tag_of<boost::proto::_>()>, void>::result<boost::phoenix::phoenix_generator(boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<1>>, 0>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<1>>, 0>>>, 2>)>. 5.) "libs/python/src/converter/builtin_converters.cpp", line 474: Error: Overloading ambiguity between "std::complex<double>::complex(double, double)" and "std::complex<double>::complex(complex double[2])". "libs/python/src/converter/builtin_converters.cpp", line 474: Error: Cannot return long from a function that should return std::complex<double>. 2 Error(s) detected. 6.) "./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)". 7.) "./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())". 8.) "./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())". These remaining issues are preventing me from building my own library because it depends on some of the Boost libraries that are still failing to build.

1 0

Re: [Boost-users] [boost] Making the Windows binaries 'official'
by Tom Kent 15 Aug '15

15 Aug '15

On Fri, Aug 14, 2015 at 8:34 PM, Glen Fernandes <glen.fernandes(a)gmail.com> wrote: > On Fri, Aug 14, 2015 at 9:03 PM, Tom Kent wrote: > > Is this something the community would be in favor of? I know that many of > > the people on these lists don't use windows and if they do are generally > > capable of building the windows binaries themselves, however there is a > > large group out there that prefers to just get the installer for them > (like > > they do for other projects like Qt, wxWidgets, etc). > > > > Thoughts? > > While I have not been a MSVC user for a while now: I think it's a good > thing for our VC users that binaries are available to them. > > Is (1) necessary? I was under the impression binaries becoming > available a few days after a source release is not uncommon. > This is basically how it is now....if people don't think it is necessary we can stick with this. However, I think it would be more professional if we change, hence my e-mail to the list. > SourceForge raises the usual concern: Can you trust a Windows > executable or DLL that you get from sourceforge.net anymore? > The .7z file and installers are SHA-256 hashed, and the list of hashes is signed with my GPG key. That said, I think we need to start planning an alternative to sourceforge for releases. It is not clear to me that it will still be around in a few years. That's a whole different thread though. > > Also, how do you cater to users who want variants that you're not > providing? i.e. Already you probably have Debug/Release * > 32-bit/64-bit * MT/MD/MTd/MDd * LIB/DLL (per 6 compiler versions). > What happens if someone wants /Gz or /Gv instead of /Gd etc. > I provide whatever bjam specifies with --build-type=complete. The bigger question is external libraries. I link with zlib, and bzip2 but not MPI for instance. I have had users ask for different version numbers of those libraries, but my answer is then that you're on your own for building anything else. These kind of questions are only relevant to far less than 1% of the people who download the binaries. Tom

2 1

[type_erasure] BOOST_TYPE_ERASURE_MEMBER with template?
by Nat Goodspeed 15 Aug '15

15 Aug '15

The code with which I'm working has two similar template classes: they have a common subset of 8 methods that could be used on an instance of either. For performance reasons, these methods are not virtual. As far as the compiler knows, the two template classes are unrelated. Naturally we can write a template function to accept an instance of either template class, as long as it uses only methods from the common subset. I also want to support runtime polymorphism, permitting a non-template function to accept an instance of either template class. Obviously that will incur some performance hit, but the coder can decide whether or not his/her function is performance-critical. If so, s/he can write that function to accept one or the other specific template class -- or write a template function. We want to incur the performance hit only when the coder deems that an acceptable tradeoff. The classic solution would be to derive both template classes from a common base class and make the common methods virtual -- but then that penalizes every consumer. I haven't yet used Boost.TypeErasure, but it seems to me potentially applicable to this problem. I see the example[0] illustrating use of BOOST_TYPE_ERASURE_MEMBER(). I was going to define requirements for each of the 8 common methods ... but then I became confused. Our common methods use a template parameter from the parent template class as a method parameter type. Can I invoke BOOST_TYPE_ERASURE_MEMBER in a generic way that would support all valid template parameters? Two of the 8 common methods are template methods, accepting a parameter whose type is a template parameter for the method rather than the containing class. I don't know whether that introduces further complexity. Thank you for any help you can provide! [0] http://www.boost.org/doc/libs/1_59_0/doc/html/boost_typeerasure/basic.html

2 1

Making the Windows binaries 'official'
by Tom Kent 15 Aug '15

15 Aug '15

<history> After the boostpro.com organization dissolved, there was never an official place to go to get pre-built binaries for the releases. Some random components were made available on the sourceforge download page and I had been hosting them on my own website (http://boost.teeks99.com) since I started building them around the release of 1.37. A couple years ago, before the release of 1.54, I asked the community if they would like my builds to be hosted on the sourceforge site, and the answer was positive: http://lists.boost.org/Archives/boost/2013/04/202460.php Since the 1.54 release, I've generally been uploading the windows binaries based on the RCs and enabling the downloads just a few minutes after the release notice goes out. </history> I would now like to propose that we make these libraries an official part of each Boost release. I don't think this entails much, just the following: 1) Have the release team coordinate with me to ensure that the binaries are ready before announcing the release. 2) Include a link to them in the release announcement. 3) Link to them from the website. It would also be good to get others who can run the scripts to perform the build, if I am someday unable to do this. The biggest hurdle here is having a (virtual) machine with all six versions of visual studio on it. Is this something the community would be in favor of? I know that many of the people on these lists don't use windows and if they do are generally capable of building the windows binaries themselves, however there is a large group out there that prefers to just get the installer for them (like they do for other projects like Qt, wxWidgets, etc). Thoughts? Tom Kent

1 0

[Graph] Descriptor invalidation on remove_vertex() with adjacency_list VL=vecS
by Chris Dellin 14 Aug '15

14 Aug '15

Hello, The documentation for the adjacency_list [0] is clear that if the vertex list container is vecS, then calling remove_vertex() will invalidate any vertex/edge descriptors into the graph. However, I was wondering if this is actually the case if the removed vertex was the one most recently added, that is, remove_vertex(vertex(num_vertices(g)-1)). In this case, I would think that no shifting of vertex data or adjustment of edge source/target indices would be necessary, and existing descriptors are guaranteed to be still valid. Is this safe to do with the current implementation? If not, why not? Thanks, - Chris Dellin [0] http://www.boost.org/doc/libs/1_59_0/libs/graph/doc/adjacency_list.html

2 1

[shared_ptr] boost::shared_ptr deleter question
by Tamas.Ruszkai＠leica-geosystems.com 14 Aug '15

14 Aug '15

Hi All, I wonder when the shared_ptr deleter is destroyed. I have a shared_ptr with a custom deleter. I would expect when the last shared pointer to the object is gone then not only the deleter method will be called, but the deleter function object is also released. As I see the deleter is taken by value and stored by value in the reference counter, so I do not understand what is going on. How is the deleter mean to be freed? Thanks, Tamas struct MyClassDeleter { ~MyClassDeleter() { // Break point is set here } void operator()(MyClass* item) { // Break point is set here } } { auto sharedPtr = boost::shared_ptr<MyClass>(new MyClass, MyClassDeleter) } // shared_ptr leaves the scope here, the custom deleter is called (parenthesis operator) // the deleter instance is however not destroyed, the breakpoint in the destructor does not hit

2 2

Log: Overwrite format of sink
by Florian Lindner 14 Aug '15

14 Aug '15

Hello, I have a console sink: boost::log::add_console_log(std::cout, keywords::format = fmtStream); with fmtStream being an expressions stream. After setting up the sinks I load a configuration file: std::ifstream file("log.settings"); init_from_stream(file); Is there a way to overwrite the format of this sink from within in the configuration file. Or, alternatively disable this sink. What I want to achieve is that a user have the option to modify the format without having two console outputs... Thanks, Florian

1 0

Query regarding interest in my submitting plf::colony to Boost
by Soul Studios 14 Aug '15

14 Aug '15

Hi all, I've had some expressions of support outside of the Boost community for submission of the plf::colony container and it's associated container plf::stack, mainly from the review judges for my cppcon submission on the same topic (topic didn't make it through to the finals but got a positive response). I'd like to guage reactions here to see whether it is worth spending the time necessary to port it to Boost, with all the associated reviews etc. plf::colony is a container for unordered data, where erasure and addition do not cause iterator/pointer invalidation, with superior performance characteristics to all std:: containers when either (a) Pointers and iterators which point to container elements must stay valid regardless of container additions and deletions and/or (b) Additions to or deletions from the container will be occurring in performance-critical code. Erasure performance in particular can be in advance of 6000x of vectors, while still being faster than lists, maps, deques etc for add and iteration. Full details and benchmarks across four compilers are here: http://www.plflib.org/colony.htm#benchmarks It has been thoroughly tested, including integrating it into the game engine I constructed last year as well as the usual unit tests. It supports both C++0x and C++11, and has been tested on the following compilers so far: Clang 3.4, GCC 4.6, 4.7, 4.8, 4.9 and 5.1 (both 32-bit and 64-bit), MS Visual C++ 2010 & 2013 (2015 supported but untested as yet). Internally a colony is a combination of a linked-list of increasingly-larger memory blocks combined with boolean erasure fields, combined with a custom memory location recycle stack. The most common comment I get is "that sounds kinda like a deque", so to save some time here are the differences (from the FAQ): "A double-ended queue requires a very different internal framework. It may or may not use a linked-list of memory blocks, dependent on the compiler, and has no comparable performance characteristics. Deque element erasure is very slow, similar to a vector, and it does not free unused memory blocks to the OS once they are empty, unlike a colony. In addition a deque invalidates references to subsequent container elements when erasing elements, which a colony does not. A colony never invalidates pointers/iterators to elements unless the element being referred to is erased." The rest of the faq is here and I would appreciate it if people read it before casting judgement: http://www.plflib.org/colony.htm I am aware that it will be a lot of work to port colony to Boost, so I will only undertake this if there is genuine interest. In addition, plf::stack - which colony must use internally - is a std::stack equivalent container but with much better performance characteristics, which can be used outside of plf::colony. Asides from the performance characteristics, colonies have the following positive and negative properties: Positive: Lack of pointer/iterator invalidation makes interrelating between collections of data easier, without the cache misses associated with vectors of pointers to dynamically-allocated objects. Negative: Due to the additional overhead, performance can be worse for scalar types. Thanks in advance- Matt B

5 13

[units] Conversions from quantities
by Michael Powell 14 Aug '15

14 Aug '15

Hello, Just wanted to clarify something. These should convert from given quantities to the desired units? double unit_conversion::from_length_to_inches(quantity<length> const & L) { const quantity<inch_base_unit::unit_type> result_(L); return result_.value(); } double unit_conversion::from_mass_to_pounds(quantity<mass> const & M) { const quantity<ounce_base_unit::unit_type> result_(M); return result_.value(); } >From an earlier post, I think maybe so, but I was interested in expert opinions, as well. https://groups.google.com/forum/#!topic/boost-list/YDJoMcu1Xx4 Thank you... Best regards, Michael Powell

4 4

Boost 1.59.0 has been released
by Marshall Clow 13 Aug '15

13 Aug '15

Release 1.59.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries * Convert: An extendible and configurable type-conversion framework, from Vladimir Batov. * Coroutine2: from Oliver Kowalke For details, including download links, see http://www.boost.org/users/news/version_1.59.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.59.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

3 2

[Interprocess][Container] nested containers and scoped allocators
by Malko 13 Aug '15

13 Aug '15

Hi, First of all my setup: I am compiling on redhat 6 with clang 3.4 in C++03, using boost_1_58. In a project of mine I am using a map<int, vector<int>> (types to be stored in shared memory and I am using the proper allocators as per interprocess documentation). If mymap is an instance of such a type, then mymap[0] is an invalid syntax because of issues that, to the best of my understanding, are related to the fact that the map tries to use the default constructor (with the default allocator) for the nested type as operator[] also accounts for the case in which the entry is missing and must be constructed. Using at() instead of operator[] makes the whole thing compile. On construction, I give the usual instance of allocator<void, segment_manager> to mymap. According to what I read in Boost.Container docs: http://www.boost.org/doc/libs/1_58_0/doc/html/container/Cpp11_conformance.h… It would seem to me that a scoped allocator is a mechanism by which the allocator I gave to mymap is passed down to the nested vector. In which case I would expect operator[] to try to use such allocator instead of the default one. But then again, I always do mymap.insert(std::pair<const int, vector<int,...>>(0, vector<...>(my_void_alloc))) to add an element to the map, since I need to specify the allocator (and the examples in interprocess use this syntax). Given all of this, I would be grateful for any insight into the following: 1. If the scoped allocator is meant to be passed from the map to the vector, why can I not use operator[] and I necessarily need to use insert() to create a new vector in the map? Have I misunderstood what a scoped allocator is? Thanks in advance. -- View this message in context: http://boost.2283326.n4.nabble.com/Interprocess-Container-nested-containers… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

1.59.0 rc3 is now available
by Marshall Clow 13 Aug '15

13 Aug '15

New Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ RC3 should fix the problem with VC14 and MSPDB140.DLL. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_rc3.7z) = 0a2e512844f3e30a6240f8139ee983f3 MD5 (boost_1_59_0_rc3.tar.bz2) = 6aa9a5c6a4ca1016edd0ed1178e3cb87 MD5 (boost_1_59_0_rc3.tar.gz) = 51528a0e3b33d9e10aaa311d9eb451e3 MD5 (boost_1_59_0_rc3.zip) = 08d29a2d85db3ebc8c6fdfa3a1f2b83c Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

5 4

[statechart] Events forwarding and orthogonal states
by lucaghera 13 Aug '15

13 Aug '15

Hi all, I've a problem similar to the one discussed in this old post: http://boost.2283326.n4.nabble.com/statechart-Broadcasting-events-to-orthog… I have a state, let's call it A, which contains two orthogonal regions. State X is the initial state of region 0 and state Y is the initial state of region 1. Both state A and state Y have a custom reaction for event E. State Y execute some computation based on event E while state A simply keeps track of how many times the event E is triggered. State A discard the event at the end of the custom reaction, while state Y forward it (the goal would be to forward it to the state A). >From the old post I think I have understood how the statechart library works and why the state Y never receives the event E. I guess that in my case state X is chosen as first state to process event E. Given that X is not interested in event E, the event is forwarded to state A, which process it and discard it. I see few possible solutions (with drawbacks) but I would like to know how this problem should be addressed. 1) I could do the counting directly in the state Y and remove the custom reaction to E from state A. This would work, however if tomorrow I will define a third state Z interested in E, I would have to duplicate the event counting code, which would work only if I assume that the Z and Y are not active at the same time (otherwise the event would be counted twice). 2) I could define an event that is listened only by state A and is triggered by the state Y after processing E. This doesn't seem really elegant and if multiple states are interested in E I have to be careful to not count the event twice. -- View this message in context: http://boost.2283326.n4.nabble.com/statechart-Events-forwarding-and-orthogo… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[variant] Possible regression from 1.55 to 1.58
by Mario Lang 12 Aug '15

12 Aug '15

Hi. I just upgraded my Boost from 1.55 to 1.58. My project doesn't build anymore, it fails on the following pattern, which used to work with 1.55: ---<snip>--- #include <algorithm> #include <boost/variant.hpp> #include <string> #include <iostream> #include <vector> struct visitor : boost::static_visitor<std::ostream &> { result_type operator() (int) { return std::cout; } result_type operator() (std::string) const { return std::cout; } }; int main() { std::vector< boost::variant<int, std::string> > v; visitor vis; foreach(v.begin(), v.end(), boost::apply_visitor(vis)); return 0; } ---<snip>--- The example is a bit silly, since foreach discards the return value of apply_visitor anyway. So my solution was to change the visitor to define result_type as void. This works. However, I am wondering why delayed_visitor does no longer work in this situation? Is it because I am trying to return a reference? -- CYa, ⡍⠁⠗⠊⠕

4 4

Problem accessing boost trac
by Leo Carreon 12 Aug '15

12 Aug '15

Hi Boosters, Sorry to be posting this here but I’m trying to access boost trac and I’m getting a certificate error. Does anyone know how to resolve this issue? Regards, Leo

2 1

[intrusive_ptr] Strange ternary op behavior with MSVC14
by TONGARI J 12 Aug '15

12 Aug '15

Hi, I found a strange bug while debugging: This is the minimal example that shows the problem: (the nullptr will be some other meaningful thing in real case) ```c++ #include <iostream> #include <boost/smart_ptr/intrusive_ptr.hpp> #include <boost/smart_ptr/intrusive_ref_counter.hpp> template<class T> struct wrapper { wrapper() = default; wrapper(boost::intrusive_ptr<T> const& p) : _p(p) {} boost::intrusive_ptr<T> const& get_ptr() const { #if 0 // This is OK. if (_p) return _p; return nullptr; #else // Strange behavior. return _p ? _p : nullptr; #endif } private: boost::intrusive_ptr<T> _p; }; struct W : boost::intrusive_ref_counter<W> { }; template<class T1, class T2> inline void test(wrapper<T1> const& s1, wrapper<T2> const& s2) { auto tup = std::make_tuple(s1.get_ptr(), s2.get_ptr()); std::cout << 0 << ":" << (void*)std::get<0>(tup).get() << "\n"; std::cout << 1 << ":" << (void*)std::get<1>(tup).get() << "\n"; } int main() { wrapper<W> a(new W), b(new W); test(a, b); return 0; } ``` If compiled with MSVC14, you'll see the 2 addresses are the same while they shouldn't. If if-stmt is used instead, the problem won't be shown. I also replaced intrusive_ptr with std::shared_ptr and the problem isn't shown as well. The same code works well with g++. It seems intrusive_ptr & MSVC14 specific but I can't reason about... Any idea?

3 5