July 2015 - Boost - lists.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[WG21 mailing] N4453 Resumable expressions
by Niall Douglas 15 Oct '15

15 Oct '15

I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf I essentially proposed the same with my functionally composed constexpr basic_future design some months ago. Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 17

Re: [boost] [afio] AFIO review postponed till Monday
by Glen Fernandes 29 Aug '15

29 Aug '15

Did the review start yesterday? Glen

18 84

"Simple C++11 metaprogramming"
by Peter Dimov 22 Aug '15

22 Aug '15

I've recently made the mistake to reread Eric Niebler's excellent "Tiny Metaprogramming Library" article http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/ which of course prompted me to try to experiment with my own tiny metaprogramming library and to see how I'd go about implementing tuple_cat (a challenge Eric gives.) Ordinarily, any such experiments of mine leave no trace once I abandon them and move on, but this time I decided to at least write an article about the result, so here it is, with the hope someone might find it useful. :-) http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html

17 55

[filesystem] proposal: treat reparse files as regular files
by Paul Harris 14 Aug '15

14 Aug '15

Hi all, -- Proposal -- tl;dr : I propose that we treat all non-symlink "reparse_files" as "regular_files". If the boost library user wants to do something special with these plain reparse files, they should use alternative means. But typically they are supposed to be treated as regular files. This means we could drop the "reparse_file" enum, or continue to use it for a special-case whats_my_real_status() function. --- Motivation --- Windows Server 2012 uses reparse points to implement deduplification. Those files should be treated as regular files in all circumstances. Currently, they are not classed as "regular" files, so fs::copy() will skip those files, and library-user code written to list files based on official examples will ignore all dedup'd files. This is causing serious and latent problems at the user end, because deduping only happens occasionally after X days, and users cannot easily check if a file is dedup'd (they look just like regular files). --- Real life example --- Another example of reparse use is the "Symantec Enterprise Vault" (version 10), which I found running on one site. It replaces files on the server with reparse-point files. FSUTIL REPARSEPOINT QUERY filename.txt shows the contents of the reparse buffer, which is a URL to an internal HTTP server. The url points to a .asp link with a bunch of codes and dates to identify the file in the server. Copy-pasting that URL into a webbrowser allows you to directly download the file via the webbrowser, which is pretty neat I suppose. In this case, the reparsed-files in Windows Explorer all have grey X crosses on their file icon. If you "type" them (via cmd) or open them, the icon loses the grey cross and the file is no longer a reparse point file. My software refused to read the files because they were "not regular files". Once I adjusted the boost code (described below), my software saw them as regular and opened the files. The file icons lost the grey cross. SO it seems that the file server automatically downloads and replaces the files with the stored content on demand, and the file reading client program should really just treat these files as normal files. --- Short logic --- reparse files (that are not symlinks) should almost always be treated as plain files. They are a mechanism for MS file servers to store files in clever ways, but the client should not care and just read/write them as if they were normal files. This is different to all the other "other" files which can't be treated like normal files: block, character, fifo, socket, unknown So, reparse files should not be grouped with the "other" file types. They are also NOT symlinks, and should not be treated as symlinks (which would require special decisions for copying, or querying the status, or checking if the target still exists). --- What are reparse files --- I did some reading, if I understand correctly: Reparse points give drivers (on the server) a chance to get data through some other specialised means (eg query from a cluster store). They are processed by the server, not the client, so clients should treat reparse data as opaque data. EXCEPT for symlink reparse files. https://msdn.microsoft.com/en-us/library/dd541667.aspx quote:"The following reparse tags, with the exception of IO_REPARSE_TAG_SYMLINK, are processed on the server and are not processed by a client after transmission over the wire. Clients should treat associated reparse data as opaque data." It seems like the rest of the tags are used for connecting files to other types of storage (eg long term storage, cluster storage). Clients may need to do something special with SOME reparse point files, IF the client cares about how long the file read may take. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365505(v=vs.85).… quote: "Most applications should take special actions for files that have been moved to long-term storage, if only to notify the user that it may take a while to retrieve the file." --- Changes required --- Option 1: change is_regular_file() to return true where type==reparse_file I don't like this option, as library-users could be checking the type directly instead of using is_regular_file(). Option 2: These functions return reparse_file: fs::file_type query_file_type(const path& p, error_code* ec) file_status status(const path& p, error_code* ec) file_status symlink_status(const path& p, error_code* ec) They should instead return regular_file instead. --- How to test with dedup files --- Creating dedup'd files is a feature only available on Windows Server 2012, I believe, although Windows XP/Vista/7/8/10 clients all can read dedup files. Here is how I created a windows server to test with (for free!) on a demo Azure cloud server. I have one working, so if anyone would like to use it for their testing, let me know. Step one: follow this blog article: http://blogs.technet.com/b/tommypatterson/p/azureservertrial.aspx once the machine was "running" I clicked Connect at the bottom. That gave me an .rdp file which in theory I could use with rdesktop, but it uses a DNS name that was only just created, so that didn't work. When you click the name of the server in the list, it shows the public IP on the right.. and the port then you can do this $ rdesktop that.ip.addr:port But only if you have the latest rdesktop AND you have set up kerberos something-something. Instead I found a windows computer and used remote desktop from there. --- Once inside, in the "Server Manager --> Dashboard" window on the screen, click "Add Roles" then go next next until "Server Roles" expand "File and Storage services" , "File and iSCSI" , and tick "Data Deduplication" Then next next etc and Install. Wait a bit... and its done. http://www.techrepublic.com/blog/data-center/configuring-windows-server-8-d… --- Continuing on that webpage... Time to enable dedup. There is a temp disk D: so lets enable there. Method 1... I did this and then went to method 2... Start PowerShell, type: "Enable-DedupVolume D:" Method 2... in that same Dashboard, hit the 4th button (File and Storage Services) Then Volumes --> Disks click Volume 1 at the top, and then right click D: at the bottom --> Configure Dedup. To try and accelerate this puppy, I set the "age to dedup" to 0 days. http://www.techrepublic.com/blog/data-center/windows-server-2012-deduplicat… --- Time to make something to dedup. We'll just duplicate the warning.txt file that exists on D: In powershell: PS> D: PS> $file = Get-Content DATALOSS_WARNING_README.txt Then, do these 2 commands a bunch of times until "big.txt" gets to say 6MB PS> Add-Content big.txt $file PS> $file = Get-Content big.txt Then use windows explorer (or other) to make a dozen copies of big.txt Copy c:\windows\explorer.exe to D: to give it something to dedup Go to D: and then copy-paste explorer.exe a dozen times. In PowerShell, type: PS> Update-DedupStatus -Volume D: PS> Start-DedupStatus -Type Optimization -Volume D: and then wait for it to finish. you can track its progress with: PS> Get-DedupJob PS> Get-DedupStatus -Volume D: --- So, once its deduped, you check. PS> FSUTIL REPARSEPOINT QUERY big.txt you should see that its a reparse point with that 0x800etc0013 code. Copy-paste big.txt to big2.txt and check it with the query, and it should tell you big2 is NOT a reparse point. NOW you have some files to test the boost library... You can't zip them up (they lose the dedup tag), you have to run boost binaries ON the computer in the sky. --- Finish --- Thanks for reading, Paul

5 30

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

[build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
by Andrey Semashev 11 Aug '15

11 Aug '15

On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: > >> All tests for Boost.Log (and I suspect any other built libraries) on MSVC- >> 14 >> are failing because of this error: >> >> LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck >> installation of this product > > My workaround was to edit the 'Path' env variable in one of the temp files > generated by bjam (b2_msvc_14.0_vcvarsall_amd64.cmd in your temp directory) > not to point to the x64 cross compiler, but to the native one. For me this > involved changing > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86 > > To > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 I encountered the same problem with VC14 RTM on my VM. This was a clean install of VC14 RTM, there were no CTPs or RCs installed on this machine. I removed the b2_msvc_14.0_vcvarsall*.cmd scripts and ran b2 with address-model=64 to build my tests so that these scripts are re-created from scratch, so it looks like there is a problem with how these scripts are generated by b2. I found 3 instances of mspdb140.dll on my system in these locations: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64 The last two are for 32 and 64-bit native compilers. The first one, I assume, is for use by IDE. The problem is that the first path is listed in b2_msvc_14.0_vcvarsall_x86_amd64.cmd in the "SET Path=..." line prior to the compiler-specific paths. Removing it from the Path solved the problem. Could Boost.Build be adjusted so that the cmd files are generated correctly in the first place?

9 25

Broken links in 1.58.0 release notes
by Jonathan Wakely 04 Aug '15

04 Aug '15

At http://www.boost.org/users/history/version_1_58_0.html the release notes on the breaking change for Variant say "See get.hpp and polymorphic_get.hpp descriptions for more info" but both hyperlinks are broken.

2 1

Review Request: QVM (generic Quaternion, Vector and Matrix operations library)
by Emil Dotchevski 04 Aug '15

04 Aug '15

Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Online documentation and a link to download the source code under the Boost license is available at http://www.revergestudios.com/boost-qvm/. I would like to thank Adam Wulkiewicz for volunteering to be the review manager for QVM and for his valuable initial feedback. Thanks, Emil Dotchevski

13 30

BOOST_NO_CXX11_CONSTEXPR and msvc-14.0
by Peter Dimov 04 Aug '15

04 Aug '15

I see that BOOST_NO_CXX11_CONSTEXPR is no longer being defined for msvc-14.0. Even the RTM version has spotty support for constexpr though; the techniques in my metaprogramming article, for example, don't work. One simple example that fails is #include <type_traits> template< int I > struct X { }; template<class... T> constexpr int f( T... t ) { return 1; } template< class... T > struct Y: X< f(std::is_same<T, void>::value...) > { }; Y<void, void, void> y; int main() { } Another is #include <type_traits> template< class... T > struct X { static constexpr bool v[] = { std::is_same<T, void>::value... }; }; int main() { }

15 32

[serialization] Errors when testing withe mingw-64/gcc on Windows
by Edward Diener 04 Aug '15

04 Aug '15

When running serialization tests with mingw-64/gcc on Windows I get repeated errors of the form: ..\..\../boost/archive/detail/basic_oarchive.hpp:64:5: error: function 'boost::archive::detail::helper_collection& boost::archive::detail::basic_oarchive::get_helper_collection()' definition is marked dllimport get_helper_collection(){ Is this a known problem ? Testing with VC++ does not give any errors.

2 5

Boost 1_59_0_b1_rc1 is available for testing
by Marshall Clow 02 Aug '15

02 Aug '15

Release candidate files for 1.59.0 beta 1 are available at http://boost.cowic.de/rc/ 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_b1_rc1.7z) = f54a97e5ee7f8e3d04cd9af8396e30f9 MD5 (boost_1_59_0_b1_rc1.tar.bz2) = 9804305aae0c9de9f8cfc02e3de75167 MD5 (boost_1_59_0_b1_rc1.tar.gz) = e584770bd76885c123a0426d24466fe2 MD5 (boost_1_59_0_b1_rc1.zip) = ee34f223aa789a6b3f727cb9480651ed Thanks! -- The release managers

13 14

Boost 1.53 Libraries for Android
by Ian Calegory 31 Jul '15

31 Jul '15

I've compiled and made available for download the Boost C++ 1.53 Libraries for Android. This enables cross platform code in C++ that uses the Boost libraries. It is especially useful for Embarcadero's FireMonkey environment in RAD Studio, where cross platform code written in C++ can run on Windows, Android, Mac OS X, and iOS. Conceivably, cross platform code can be written using the Boost libraries that can run on all of the aforementioned environments. (The other platform libraries would have to be available, of course, and RAD Studio comes with Boost pre-compiled for Windows; Boost of course is widely available for Mac OS X.) Here is my web page where the include files and .a library files (one file for each of the four main Android architectures) is available for download: http://www.mandelmania.net/boost.html Any comments welcome. logo final small 11 Ian Calegory Software Engineer <mailto:ianc102002@yahoo.com> ianc102002(a)yahoo.com <http://www.mandelmania.net/> http://www.mandelmania.net

1 0

devector feedback request
by Benedek Thaler 30 Jul '15

30 Jul '15

Dear Boost, I'm happy to announce the new devector container developed as part of the GSoC programme reached a presentable state. I invite you to take a look and ask for feedback. Main features: - every std::vector feature - front operations with amortized linear complexity - optional small buffer optimization - customizable growth policy (see the docs) - unsafe methods for the brave and performance addicts Documentation: - Intro: http://erenon.hu/container/container/non_standard_containers.html#container… - Usage: http://erenon.hu/container/container/examples.html#container.examples.devec… - API: http://erenon.hu/container/boost/container/devector.html#idp86138944 Code: - Implementation: https://github.com/erenon/container/blob/devector/include/boost/container/d… - Tests: https://github.com/erenon/container/blob/devector/test/devector_test.cpp Thanks, Benedek

6 11

[Log] Running in a separate thread
by Andrew Hundt 29 Jul '15

29 Jul '15

I really only need some of the functionality of BOOST_LOG_TRIVIAL, perhaps plus loving to a file in addition to the console. However, my only true need is that all the work (or as much as possible) must be done in a separate thread so as not to slow the current thread down. Right now when I use BOOST_LOG_TRIVIAL as is it causes latency in my network communications which have soft realtime requirements so I've had to comment all of my logs out. Is there a straightforward non-intrusive solution to having as much of the work as possible for boost.log be done in a separate thread? Thanks for your help! Cheers! Andrew Hundt

3 4

Boost.DLL formal review result
by Vladimir Prus 28 Jul '15

28 Jul '15

The Boost.DLL library is accepted. Congratulations to Antony, and thanks for everybody who reviewed the library! The votes were as follows: - Ralf Globisch - Yes - Klaim - Joël Lamotte - Yes - Niall Douglas - Yes, conditionally - John P Fletcher - Yes - Bjorn Reese - Yes - Edward Diener - Yes - Rodrigo Madera - Yes - Richard - Yes I'd like to also thank Thomas Trummer, Rob Stewart and Ion Gaztañaga for their contribution to review. The key suggestions from the review are listed below. None is critical enough to become a formal prerequisite, or require a mini-review. The library can be added when Antony feels its ready. Naming ----------- There was a concern that "DLL" might sound windows specific, and search for best terminology. This does not seem all that important, as soon as documentation introduces the terminology it uses, and is consistent. OSX support ------------------- The library was found not to work on OSX; I believe this issue was already fixed off-list with help from Rodrigo. Documentation ---------------------- Several people requested improvements. Bjorn and John, in particular, pointed out specific issues. This seems to be the post important change prior to adding the library. Dependencies on Boost and system headers ---------------------------------------------------------------- It was suggested that the library does not depend on other Boost C++ Libraries. While it might be helpful to some users, I find it logically impossible for a Boost formal review to request that dependencies on Boost libraries be removed. It was also mentioned that Boost.DLL is header-only library and includes system headers that can bring a lot of symbols and maybe macros. I don't think an actual problem was reported, though, and there is no way to avoid the problem while staying header-only. It's up to the author to consider these suggestions and do something, or don't do anything. Continuous integration -------------------------------- There was a recommendation from Niall to improve CI of the library, including static analysis, valgrind, Windows CI, showing CI status in documentation and so forth. These are good suggestions. At the same time, they are not specific to Boost.DLL, and it's not the goal of a formal review to create new generic development process requirements. Many existing libraries of indisputably high quality do not have these requested mechanisms. Therefore, the author can act on these suggestions as he sees fit. Thanks, -- Vladimir Prus http://vladimirprus.com

4 3

BGL pull requests
by Mads Jensen 27 Jul '15

27 Jul '15

Hi, There are many quite trivial pull requests on Github for BGL. Can the project responsible please have a look at them? Most of them just fix typos and add more clarity to the documentation. Thank you, -- Med venlig hilsen / Kind regards, Mads Jensen Gunnery Sergeant Hartman: What's your excuse? Private Cowboy: Sir, excuse for what, sir? Gunnery Sergeant Hartman: I'm asking the fucking questions here, private! Do you understand? -- Full Metal Jacket

6 8

[mpl] Problem with VC++14 and boost::mpl::size_t
by Edward Diener 27 Jul '15

27 Jul '15

The just released VC++14 has a problem with the boost::mpl::size_t template. After preprocessing it sees: namespace boost { namespace mpl { template< std::size_t N > struct size_t { static const std::size_t value = N; typedef size_t type; typedef std::size_t value_type; typedef integral_c_tag tag; typedef boost::mpl::size_t< static_cast<std::size_t>((value + 1)) > next; typedef boost::mpl::size_t< static_cast<std::size_t>((value - 1)) > prior; operator std::size_t() const { return static_cast<std::size_t>(this->value); } }; template< std::size_t N > std::size_t const boost::mpl::size_t< N >::value; }} and gives the error message: size_t.cpp(nnn): error C2872: 'size_t': ambiguous symbol predefined C++ types (compiler internal)(16): note: could be 'unsigned int size_t' size_t.cpp(nnn): note: or 'boost::mpl::size_t' pointing to the line after it encounters 'struct size_t' as far as I can make out ( you need to preprocess the size_t.cpp test, comment out the #line directives and run the test against the preprocessed result to see what the compiler is objecting to ). It therefore fails a number of mpl tests which all prior versions of VC++ pass. It flags this error in 5 mpl tests which use the boost::mpl::size_t integral wrapper, among which the easiest to analyze is the size_t.cpp test itself. Anybody have any idea what is going on here with the compiler, or whether it can be fixed somehow in VC++14 for the mpl code ?

9 21

[config] BOOST_NO_CXX11_HDR_CODECVT is not defined for VC14
by Andrey Semashev 27 Jul '15

27 Jul '15

Hi, I see that BOOST_NO_CXX11_HDR_CODECVT is not defined for MSVC-14, although it is known that the codecvt facets are unusable because of linkin errors: https://connect.microsoft.com/VisualStudio/feedback/details/1348277/link-er… You can also see STL mentioning DevDiv#1060849 here: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studio-2015-previe… and I can see that the problem is not fixed in RTM. This also concerns std::codecvt specializations for char16_t and char32_t. Can we define the BOOST_NO_CXX11_HDR_CODECVT macro for MSVC?

3 6

[predef] Fails on Intel/win
by John Maddock 27 Jul '15

27 Jul '15

BOOST_COMP_INTEL is set to 0, which means that [ predef-require "BOOST_COMP_INTEL" ] fails. __INTEL_COMPILER is set to 1500. BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) ) Thanks, John.

6 17

__NR_eventfd syscall
by Alexey Brodkin 27 Jul '15

27 Jul '15

Hi, When building Boost for ARC architecture we're seeing this failure: --------------------->8--------------------- ./boost/asio/detail/impl/eventfd_select_interrupter.ipp: In member function 'void boost::asio::detail::eventfd_select_interrupter::open_descriptors()': ./boost/asio/detail/impl/eventfd_select_interrupter.ipp:50:50: error: '__NR_eventfd' was not declared in this scope write_descriptor_ = read_descriptor_ = syscall(__NR_eventfd, 0); --------------------->8--------------------- This happens clearly because ARC following Linux kernel's UAPI doesn't define __NR_eventfd syscall. If you look here https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/unis… you may notice that "eventfd" syscall with some others resides in "#ifdef__ARCH_WANT_SYSCALL_NO_FLAGS". And from what I may see only "score" architecture has this __ARCH_WANT_SYSCALL_NO_FLAGS defined. Most of other arches that don't use unistd.h from "include/uapi/asm-genereic" folder have "eventfd" syscall defined. For example it's true for ARM (both 32 and 64 versions). So I'd say it's not the best way to use directly a syscall that's being obsoleted in "Boost". And so real fix would be to modify Boost's "eventfd_select_interrupter::open_descriptors()" for example with use of really generic "eventfd2" or even better use libc's eventfd() call instead of direct syscall. Any thoughts what would be the best fix here? -Alexey

1 1

[ublas] [1.5.9.0b1] Merge patch for broken boost::numeric::ublas::shallow_array_adaptor since 1.58
by Hugues Malphettes 24 Jul '15

24 Jul '15

Hi everyone, Does somebody knows how to proceed to merge the patch filed here: https://svn.boost.org/trac/boost/ticket/11207 I am forced to remain on 1.57 because of this issue. At the minimum there are 4 projects affected: myself, Mark Moll who filed the issue on track and nasosi and vh4n who filed the same patch here: https://github.com/uBLAS/ublas/pull/30/files I had convinced myself that because it had been merged in github we would be good to go for 1.59. I just tested 1.59.0b1 and it has not been merged. Many thanks for your help! Hugues

1 0

Test Runner Update to vc14.0 - CTP 6
by Tom Kent 23 Jul '15

23 Jul '15

Just a heads up, I have just updated the test runner teeks99-08f-win2012R2-64on64 from vc14.0 - CTP 4 to vc14.0 - CTP 6. The change should show up in the next run of that runner in a few hours. I think some people were waiting to see if MS was fixing some things, so I thought I'd send a message letting people know these results would be available. Tom

7 22

Genetics library: Volunteers needed
by Andy Thomason 23 Jul '15

23 Jul '15

Hi All, I am recruiting users for the putative genetics library. https://github.com/andy-thomason/genetics We have a few simple examples of gene searching and I am working on a more complete aligner example and some performance improvements to the index data structure. For data, you can obtain the human genome from: ftp://ftp.ensembl.org/pub/release-81/fasta/homo_sapiens/dna/Homo_sapiens.GR… Interesting problems we would like to solve: Given a 20 character sequence with up to six errors, what is the fastest way to list all possibilities other than a brute force search (CRISPR). Can we use JNI to connect the library to Hadoop and other distributed seach systems? Can we construct a database of all known viral genomes including recombination? Can we detect variations in MHC VDJ regions within a single sample? Many other interesting puzzles are there to be found... Andy. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

4 4

Trouble with Boost.Test on ESXi
by William Winder 23 Jul '15

23 Jul '15

I'm using Boost.Test and Boost v1.55 to unit test an application on Windows/Linux/ESXi. The ESXi build is done on a CentOS 5.10 machine, this has been working well for the main application, but the Boost.Test binary hits an assert before running any tests: /tmp # ./MyTests Test setup error: system_error produced by: ::sigaltstack( 0, &sigstk ) != -1: Function not implemented The "Function not implemented" problem has been a recurring problem for me while making my application compatible with ESXi. My basic understanding is that ESXi implements a subset of glibc. I saw a similar issue here: http://comments.gmane.org/gmane.comp.lib.boost.testing/7782 I'm wondering how I can disable this assert and what the repercussions would be. Thanks

2 1

Re: [boost] Genetics Library:Volunteers Needed
by Mudit Sharma 23 Jul '15

23 Jul '15

Hi! I am deeply interested in volunteering for genetics library in Boost. I have sound knowledge of boost libraries. Note:This project can help me personally. Thanks! M

1 0

gcc 5.1/6.0 warnings with smart_ptr
by Gennadiy Rozental 23 Jul '15

23 Jul '15

Hi, There are bunch of warnings like these: ../boost/smart_ptr/shared_ptr.hpp:249:65: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] Any chance we can shut these down? Maybe update toolset config? Gennadiy

1 0

[boost.test] Assertion/crash
by Philip Bennefall 23 Jul '15

23 Jul '15

Hi all, I am having an issue where boost.test is triggering an assert when I make a BOOST_REQUIRE_EQUAL check. It always gives me the same assert. I am on Windows 7 with Visual C++ 2013, compiling a 32 bit application. This error happens both with boost_1_57_0 and boost_1_58_0. The assert says: Debug Assertion Failed! Program: C:\Windows\system32\MSVCP120D.dll File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xstring Line: 168 Expression: string iterator + offset out of range Here's the stack: 0041ef44 0149ca07 015c08f0 015c07e0 000000a8 MSVCP120D!std::_Debug_message+0x26 0041ef60 0149ca93 00000053 0041ef80 0041efa0 my_tests!std::_String_const_iterator<std::_String_val<std::_Simple_types<char> > >::operator+=+0x77 0041ef70 0149c91e 00000053 d4f524ac 07d2cff0 my_tests!std::_String_iterator<std::_String_val<std::_Simple_types<char> > >::operator+=+0x13 0041efa0 0149be76 0041efb4 00000053 d4f524ec my_tests!std::_String_iterator<std::_String_val<std::_Simple_types<char> > >::operator++0x4e 0041efe0 0149bdf6 0041f100 07d2ef28 07d2ef7b my_tests!std::_Transform1<char *,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x46 0041f034 0149c1b1 0041f100 07d2ef28 07d2ef7b my_tests!std::_Transform1<char *,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x96 0041f0c8 0149b5bf 0041f100 07d2cff0 0041f0e0 my_tests!std::transform<std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x191 0041f148 0149d6e2 0041f18c 00000000 015c0d18 my_tests!boost::unit_test::unit_test_log_t::operator<<+0x10f 0041f2c8 014315dc 0041f320 0041f3f4 015aa770 my_tests!boost::test_tools::tt_detail::check_impl+0x372 0041f364 01404626 00000000 0041f3f4 015aa770 my_tests!boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd,int,enum my_error_codes>+0xec 0041f458 014050af 000d7550 d4f53c34 00000000 my_tests!basic_operations::playback_decoders::pull_samples+0x146 0041f738 014053e6 015b223c 015b2234 00000000 my_tests!basic_operations::playback_decoders::iteration+0x8cf 0041f758 01405451 d4f53c70 cccccccc cccccccc my_tests!basic_operations::playback_decoders::playback_decoders_mono::test_method+0x26 0041f77c 014399d1 00000000 cccccccc 0041f7a3 my_tests!basic_operations::playback_decoders::playback_decoders_mono_invoker+0x51 0041f790 0148a54f 0041f7cf 076ecff4 00cccccc my_tests!boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (__cdecl*)(void)>+0x21 0041f7a8 01522cc5 0041f7cf 078c4ff0 076ecff0 my_tests!boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (__cdecl*)(void)>::invoke+0x2f 0041f7bc 01522ce7 0041f7cf 0a66aff4 00000000 my_tests!boost::unit_test::callback0<boost::unit_test::ut_detail::unused>::operator()+0x25 0041f7d0 01522a1f 0041f7ef 0041f7f0 01522dbd my_tests!boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> >::operator()+0x17 0041f7dc 01522dbd 0a66aff4 0a66aff0 0041f918 my_tests!boost::unit_test::ut_detail::invoker<int>::invoke<boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >+0xf 0041f7f0 01521e31 0041f918 0a66aff0 0041f810 my_tests!boost::unit_test::ut_detail::callback0_impl_t<int,boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke+0x1d 0041f800 01521b6e 0041f814 538d1e44 0041f87c my_tests!boost::unit_test::callback0<int>::operator()+0x21 0041f810 01521312 01620790 0041f918 d4f53370 my_tests!boost::detail::do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>,boost::unit_test::callback0<int> >+0x3e 0041f87c 01520dc4 0041f918 d4f533f0 00000000 my_tests!boost::execution_monitor::catch_signals+0xd2 0041f8fc 0152259d 0041f918 d4f53268 00000000 my_tests!boost::execution_monitor::execute+0x54 0041f964 014b6723 078c4fa8 d4f5316c 01574668 my_tests!boost::unit_test::unit_test_monitor_t::execute_and_translate+0xad 0041fa60 014a2565 078c4fa8 0041fa7c 014a259a my_tests!boost::unit_test::framework_impl::visit+0x3c3 0041fa6c 014a259a 078c4fa8 01620750 0041fb38 my_tests!boost::unit_test::traverse_test_tree+0x25 0041fa7c 014a22b2 00010040 01620750 d4f53034 my_tests!boost::unit_test::traverse_test_tree+0x2a 0041fb38 014a25b5 06258fa0 01620750 0041fc04 my_tests!boost::unit_test::traverse_test_tree+0x1e2 0041fb48 014a22b2 00000004 01620750 d4f53708 my_tests!boost::unit_test::traverse_test_tree+0x45 0041fc04 014a25b5 07388f98 01620750 0041fdc0 my_tests!boost::unit_test::traverse_test_tree+0x1e2 0041fc14 014a9ccb 00000001 01620750 d4f536cc my_tests!boost::unit_test::traverse_test_tree+0x45 0041fdc0 014b6bc3 00000001 00000001 d4f53538 my_tests!boost::unit_test::framework::run+0x5db 0041fe34 014b6d5c 013b346d 00000001 066fafb0 my_tests!boost::unit_test::unit_test_main+0xb3 0041fe4c 014996f9 00000001 066fafb0 05f44f28 my_tests!main+0x1c 0041fe9c 0149983d 0041feb0 74e4337a 7efde000 my_tests!__tmainCRTStartup+0x199 0041fea4 74e4337a 7efde000 0041fef0 773892e2 my_tests!mainCRTStartup+0xd 0041feb0 773892e2 7efde000 74959ac7 00000000 kernel32!BaseThreadInitThunk+0x12 0041fef0 773892b5 01499830 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63 0041ff08 00000000 01499830 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36 Does anyone have any tips for things I might try? Thanks in advance for any help on this! Kind regards, Philip Bennefall

2 1

Boost release 1.59.0 beta 1 is now available from SourceForge
by Marshall Clow 22 Jul '15

22 Jul '15

Boost release 1.59.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/ For details of what's in the release, see http://www.boost.org/users/history/version_1_59_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

3 3

[container] [1.59.0b1] Behavioral (runtime) breakage with flat_xxx + ordered_unique_range + non-default comparator
by Adam Merz 21 Jul '15

21 Jul '15

I've encountered a serious behavioral breakage for code using flat_xxx in conjunction with ordered_unique_range and a non-default comparator in 1.59.0b1. Here is a small repro: #include <initializer_list> #include <algorithm> #include <functional> #include <iterator> #include <iostream> #include <boost/container/flat_set.hpp> int main() { namespace bcont = boost::container; auto const p = [](auto const& desc, auto const& s) { std::cout << desc << ": "; std::copy( s.cbegin(), s.cend(), std::ostream_iterator<int>(std::cout, " ") ); std::cout << '\n'; }; auto const r = {4, 3, 2}; bcont::flat_set<int, std::greater<int>> const s{3, 2, 1}; p("orig set", s); auto s1{s}; s1.insert(r.begin(), r.end()); p("without\tordered_unique_range (expected output)", s1); auto s2{s}; s2.insert(bcont::ordered_unique_range, r.begin(), r.end()); p("with\tordered_unique_range (erroneous output)", s2); } I've worked around this locally by rerouting the ordered_unique_range codepath to the default codepath, but this seems like a showstopper for 1.59.0 as the code's behavior has broken entirely silently. Regards, Adam Merz

2 1

Python bindings for Boost.Interprocess
by Edison Gustavo Muenz 21 Jul '15

21 Jul '15

Hi all, this is my first e-mail on the list, so please be nice, I’m new here. I have this problem in which I need to communicate between two processes, one written in C++ (it’s actually a .so) and one written in python. They need to share large arrays. I’ve searched on the internet for a way to use shared-memory in python, and the only alternative I found was POSIX IPC for Python <http://semanchuk.com/philip/posix_ipc/> (which looks good, but it is *nix only). Also, I find the Boost.Interprocess library to be a joy to use, it worked for the problem I had, so I wanted to use it. Since I didn’t find python bindings for Boost.Interprocess is it desirable to have this? I started writing some code which uses a tiny part of Boost.Interprocess that is necessary to solve my problem. It is working already. I’m asking here to know what do boost experts think about this idea, if it unreasonable or if other developers already had this need. Feedback would be greatly appreciated. Thanks, Edison Gustavo Muenz

2 1

[mpl] Updated fixes on 'master'
by Edward Diener 18 Jul '15

18 Jul '15

A number of fixes in mpl, by Bruno Dutra and Deniz Bahadir, had been tested on 'develop' for quite a long time but had not been merged to 'master' for the upcoming release. The regression tests on 'develop' had shown that the fixes were working properly and I have taken the responsibility of merging them now to 'master' for the upcoming release. I will be checking the 'master' regression tests. If there are any problems I will revert this merge but I am 99.99% certain that the changes are correct, so I take full responsibility for merging. The fixes come from Trac items so I feel that correcting these bugs is important for the upcoming release else I would not have performed the merge and the push to Boost.

1 0

[string_ref] [utility] Add string_view?
by Beman Dawes 18 Jul '15

18 Jul '15

Boost has shipped string_ref since 1.53. See www.boost.org/doc/libs/1_58_0/libs/utility/doc/html/string_ref.html In the meantime, the C++ committee has shipped a final version, named string_view, in the Library Fundamentals TS. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html#string.v… In addition to the name change, the interface in the TS more closely mimics the std::basic_string interface. I'd really like to see the final TS basic_string_view added to Boost so I can start using it now. Using basic_string_ref, and then later having to rename all uses, is less attractive. I suspect others may feel the same way. Because a Boost basic_string_view would be an implementation of a standard library TS class, and because basic_string_ref is already in Boost, it seems a min-review would be sufficient rather than a formal review. So what I'm proposing here is to create a basic_string_view branch of the utility repo, and start working on basic_string_view there. Once it is reasonably compliant with the TS and Boost doc requirements we would hold a mini-review and then merge the branch to develop, and once stable, to release. Comments? --Beman

6 8

Boost 1.57.0 WinCE support/maintenance
by Dennis Driesens 17 Jul '15

17 Jul '15

Hello, We're porting a software product, which uses boost 1.57.0 to Windows embedded compact 7 . In this context I have a few questions. What is the support /maintenance status of boost for Windows embedded compact 7? We patched boost 1.57.0, to make it build for WEC7. Is it possible to have these patches included in boost? Regards, Dennis Driesens Dennis Driesens * Sr. Software Engineer * PU Custom Systems * Dennis.Driesens(a)tomtom.com<mailto:Dennis.Driesens@tomtom.com> * +31 (0) 40 84 44793 office * www.tomtom.com<http://www.tomtom.com>

2 1

svn.boost.org wiki
by Stefan Seefeld 17 Jul '15

17 Jul '15

Hello, I have sent the following to the Boost documentation list, but since this is of broader relevance I have been asked to resend it here... The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date. * There is an entire section "Quick Access to the Boost Subversion Repository". Shouldn't that be removed entirely ? * The section "Git and Modular Boost" starts with "Boost is moving...". Isn't that conversion complete (and thus, shouldn't the docs state that clearly) ? * There are other seemingly outdated bits, but there are relatively minor... What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know. Thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin...

4 6

Master branch is open again - for bug fixes, doc updates, etc
by Marshall Clow 16 Jul '15

16 Jul '15

Now that we've shipped the 1.59.0 beta, the master branch is open again for updates. Please do not add new features, etc to the master until after the release. But bug fixes, documentation updates, etc are very welcome. Note that: * GCC 5.2 was released today * VS2015 should be out next week * Clang 3.7 branched for release this week Compatibility with these new compiler releases would be a good thing :-) -- Marshall

1 0

[Iterator][Type_Erasure] Conflicting declaration. (Fix is provided.)
by Deniz Bahadir 16 Jul '15

16 Jul '15

Hi there, I noticed a "conflicting declaration" error when developing a program which uses Boost.Program_Options and Boost.Type_Erasure. Further investigation showed me, that the conflict is actually between Boost.Iterator and Boost.Type_Erasure. A test-case which demonstrates this compiler-error is the following simple two-liner: #include <boost/type_erasure/iterator.hpp> #include <boost/iterator/iterator_adaptor.hpp> Clang is quite verbose and outputs the following: /tmp/boost-1_58/boost/iterator/iterator_adaptor.hpp:44:18: error: target of using declaration conflicts with declaration already in scope using iterators::use_default; ^ /tmp/boost-1_58/boost/iterator/iterator_adaptor.hpp:40:10: note: target of using declaration struct use_default; ^ /tmp/boost-1_58/boost/type_erasure/iterator.hpp:27:8: note: conflicting declaration struct use_default; ^ 1 error generated. The fix is actually quite simple and should be applied to Boost.Iterator. I already provided a pull-request [1] for this. I hope this fix can still make it into the upcoming 1.59 release of Boost. Best regards, Deniz Bahadir [1] https://github.com/boostorg/iterator/pull/15 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Board of Management: Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

3 2

Boost.DLL formal review is ongoing
by Vladimir Prus 16 Jul '15

16 Jul '15

The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

16 42

[afio] AFIO review postponed till Monday
by Niall Douglas 16 Jul '15

16 Jul '15

Just a quick heads up that the AFIO review is postponed till Monday to give me more time to refactor the docs to match the final API. Some quick notes on what will be presented for review, so there are no surprises: 1. I won't have the time to rewrite the code examples into C++ 1z coroutines before the review unfortunately, so you'll get a warning sign in the docs saying that is coming. The code example this matters most to is the find regex in files example as the code is very messy (full of callback handlers) without coroutines. 2. The API presented is expected to be a final API, but the implementation will be a messy conglomeration of the existing mature dispatch engine with the new lightweight future-promises. In other words, code will compile and run, but the internal engine is going to be completely replaced eventually as I debug lightweight future-promises. As lightweight future-promises is all brand new code mostly written between 12am and 4am each night since May after a work day, I don't hugely trust it enough to present you guys with an engine based on it. Just because it passes a conformance suite doesn't mean it is without quirks - plus, I discovered some surprises in the Concurrency TS about which I'll need to get some clarifications. As I mentioned though, the user facing API will be final, as promised. And it does use monads and lightweight future-promise. 3. Minimum compilers will unfortunately be GCC 4.8, clang 3.2 and VS2015. Sorry about that, lightweight monadic future-promises substantially bumped the compiler requirements, even as it is I have several GCC 4.8 specific workarounds. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[predef] The predef-check functionality is not working on the Android regression tests
by Edward Diener 15 Jul '15

15 Jul '15

I do not believe that predef-check is working at all on the Android regression tests. Predef itself appears to be working as far as the predef macro values. But attempting to use predef-check to set a <cxxflags> value is just not happening. I can attest that just setting a <cxxflags> value, outside of using predef-check, does work correctly on the Android regression tests. The failure is occurring on my VMD tests. But you can also see the failure on the predef tests also. Looking at the info_as_cpp test output at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… you can see that BOOST_COMP_CLANG > 0 and BOOST_OS_LINUX = 0. Yet if you look at the corresponding check_value test at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… you will see that the output is 'CHECK_VALUE == undefined', whereas if predef-check were actually working the output should be 'CHECK_VALUE == 1' ( or 'true' ). In all other environments predef-check is working. Maybe this failure of predef-check somehow occurs because the Android tests are a cross-compile, being done on a Unix system but targeting the Android. But for whatever reason the inability of getting predef-check to work keeps my VMD tests from adding the '-std=c++0x' option and the VMD tests all fail without that option since the variadic macro support in VMD for gcc needs C++11 support or better.

3 6

Re: [boost] [Boost-users] Boost 1_59_0_b1_rc1 is available for testing
by Marshall Clow 15 Jul '15

15 Jul '15

On Tue, Jul 14, 2015 at 9:20 PM, Gavin Lambert <gavinl(a)compacsort.com> wrote: > On 15/07/2015 14:59, Edward Diener wrote: > >> Because MPL is so central to everything it seems it is too late to get >> these fixes into 'master', have the regression tested on 'master' and >> into the upcoming release at this point. >> > > Take this with a grain of salt, since I'm not a library maintainer or > release manager, but: > > Since it's still at a beta release stage (if I'm understanding correctly), > this seems to me like the perfect time to merge bugfixes, especially ones > that have already been tested on develop. > > Part of the point of having a beta cycle is to discover these > accidentally-left-out elements and correct them. > > After we ship the beta, before the 1.59.0 release, library maintainers will have time to fix bugs that were found in the beta. -- Marshall

1 0

[foreach] use of boost_foreach_argument_dependent_lookup_hack
by Joaquin M López Muñoz 15 Jul '15

15 Jul '15

Hi, Boost.MultiIndex indices, which are not copyable, interoperate with Boost.Foreach by defining the following: template<typename SuperMeta,typename TagList> inline boost::mpl::true_* boost_foreach_is_noncopyable( boost::multi_index::detail::sequenced_index<SuperMeta,TagList>*&, boost::foreach::tag) { return 0; } Unfortunately Qt (in some configuration modes, at least), defines a macro foreach to Q_FOREACH, which produces the following problem, even if Boost.Foreach was not intended to be used: http://tinyurl.com/nq52xho My question is: would it be OK if the code above was rewritten like template<typename SuperMeta,typename TagList> inline boost::mpl::true_* boost_foreach_is_noncopyable( boost::multi_index::detail::sequenced_index<SuperMeta,TagList>*&, boost_foreach_argument_dependent_lookup_hack) { return 0; } so that "foreach" is not ever mentioned? I understand that Boost.Foreach would still not work unless the macro is not defined, but this would at least save Boost.MultiIndex, which doesn't really depend on Boost.Foreach. Thanks for your comments, Joaquín M López Muñoz Telefónica

4 12

Serializing shared_ptr fails on .template
by Jared McIntyre 15 Jul '15

15 Jul '15

I've run into an issue where VS 2013, and likely earlier versions, fail to serialize a shared_ptr because Visual Studio is choking on the use of ar.template get_helper in load() to remove ambiguity. The issue appears to replicate previous bug report here: https://svn.boost.org/trac/boost/ticket/10727 That report didn't post an example, so instead of adding a new bug, I've posted example code to that existing report. VS 2013 Boost 1.57 Jared McIntyre

3 8

[variant] Maintainer
by Antony Polukhin 15 Jul '15

15 Jul '15

Hi, I've been keeping an eye on Boost.Varinat for a few years. Since then multiple issues were closed; support for rvalues and variadic templates was added; other good things happened. Could I be promoted to an official maintainer of Variant? This will help me to react on issues faster (email notifications) which is essential. I'm also planning to add missing features from N4450 without affecting the current never-empty behaviour and without breaking existing code. -- Best regards, Antony Polukhin

27 75

Re: [boost] [Boost-users] Boost 1_59_0_b1_rc1 regression in spirit::qi
by Lee Clagett 14 Jul '15

14 Jul '15

On Tue, Jul 14, 2015 at 8:10 AM, Oswin Krause < Oswin.Krause(a)ruhr-uni-bochum.de> wrote: > Hi, > > On 2015-07-14 05:54, Marshall Clow wrote: > >> Release candidate files for 1.59.0 beta 1 are available at >> http://boost.cowic.de/rc/ [1] >> >> 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. >> > > Boost compiles fine, OS Arch Linux, x86_64. > > However, i got a regression in my software using boost::spirit::qi > > See attached the program (i guess it does not qualify minimal, but i do > not have time to trace it further), output of g++/valgrind for boost 1.58 > and for 1.59. There seems to be a signed/unsigned comparison issue and > valgrind detects a conditional jump that depends on unintialized memory. In > my code this showed up as 4 values read from the parsed file have wrong > values albeit the 200 or so other values before and after are fine. > > Best, > Oswin > > I found the issue, and issued a pull request to fix it. Joel let me know if you want a test case; a variable currently unitialized (presumably intentionally) would have to be value-initialized to make it reliably catch this particular case (and then it could suppress errors if the float is `0`). Lee

1 0

Boost.DLL Review is finished
by Vladimir Prus 14 Jul '15

14 Jul '15

Boosters, the formal review of the Boost.DLL library by Antony Polukhin is now finished. The preliminary results are as follows: The following people have provided reviews: - Ralf Globisch - Yes - Klaim - Joël Lamotte - Yes (*) - Niall Douglas - Yes, conditionally - John P Fletcher - Yes - Bjorn Reese - Yes - Edward Diener - Yes Klaim - Joël has asked that his vote is not counted until he's done trying the library for real, and there was no confirmation it's done yet. The following people have contributed, but did not provide a review - Rodrigo Madera - Thomas Trummer - Rob Stewart - Ion Gaztañaga If anybody would like to amend or clarify anything, or plans to provide additional comments during this week, please contact me off-list. I will post final review result after that. Thanks, Volodya

2 1

Boost.DLL formal review
by Vladimir Prus 14 Jul '15

14 Jul '15

The formal review of Boost.DLL library by Antony Polukhin starts today. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? This formal review has a couple of adjustments in place: - It will run for two calendar weeks, not for 10 days, as a number of people said 10 days is too little. That said, please try to submit a review during first week, so that necessary discussion can happen conveniently. - The documentation site has Google Analytics enabled, which will allow us to see which pages and navigation paths are most useful for reviewers. No personally identifiable information will be collected. I will post the data after the review is over. Thanks, Volodya

4 6

[1.59] [locale] Merge PR to fix build failures
by Andrey Semashev 13 Jul '15

13 Jul '15

Hi, I've created this pull request [1] a while ago, but it's still not merged. The PR fixes compilation on MSVC and GCC (Ubuntu) and IMO is essential for 1.59. Could someone take a look and merge it? [1] https://github.com/boostorg/locale/pull/9

1 1

[threads] Problem with lambda and tls
by Fu ji 13 Jul '15

13 Jul '15

Hello, I have a problem when I use lambda in lambda and I want to obtain thread local storage. Here is simple example: auto late_connect = wakeup_signal_notify_to_connect.connect([this](){ auto* alias_to_this = this; this->OnInvokeUpdate(); //here I can obtain thread local storage from boost auto wakeup = wakeup_signal_ptr->connect([alias_to_this]() { alias_to_this->OnInvokeUpdate(); //here I cannot obtain thread local storage from boost } });}); Between first and second of invoke OnInvokeUpdate function there was no destructor call. Someone have idei why ? If I don't use alias for this in capture list there is the same effet. Best regards

2 2

[Boost-announce] [review] Metaparse Review Result
by Christophe Henry 13 Jul '15

13 Jul '15

Hi all, First of all, the final result. Metaparse is formally unconditionally accepted into Boost. We had 11 reviews, all "Yes" votes. 2 "No" reviews based on formality were later reversed to a "Yes". The review was lively, with a general agreement that the library is very useful, the design of high quality and the documentation great. Here are some noticeable quotes which helped me take my decision: - "thank you Abel for submitting such an amazing library. The quality of the documentation and code is wonderful and it has been a pleasure to review Metaparse." (Michael Caisse) - (Design) "Of high quality. Based on the MPL paradigm, but I don't view this as a problem." (Peter Dimov) - "Part of the role of boost is to push compilers to the limit (and sometimes beyond). This library certainly has the capabilities to do so." (Roland Bock) Worth noticing is the review of Gordon Woodhull. I myself wrote a new front-end for MSM using Metaparse, and other use cases were very welcome and Gordon managed to produce one for his compile-time graph library by the end of the review, which I found impressive (for both the reviewer and the library). Thank you for investing time in this review. Another important factor for me for acceptance is how well the author is going to maintain his library. We have too many abandoned libraries. Abel went out of his way to oblige remarks and demands made by reviewers. Long before the reviews he also had obliged my many critics and demands. He also showed himself open for experiments. All this while keeping a very calm and professional tone. This is for me a very good sign of a library which will be well-maintained. Finally, there were some repeated important comments which I see as adressed to the rest of Boost that the library is targeted towards library writers. >From Peter Dimov: > - Are you knowledgeable about the problem domain? "I'm not sure if anybody is. :-)" It all depends on us, library and potential library writers to become knowledgeable about this domain and make this library move from potentially useful to very useful. We need to use it to write more cool libraries. I notice a recurring theme where Boost would be dead or on the way to doom etc etc. Some very popular Boost libraries are now part of the Standard, and so what? We need to make new ones. Metaparse is one of them. Let's build more, using it! Yes Reviews(11): Andrzej Krzemienski Bjorn Reese Gordon Woodhull Lee Clagett Louis Dionne Michael Caisse Paul A. Bristow Peter Dimov Roland Bock Edward Diener Niall Douglas I want to thank all the reviewers who invested their time in this review and those who provided some usefuls comments. I also want to thank Abel for presenting this great library. Christophe Henry Metaparse Review Manager

3 2

Re: [boost] [Boost-users] Boost.DLL formal review is ending soon - submit your reviews
by Klaim - Joël Lamotte 12 Jul '15

12 Jul '15

On 12 July 2015 at 21:24, Edward Diener <eldiener(a)tropicsoft.com> wrote: > The name of the library seems Windows specific, since DLL is the term that > Windows uses for shared libraries. Would not Boost DLM ( for dynamic > loadable modules ) or Boost Loadable Library be clearer ? If I remember correctly, there was a long discussion about the naming of the library before the majority seemed ok with DLL because it's explicitely only about loading libraries, not "modules"(which is misleading) nor "plugins" (which would require a lot more features). The name, if my memory is correct, was not particularly thought to be about the Windows context. Other libraries also already took the other names like Boost.SharedObject so it was not an option.

1 0

[msm][eUML2][metaparse] Compile time
by Christophe Henry 12 Jul '15

12 Jul '15

Michael Caisse wrote: >> >> Boost.Msm v3 also implements a new compile-time strings based front-end >> called eUML2 to demonstrate the power of the library and the conciseness >> and expressiveness it allows. >> Please have a look at the documentation: >> >> https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… >> >> > >Christophe, this is wonderful work and a great example of the usefulness >of Metaparse. Can you comment on the compile time compared to eUML? Hi Michael, sorry, I had completely forgotten this post and saw it while preparing the review results (which will be done soon). Please allow me to answer this question, with my apologies. I added in the msm3 branch a CompareFrontEnds.cpp example. It is a simple fsm with 12 transitions. I tried with gcc-4.9 and clang-3.5, using -O2 on a i7-5960X processor, suse linux 13.2. Here are the results. eUML clang 4s g++ 5s eUML2 clang 9s g++ 14s Clang is clearly much faster than g++, with about 0.5s added compile-time per transition. With g++ it does not look so good. I already noticed that compile times of most production code at work with g++ is much higher than with clang. Regards, Christophe

2 1

[Better Enums] Maps between enums and other types
by Anton Bachin 12 Jul '15

12 Jul '15

Hello, In past exchanges on this list, several people expressed a desire for bidirectional maps on enums. I've made a simple implementation [1] that relies on constexpr functions containing a switch. The switch forces case exhaustiveness checking. This method therefore requires C++14 to be truly useful. Usage is: ENUM(Channel, int, Red, Green, Blue) constexpr const char* describe(Channel channel) { switch(channel) { case Channel::Red: return "the red channel"; case Channel::Green: return "the green channel"; case Channel::Blue: return "the blue channel"; } } constexpr auto descriptions = better_enums::make_map(describe); int main() { std::cout << descriptions.from_enum(Channel::Red) << std::endl; std::cout << descriptions.to_enum("the green channel") << std::endl; } This prints the red channel Green In principle, make_map should enumerate the function by passing every possible value of Channel, and use the results to build up some lookup data structure. I am not doing that right now because I haven't found a compile-time data structure with fast enough generation to be practical. I suppose with reflective information, there are other ways to check for exhaustiveness besides using a switch. The implementation is currently inefficient (it uses a linear scan to do the reverse mapping). There is also no support for multimaps or partial maps. I could probably support the latter easily by having the function return an option type. I am not sure multimaps are a good idea at all. The only point of them would be to do a reverse mapping from multiple values to the same enum. Interested to hear any opinions. Anton [1] http://aantron.github.io/better-enums/tutorial/Maps.html

1 0

Another Problem (was RE: [type_traits] Another big update in develop)
by Fletcher, John P 11 Jul '15

11 Jul '15

A recent change on develop is breaking something in boost function: _In file included from ../../../boost/function/function_base.hpp:22:0, from ../../../boost/function/detail/prologue.hpp:17, from ../../../boost/function.hpp:24, from ../../../boost/thread/future.hpp:52, from ../../../libs/thread/src/pthread/thread.cpp:19: ../../../boost/type_traits/has_trivial_copy.hpp:47:47: error: template argument 1 is invalid This was not there yesterday. John Fletcher

3 6

Boost.Hana
by Glen Fernandes 11 Jul '15

11 Jul '15

Dear Ron, Louis, and Boost developers, The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support. I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library. Thank you again, Louis, for your work on Hana and for contributing it to Boost. I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful. I trust, but do not mandate before Hana is officially accepted into Boost, that: 1. All GitHub issues pertaining to implementation and documentation that were opened by Louis in response to review feedback (or by others, such as Vincente, that were approved by Louis) will be addressed eventually (as long as they remain relevant). I personally would ask for, but do not require for Hana's acceptance, that: 1. That Hana's non-reference documentation live outside of the source code. The presentation of Hana's documentation is great; it looks modern, is easy to browse. I am not a fan of the prose living inside hana.hpp though (API reference documentation is the only exception). 2. Louis to investigate further the possibility of a Hana core library if such can be achieved with zero overhead (instead of focusing that effort onto a separate library that provides only a subset of Hana's functionality). On the note of Hana's current support in existing C++ implementations: - While Hana is wholly only supported by clang at present, gcc is not far behind. Given the trend of language conformance, it is reasonable to expect Hana will be entirely supported in a future gcc release. - Hana targets the C++ standard (i.e. This isn't a case of targeting any compiler-vendor specific extensions) and any highly-contentious C++ language features within (e.g. This isn't something like a pre-C++11 library that uses 'export' that only builds with an EDG compiler). - The community now has expressed sufficient interest in both kinds of libraries being part of Boost: Highly portable libraries that target implementation-specific features, and maintain compatibility with even legacy compilers; standard conforming, modern, libraries that are free of the maintenance debt of ancient compiler support. - We need more libraries taking advantage of C++14 language features to drive vendor conformance. A standard may only be as potent as the C++ implementations that support support it, but when one (such as clang does) does, others will be more driven to follow suit when real (and highly desired) projects take advantage of it. My thanks to everyone that participated in Hana's review with a review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel, Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul, Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug reports. Best, Glen

7 9

[BestPracticeHandbook] Run this code online
by Krzysztof Jusiak 11 Jul '15

11 Jul '15

Hi, I've recently added a new functionality to proposed boost.di library documentation. After `try it online` the natural next step was to add `run this code` functionality like in http://en.cppreference.com/w/ or http://www.rust-lang.org/ programming language. Powered by Wandbox and CodeMirror approach, let you play with the particular example and switch between normal quick book programming listing mode and the editor/compiler mode. You can check it here: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html/di/exampl… Just click on `Run this code` button and you will be switched to the editor mode, where you would be able to edit the code and compile it online using the newest version of the library. Implementation details: https://github.com/krzysztof-jusiak/di/blob/cpp14/doc/js/run_this_code.js It's basically the same solution as `try it online`, just implemented in js instead. Additionally, it also takes the newest version of the library from github. Minimal html: <link rel="stylesheet" href="CodeMirror/lib/codemirror.css"> <link rel="stylesheet" href="CodeMirror/theme/zenburn.css"> <script src="CodeMirror/lib/codemirror.js"></script> <script src="CodeMirror/mode/clike/clike.js"></script> <script src="CodeMirror/addon/selection/active-line.js"></script> <script src="run_this_code.js"></script> <button class="TryItBtn" id="run_it_btn" onclick="show(' https://raw.githubusercontent.com/krzysztof-jusiak/di/cpp14/examples/hello_…)">Run this code!<\/button> <textarea style="display: none" id="code"></textarea> <textarea style="display: none" id="output"></textarea> <div id="code_listing"> //quick book programming listing here or anything else, which should be hidden when editor mode is enabled </div> Let me know, what do you think. Cheers, Kris

3 2

Using clang on Windows with mingw-64
by Edward Diener 11 Jul '15

11 Jul '15

This is just a heads up about testing with clang on Windows. The latest clang, when built from the latest source, is now capable on Windows of using the mingw-64/gcc RTL. Furthermore it is no longer necessary to have the mingw/mingw-64 implementation hardcoded or linked from c:\mingw. With the latest clang the executable will look for a mingw/mingw-64 implementation on the PATH, meaning that the if the implementation's 'bin' directory is on the PATH clang will find it and use its RTL. The ability of the latest clang to use mingw-64 means that clang can use the latest gcc-5.1 RTL on Windows. The mingw-64 implementation offers more up to date and better implementations of gcc than mingw. There is one "gotcha" I have found with this setup on Windows when using clang on Windows with gcc-4.9 on up. The gcc intrin.h implementation of mingw-64 for gcc-4.9 on up has a bug where if the gcc version is less than 4.9 a compiler error will occur. I have reported this to mingw-64 on their developer's mailing list but it has been ignored. Unfortunately clang still sets itself to gcc version 4.2.1. But a workaround solves the problem and that workaround is that when using clang you define '__MINGW_FORCE_SYS_INTRINS', which causes the bug in the mingw-64 intrin.h header file to not trigger. Previous versions of clang on Windows ( 3.4, 3.5, 3.6 ) of course still have the limitation of only working with mingw and needing the mingw implementation hardcoded at c:\mingw. But at least with the latest clang built from source this has changed as explained above. The Boost build clang toolset, which on Windows is really clang-linux, should continue to work with this latest change of clang.

2 2

[1.59] Boost 1.59 schedule?
by Joaquin M López Muñoz 09 Jul '15

09 Jul '15

Hi, The official release schedule at http://www.boost.org/development/index.html seems to indicate we're now really close to the first beta of Boost 1.59, yet I don't see much activity in the mailing list and, for instance, the release notes are almost empty now: https://github.com/boostorg/website/blob/master/feed/history/boost_1_59_0.q… Is this schedule still valid? Thank you, Joaquín M López Muñoz Telefónica

6 7

Problem cross-compiling boost.context for Raspberry Pi (2)
by Biddiscombe, John A. 09 Jul '15

09 Jul '15

Hello list, I am able to compile the full set of boost libraries on the Raspberry Pi, and I get all the libraries successfully built, including context and coroutine which I need. However, when I cross compile on an Ubuntu virtual machine setup for the job, all the libraries except context/coroutine are built. The problem seems to be that when cross compiling, the file "unsupported.cpp" is being pulled in (here is a verbose output showing flag I'm using) "/home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-arm/release/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp" which emanates from the jamfile boost_1_58_0/libs/context/build/Jamfile.v2 where the following alias asm_context_sources : unsupported.cpp ; is in a section marked #COMBINED Now, when I build on the pi itself, this file is not being added to the build, so it seems to me that during the bootstrap phase on the pi, different flags are being used which trigger the correct behaviour of bjam my user-config.jam looks like this using gcc : : /home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ : <compile-flags>-D__arm__ -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard ; (NB. I added -D__arm__ to see if it helps, but it does not make a difference without it). I have no knowledge of how bjam / boost.build do their things, so I do not know what to try next. It seems that I need to bootstrap the build using the flags for the pi, but built for the host so that it can generate the correct makefiles and this looks like where the problem is arising. the build process seems good apart from this wrinkle The bootstrap command I'm using is ./bootstrap.sh --with-toolset=gcc and the build appears sensible when I use ./b2 cxxflags="-D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" --layout=versioned threading=multi link=shared variant=release -j8 Performing configuration checks - 32-bit : yes - arm : yes .... etc etc Can anyone see what I'm doing wrong? (Note : With another project which depends on libpthread, I had to copy libpthread from the pi to the host and force the linker to use the pthread lib from the pi and not the host one, does bjam do something internally which might require a trick like this? - note2 - the binaries generated via this process run without error) Many thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82

4 17

Json read...segment by segment
by vijay.singh＠edisphere.com 07 Jul '15

07 Jul '15

Hi, I am using below code to read load Json file in boost::property_tree::ptree object. Function read_json(.) read all file content at a time. I want to know is there any way to read file content segment by segment. Thanks and regards, Vijay int _tmai3n(int argc, _TCHAR* argv[]) { try { std::stringstream ss; std::ifstream file("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\Inputfiles\\AI98_Test_3.json", std::ios::binary); // Make sure we have something to read. if (!file.is_open()) { throw (std::exception("Could not open file.")); } // Copy contents "as efficiently as possible". ss << file.rdbuf(); boost::property_tree::ptree pt; boost::property_tree::read_json(ss, pt); boost::property_tree::write_json("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\In putfiles\\AI98_Test_3_sprite.json", pt); } catch (boost::property_tree::json_parser_error e) { ; } //} return 0; }

4 7

Boost.Test v3 is in master
by Gennadiy Rozental 07 Jul '15

07 Jul '15

Hi, I've merged new Boost.Test into the master branch. We'll look for any regressions, but I do not expect big changes before release. Gennadiy

2 1

[test] Bug in Mingw support?
by John Maddock 07 Jul '15

07 Jul '15

The short program below passes with MSVC and GCC Linux, but fails with Mingw-x64 at runtime (the expected failures count gets ignored). This is with current develop. Any ideas? BTW the new decorator based approach does work OK, but is only supported on a tiny number of compilers as it seems to rely on the preprocessor lib using variadic macros, as opposed to Boost.Config marking them as available. Here's the program: #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(test_main, 10000); BOOST_AUTO_TEST_CASE(test_main) { BOOST_ERROR("one"); BOOST_ERROR("two"); } Thanks, John.

3 7

Boost Graph maintenance
by Oodini 07 Jul '15

07 Jul '15

Hello, I've been working on BGL for several days, and I'll probably have to work on it for a long time. The documentation is not very clear (I suspect it is outdated on some points), and as it doesn't seem complete. Also, the official maintener, Jeremiah Willcock, hasn't commited since the end of 2013. I'd like to work on the documentation, in the first time on the organization and presentation. If I amend the text later, I will need a reviewer (my english is not good enough). What would be the process ? I havn't participated to any Boost library.

5 5

Boost.Experimental Re: [variant] Maintainer
by Gottlob Frege 07 Jul '15

07 Jul '15

On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86(a)hotmail.com> wrote: > On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote: >> >> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit : >>> >>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote: >>>> >>>> I would accept Eggs.Variant without even a review (or with a minimal >>>> review) as an experimental library as part of Boost.Variant after some >>>> minimal adaptation to fit in Boost of course. >>> >>> First of, as I have already said before, Eggs.Variant is an >>> experiment. As such it is highly unstable, and I reserve the right to >>> change things in any way I see fit, with no regards for backwards >>> compatibility, maintenance, or support. I have made these kinds of >>> changes in the past, and I have more planned for the near future. I >>> think it would be unwise to make it a part of Boost, even as an >>> experimental library, until the design has fully hatched ("Eggs", get >>> it?). >> >> Agustin, this is exactly the kind of constraints of an experimental >> library. When the design is fully hatched then it moves to non >> experimental. > > > I fail to see the point in including an experimental library that changes > its interface every month into Boost, which is released every 3 months or > so. By the time you get your hands in a release, the interface of the > library has already changed. And the library as such would only exist for a > single release. > > Who would benefit from Boost packaging old snapshots of experimental > libraries? > > Perhaps you'd wish to bring back the Sandbox > (http://www.boost.org/community/sandbox.html) which has been superseded by > standalone repositories since the move to Git. > I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something. There are (at least) 2 needs that Boost tackles: 1. great libraries that solve problems for developers 2. great libraries that can turn into std:: libraries I think we are doing better on 1 than 2. I think 2 requires more experimentation (whereas 1 requires more stability). Yes I know 2 looks successful - just look at how much of boost is in C++11. But when each Boost library is brought to the committee, we have 2 choices: - make design changes before going into std - take as is Making design choices in a committee (and without experimenting) is not always a good idea. We are, in theory at least, suppose to standardize existing behaviour. Taking as is means we are accepting whatever was good enough to pass Boost review as *best*. Boost review is a high bar, but the std:: should be higher. It is common for the committee to hear/say "boost users have been using it this way for years". That is usually a good strong argument - we want/need implementation and usage experience. But saying "this works" doesn't mean something else could work better. Implementation/usage experience is most accurate when it says "this does NOT work", because then you have ruled out an option. When you say "this works", it doesn't rule out options that might work _better_. We are increasingly going with option 3: - put into std::experimental which delays the desired outcome of getting great libraries into the standard. I'd like some kind of experimental area that would help find the best possible libraries. What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right - I'd rather break boost users than std:: users. (We have and will make breaking changes in the standard library). But I understand that current users wouldn't be too happy about breaking changes _just for experimentation's sake_. And if we lost the boost user base, boost would no longer be helpful to the standard at all. (As a reasonable example of not being afraid of breaking changes: Sean Parent's Adobe Standard Library would boldly break whenever he thought something could be made better. It didn't break just for experimenting, but he wasn't afraid to make breaking changes for the better.)

6 11

[predef] Using predef-check on 'develop' problem
by Edward Diener 06 Jul '15

06 Jul '15

In a jam file I have for a run test a predef-check which looks like: run test_variadic_macro.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ; When running on QNX with the gcc version greater than 4.3 I would expect that -std=c++0x would not be added as a C++ compile parameter to the run. Yet it is being added to the run. Another test confirms that BOOST_OS_QNX is indeed being set to a non-zero value. Is there a bug in predef-check ? Am I using it incorrectly ?

4 45

Testing InputIterator on the interface
by Benedek Thaler 05 Jul '15

05 Jul '15

Hi, I'd like to verify my methods accepting an input range (two iterators modelling InputIterator) do a single pass over the range at most. I'd like to have an iterator adaptor, which erases the visited element upon incrementing. So far, I found these: 1) https://github.com/boostorg/test/blob/master/include/boost/test/utils/itera… I couldn't find its documentation, and does not seem to what I want. 2) https://github.com/boostorg/container/blob/master/test/input_from_forward_i… Despite the name, still not something I want. I'm developing a Boost.Container class [0], so using container/test would be okay. Is there such a thing ready somewhere or shall I roll my own? Thanks, Benedek [0]: https://github.com/erenon/container/blob/devector/include/boost/container/d…

2 3

Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
by Klaim - Joël Lamotte 04 Jul '15

04 Jul '15

On 4 July 2015 at 11:38, Antony Polukhin <antoshkka(a)gmail.com> wrote: > 2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: >> >> >> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >>> >>> - What's your evaluation of >>> - Design >>> >> >> I consider the solutions provided to solve each usual issue with plugin >> systems to be simple >> and clear, easy to use (as long as you understand what loading plugins >> imply). >> >> Until I check in some complex cases, I think the design is very good. >> The symbol name magic might be tricky to understand sometime but it's an >> issue which is a side effect of providing >> a simple tool to manage symbole names, so it's still good. >> >> One thing I was wondering: would it be possible to provide a way to load >> shared libraries from >> raw memory? Or does the OS APIs all requires that the library have to be >> on a file sytem? >> > > Unfortunately, there's no portable way to load libraries from raw memory. > However you can always mount a filesystem that directly maps to memory (for > example Tmpfs on Linux) and store your data in there. This may look like a > big performance overhead, but actually loading a shared library takes much > time so you won't probably notice the overhead of additional create_file + > memcpy. > It's ok, the solution to write a shared library in the the filesystem before loading it is what Ihave been doing so far and it works well. I was just wondering if it was possible with memory. :) If the plugin is in an archive file, I have to extract it in a temporary directory before loading it, which is what I would like to avoid, but it seems unavoidable. > > If you're planing this feature to write interpreters\JIT compillers and > you just need a place to store end execute generated native code, then > Boost.Interprocess's memory mapped files fill probably suit you better. > Shared libraries contain a lot of headers, helper data for load and a bunch > of other stuff that would be really hard to generate. > I don't write an interpreter (I'm really just managing plugins) but I didn't know that, it seems useful in some other contexts. Thanks for the pointer.

1 0

Fwd: [Boost-users] Boost.DLL formal review is ongoing
by Antony Polukhin 04 Jul '15

04 Jul '15

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: > > > On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >> >> - What's your evaluation of >> - Design >> > > I consider the solutions provided to solve each usual issue with plugin > systems to be simple > and clear, easy to use (as long as you understand what loading plugins > imply). > > Until I check in some complex cases, I think the design is very good. > The symbol name magic might be tricky to understand sometime but it's an > issue which is a side effect of providing > a simple tool to manage symbole names, so it's still good. > > One thing I was wondering: would it be possible to provide a way to load > shared libraries from > raw memory? Or does the OS APIs all requires that the library have to be > on a file sytem? > Unfortunately, there's no portable way to load libraries from raw memory. However you can always mount a filesystem that directly maps to memory (for example Tmpfs on Linux) and store your data in there. This may look like a big performance overhead, but actually loading a shared library takes much time so you won't probably notice the overhead of additional create_file + memcpy. If you're planing this feature to write interpreters\JIT compillers and you just need a place to store end execute generated native code, then Boost.Interprocess's memory mapped files fill probably suit you better. Shared libraries contain a lot of headers, helper data for load and a bunch of other stuff that would be really hard to generate. -- Best regards, Antony Polukhin

1 0

[next gen futures] Lightweight monad ready for inspection
by Niall Douglas 03 Jul '15

03 Jul '15

Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>. I didn't expect it would take nearly four weeks to get there, but writing STL quality C++ with full conformance test suite is amazingly labourious. Anyway you can now view the design and tell me what you think. A quick overview of the design: This monad can hold a fixed variant list of empty, a type R, a lightweight error_type or a heavier exception_type at a space cost of max(20, sizeof(R)+4). Features: * Very lightweight on build times and run times up to the point of zero execution cost and just a four byte space overhead. Requires min clang 3.2, GCC 4.7 or VS2015. A quick sample of runtime overhead, min to max opcodes generated by GCC 5.1: 1 opcodes <= Value transport <= 113 opcodes 8 opcodes <= Error transport <= 119 opcodes 22 opcodes <= Exception transport <= 214 opcodes 4 opcodes <= then() <= 154 opcodes 5 opcodes <= bind() <= 44 opcodes * Just enough monad, nothing more, nothing fancy. Replicates the future API with a fair chunk of the Expected<T> API, so if you know how to use a future you already know how to use this. * Enables convenient all-noexcept mathematically verifiable close semantic design, so why bother with Rust anymore? :) * Can replace most uses of optional<T>. * Deep integration with lightweight future-promise (i.e. async monadic programming) also in this library. * Comprehensive unit testing and validation suite. * Mirrors noexcept of type R. * Type R can have no default constructor, move nor copy. * Works inside a STL container, and type R can be a STL container. * No comparison operations nor hashing is provided, deliberately to keep things simple. Documentation page: https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1l ightweight__futures_1_1monad.html Source code: https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/monad.hpp Online wandbox compiler: http://melpon.org/wandbox/permlink/cnZM5KRNpjErXrPH Any opinions or thoughts gratefully received, particularly if I have the exception safety semantics right (i.e. a throw during move or copy leaves the monad empty). Do you also like the polymorphic bind() and map() which does different things depending on the parameter type your callable takes? Do you like that by simply changing the callable's type to a rvalue reference you can move state, or is this being too clever? This monad will become the basis of lightweight future-promise which is essentially a "split monad" with the setter interface and getter interface potentially in different system threads. The then(), bind() and map() work as here but only are triggered at the point of the value being changed. This effectively makes the lightweight future a "lazy continued monad". That lightweight future-promise will then enter AFIO to replace its async_io_op type hopefully in time for the peer review this time next month. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 42

Re: [boost] Boost.DLL formal review is ongoing
by Ralf Globisch 03 Jul '15

03 Jul '15

Hi, Firstly, thanks Anthony for submitting this useful library to boost, and to Vladimir for managing the review. - Should the library be accepted? Yes. I had been meaning to test the library for some time, and with the review reminder finally made some time to do so. My vote of yes is based on my (limited) positive experience with the library, as well as having followed past related discussions on the mailing list, in which many questions are addressed. (http://lists.boost.org/Archives/boost/2014/09/216650.php) I think boost.DLL should be accepted unless someone has a serious/valid reservation as to why this library should not to be accepted. - How useful is it? Very useful. It enabled me to add a test-plugin mechanism to an existing application (Windows and Linux) in a matter of minutes. - What's your evaluation of - Design Looks good to me. Simple to use, with good integration into rest of boost (e.g. file_system). I like the fact that the library is header only and minimal effort was required to integrate plug-in like functionality into an existing application. - Implementation I'm not knowledgeable enough to comment on this. - Documentations Good, the tutorials made it fairly easy to get going and covered my common usage scenarios Code is well commented. - How much effort did you put into your evaluation? About three hours worth of effort, reading through documentation and source code, and using library to create a very simple plug-in mechanism in an existing application. Tested basic plug-in functionality on Windows and Linux. - Did you attempt to use the library? On what systems and compilers? Yes -Linux Ubuntu 14.10 with gcc 4.9.1 with boost 1.57 -Window 7 64-bit with VS 2013 community edition with boost 1.58. Initially made the mistake of not checking the boost version (which had been 1.53 and caused lots of compilation errors.) Minor typo in documentation: Just above the "Full Sources" for tutorial 4 "If we want o make a traditional" should be "If we want to make a traditional" Regards, Ralf >>> Vladimir Prus <vladimir.prus(a)gmail.com> 07/03/15 3:52 PM >>> The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.

1 0

Metaprogramming: parameter pack expansion/evaluation trick
by Antony Polukhin 03 Jul '15

03 Jul '15

Hi, Straight to the problem. Consider the situation, were a function accepts parameter pack and something need to be done with each argument (for example, we want to print each argument on a new line): template <typename... Args> void print(Args&&... a) { // print each a on a separate line } There's a known trick to do that: template <typename... Args> void print(Args&&... a) { (void) (int []){ 0, (std::cout << a << std::endl, 0)... }; } But the syntax is not very readable (and I always forget it and search for an example in Internet). I've tried to improve the syntax, and here's the result: template<typename... Args> void print(Args&&... a) { expand_if<Args...> { std::cout << a << '\n'... }; } Compete source could be found here: http://coliru.stacked-crooked.com/view?id=c2c59f22574671e5 Here's some more usage examples: template<typename... Args> void printer_int(Args&&... args) { expand { std::cout << std::abs(args) << std::endl..., std::cout << "Printing once again all the numbers: " << std::endl, std::cout << " Once again " << std::abs(args) << std::endl..., std::cout << "EOF Printing once again all the numbers." << std::endl }; } template<typename... Args> float sum(Args&&... args) { float res = 0; expand_if<Args...> { res += args... }; return res; } I hope this would be helpful for someone or it could be used as an argument for a proposal to extend C++ and allow simpler syntax: template<typename... Args> void print(Args&&... a) { std::cout << a << '\n'...; } P.S.: There was a nicer solution that newer required "_if<Args..>" : namespace detail { struct expand_impl final { template <class... Arg> constexpr inline expand_impl(Arg&&...) noexcept {} }; } template <class... Arg> using expand = detail::expand_impl; But unfortunately there's no way to force the compiler to evaluate expressions in constructor call from left to right. So it did not work on GCC (but work on Clang). -- Best regards, Antony Polukhin

4 4

[math][website] SVG graphics all missing?
by John Maddock 03 Jul '15

03 Jul '15

It looks like all the SVG graphics used by the Boost.Math docs are missing from the website - is this a release SNAFU? Thanks, John.

1 1

[winapi] Major changes in develop
by Andrey Semashev 02 Jul '15

02 Jul '15

Hi, I've just merged a largely reworked version of Boost.WinAPI to develop. It fixes a few bugs and also changes the implementation for better conformance with the C++ standard. Hopefully, it should fix compilation issues with clang on Windows. Another significant change is that Boost.WinAPI targets Windows Vista and later by default. As before, it is possible to explicitly select another version to target by defining BOOST_USE_WINAPI_VERSION. For example, to build Boost for Windows XP one would invoke: b2 define=BOOST_USE_WINAPI_VERSION=0x0501 If anyone has problems with this change, please let me know.

2 5

[optional] How to use optional to lazy construct obj?
by Mostafa 01 Jul '15

01 Jul '15

I'm interested in doing something along the lines of: lazy_adaptor<obj_type> lz(arg1, arg2, arg3, ...) where then lz.construct() then constructs an object of obj_type with ctor of arguments "arg1, arg2, arg3, ...". So far I have the following: (Am I on the right track?) #include <utility> #include <tuple> #include <string> #include <boost/optional/optional.hpp> template <typename... Args> struct ctor_forwarder; template <typename... Args> ctor_forwarder<Args...> make_ctor_forwarder(Args&&... args) { // Note: The "Args..." template parameter to ctor_forwarder determines how // the caller's arguments are temporarily stored. If it's an rvalue, it's // temporarily stored by value, else it's temporary stored by reference. return ctor_forwarder<Args...>(std::forward<Args>(args)...); } template <typename... Args> struct ctor_forwarder { //TODO: make ctor private. template <typename... A> explicit ctor_forwarder(A&&... args) : m_args( ::std::forward<A>(args)... ) {} /* template <typename Callable> auto forward_to(Callable && caller) -> decltype( caller(::std::forward<Args>(m_args)...) ) { return caller(::std::forward<Args>(m_args)...); } */ template <typename T> void forward_to(::boost::optional<T> & obj) { obj.emplace(::std::forward<Args>(m_args)...); } private: typedef ::std::tuple<Args...> args_t; private: args_t m_args; }; template <typename Obj, typename... Args> struct lazy_adaptor { Obj on_enter() { m_args_forwarder.forward_to(m_obj); } private: ::boost::optional<Obj> m_obj; ctor_forwarder<Args...> m_args_forwarder; }; template <typename Obj, typename... Args> lazy_adaptor<Obj, Args...> make_lazy_adaptor(Args&&... args) { return lazy_adaptor<Obj, Args...>(); } struct Sample1 { Sample1(int num, std::string str) {} }; int main() { auto df = make_ctor_forwarder(10, "Ten"); //ctor_forwarder<int, std::string> df(10, "Ten"); auto lazy_ctor = make_lazy_adaptor<Sample1>(10, "Ten"); return 0; }

1 0

Fwd: [SORT] Parallel Algorithms
by Francisco José Tapia 01 Jul '15

01 Jul '15

Hi Steven I had been revising and testing spreadsort, and the results are impressive. I have prepared the benchmarks and include spreadsort. Now the numbers are extracted from a file generated with a random number generator. In a few days I will put all in a git repository for a easy access As I had seen, you use boost::sort for to invoke to spreadsort. If you use this name, which name use for to invoke introsort? I think a good idea can be call the algorithms by their name. If we do this we have the next algorithm list : - spreadsort - spreadsort_integer - spreadsort_float - spreadsort_string - introsort - parallel_introsort - smart_merge_sort - parallel_stable_sort - sample_sort I think it's a simple and easy to understand, because with the name sort, many people think about an algorithm as introsort ( general , not specific for several data types) and not stable. What's your opinion ?

3 19