- Boost - lists.preview.boost.org

[compute] [OS X 10.11.5] [GeForce GT 750M] Segmentation fault
by Prashant 25 May '16

25 May '16

Hi, Am trying to sort a vector on GPU (GeForce GT 750M) using example code which generates SEGV. However, it runs fine on Iris Pro (Intel(R) Core(TM) i7-4850HQ CPU). We observe SEGV when size is 10 million. When the size is 5 million, following exception is thrown: boost/1_61_0/include/boost/compute/command_queue.hpp(453): Throw in function boost::compute::event boost::compute::command_queue::enqueue_write_buffer(const boost::compute::buffer &, size_t, size_t, const void *, const boost::compute::wait_list &) Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector< boost::compute::opencl_error> > std::exception::what: Invalid Value Another observation: if the size of vector is 50 million the sorting works fine, though the timings are worse than Iris Pro. Also, when is size is 100 million, the binary causes the OS to crash. Compiler details: clang++ --version Apple LLVM version 7.3.0 (clang-703.0.31) Target: x86_64-apple-darwin15.5.0 Thread model: posix OS: System Version: OS X 10.11.5 (15F34) Kernel Version: Darwin 15.5.0 Regards, Prashant ----------------------------Cut here------------------------------------- #include <iostream> #include <vector> #include <algorithm> #include <boost/foreach.hpp> #include <boost/compute/core.hpp> #include <boost/compute/platform.hpp> #include <boost/compute/algorithm.hpp> #include <boost/compute/container/vector.hpp> #include <boost/compute/functional/math.hpp> #include <boost/compute/types/builtin.hpp> #include <boost/compute/function.hpp> #include <boost/chrono/include.hpp> #include <boost/exception/all.hpp> namespace compute = boost::compute; int main(int argc, char* argv[]) { if (argc != 2) { std::cout << "Usage: " << argv[0] << " <size> " << std::endl; return 0; } // generate random data on the host std::vector<float> host_vector(atoi(argv[1])); std::generate(host_vector.begin(), host_vector.end(), rand); std::cout << "===============CPU==================\n"; for (size_t k=0; k<5; k++) { std::vector<float> host_copy_vector(host_vector); auto start = std::chrono::high_resolution_clock::now(); std::sort(host_copy_vector.begin(), host_copy_vector.end()); auto duration = std::chrono::duration_cast<std::chrono::milliseconds> (std::chrono::high_resolution_clock::now() - start); std::cout << "time: iteration ("<< k << ") : " << duration.count() << " ms" << std::endl; } std::vector<compute::platform> platforms = compute::system::platforms(); for(size_t i = 0; i < platforms.size(); i++){ const compute::platform &platform = platforms[i]; std::cout << "Platform '" << platform.name() << "'" << std::endl; std::vector<compute::device> devices = platform.devices(); for(size_t j = 0; j < devices.size(); j++){ const compute::device &device = devices[j]; std::string type; if(device.type() & compute::device::gpu) type = "GPU Device"; else if(device.type() & compute::device::cpu) type = "CPU Device"; else if(device.type() & compute::device::accelerator) type = "Accelerator Device"; else type = "Unknown Device"; if (type != "GPU Device") { std::cout << "Ignoring non GPU devices.\n"; continue; } std::cout << "====\n"; std::cout << " " << type << ": " << device.name() << std::endl; std::cout << "====\n"; compute::context context(device); compute::command_queue queue(context, device); for (size_t k=0; k<5; k++) { compute::vector<float> device_vector(host_vector.size(), context); // copy data from the host to the device compute::copy( host_vector.begin(), host_vector.end(), device_vector.begin(), queue ); auto start = std::chrono::high_resolution_clock::now(); try { compute::sort(device_vector.begin(), device_vector.end(), queue); } catch (boost::exception & e) { std::cerr << diagnostic_information(e); break; } auto duration = std::chrono::duration_cast<std::chrono::milliseconds> (std::chrono::high_resolution_clock::now() - start); std::cout << "time: iteration ("<< k << ") : " << duration.count() << " ms" << std::endl; } std::cout << "====\n"; } } return 0; }

2 1

[multiprecision] compilation failure
by Raffi Enficiaud 24 May '16

24 May '16

Hi, I have the following failure on develop from multiprecision (unit tests of boost.test): In file included from writing-test-ts/fp-multiprecision-comparison-test.cpp:23:0: ../../../boost/multiprecision/cpp_dec_float.hpp: In member function ?std::size_t boost::multiprecision::backends::cpp_dec_float<Digits10, ExponentType, Allocator>::hash() const?: ../../../boost/multiprecision/cpp_dec_float.hpp:264:10: error: ?hash_combine? is not a member of ?boost? boost::hash_combine(result, data[i]); Thanks, Raffi

3 2

Request for a "Policy Review" regarding 'CMakeLists.txt'
by David Sankel 24 May '16

24 May '16

A question has been brought up regarding whether or not a Boost library author is permitted to include a 'CMakeLists.txt' file in the root of the directory. This stemmed from a discussion at C++Now 2016 which included several members of the Boost Steering Committee and a sampling of the Boost community. We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory. * Several libraries, such as Boost.Hana and Boost.Spirit, have two distribution mechanisms: one as distributed with Boost and the other as an independent package. The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution. * Several companies have revealed that they are building Boost with their own custom CMake scripts. The suggested policy change would enable authors to relieve the infrastructure cost of their CMake users and unify how their library is built. * CMake is, by far, the most popular build system for C++. Allowing authors to support CMake users in addition to BJam will help the Boost ecosystem to grow and thrive by lowering the barriers to access. -- David Sankel

51 224

Boost.Fit review Mars 3-20 result
by Vicente J. Botet Escriba 24 May '16

24 May '16

Hi, I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report. Summary ======= The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is: Conditional acceptance (a new review is needed) There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions. From the review discussion I deduce that there is some interest in the library, and that some people don't understand yet what the library is proposing. Paul has started already to take in account some if the issues raised during the review and a lot of them must be resolved before we re-try a new review. There were some discussion about the name of the library, but there were no consensus. Paul is free to change the name of his library and see how people react. On behalf of the Boost community, I would like to thank Paul Fultz for the work he has put into the Fit library so far. I encourage him to continue to evolve this library and to bring it back for a new review. We had seven 6 formal votes, and 2 more votes without a complete review abbreviated here: Steaven Watanabe: No in his current state Zach Laine : Conditinal acceptance Krzysztof Jusiak: Accepted Artyom Beilis : Rejected Peter Dimov : Accepted (no review) Manuel Sancher : Accepted (no review) Rob Stewart : Conditinal acceptance ??? Louis Dionne : Conditinal acceptance There were other people that participated on the review giving their advice respect to a specific issue. I thank each of these reviewers, and indeed everyone who invested some time participating in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. Detailed Report =============== You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Issues:https://github.com/pfultz2/Fit/issues Documentation:http://pfultz2.github.io/Fit/doc/html/ Hopping this helps, Vicente Botet Escriba

11 26

b2 looks for tools/inspect/build/Jamfile
by Peter Dimov 23 May '16

23 May '16

I'm experimenting with a partial Boost clone, the superproject, tools/build, libs/bind, libs/config and few others, and when trying to build the tests, I'm getting the following error: D:\tmp\boost\libs\bind\test>..\..\..\b2 toolset=msvc-10.0 D:/tmp/boost/tools/build/src/build\project.jam:262: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../../../tools/inspect/build'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'http://www.boost.org'. D:/tmp/boost/tools/build/src/build\project.jam:280: in load-jamfile from module project D:/tmp/boost/tools/build/src/build\project.jam:64: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:89: in load-used-projects from mo dule project D:/tmp/boost/tools/build/src/build\project.jam:75: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:113: in load-parent from module p roject D:/tmp/boost/tools/build/src/build\project.jam:464: in initialize from module pr oject D:/tmp/boost/tools/build/src/build\project.jam:306: in load-jamfile from module project D:/tmp/boost/tools/build/src/build\project.jam:64: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:113: in load-parent from module p roject D:/tmp/boost/tools/build/src/build\project.jam:464: in initialize from module pr oject D:/tmp/boost/tools/build/src/build\project.jam:306: in load-jamfile from module project D:/tmp/boost/tools/build/src/build\project.jam:64: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:145: in project.find from module project D:/tmp/boost/tools/build/src\build-system.jam:535: in load from module build-sys tem D:\tmp\boost\tools\build\src/kernel\modules.jam:295: in import from module modul es D:\tmp\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from modul e D:\tmp\boost\boost-build.jam:17: in module scope from module Does anyone have an idea why b2 looks for the tools/inspect Jamfile? I don't remember this being a problem before when I tried a stripped-down installation.

6 14

doctest - the lightest feature rich C++ single header testing framework - if it can enter boost and if it/boost will benefit from that
by Viktor Kirilov 23 May '16

23 May '16

Hello! I just released doctest - https://github.com/onqtam/doctest All the info about it can be found on github. So do you think it can enter the boost project? How much work will it take to get it into boost except for adding boost in the title? Will it or boost benefit from that addition? Also I've sort-of followed the Best Practice Handbook (I consider it very valuable) as much as possible - https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook Any feedback will be greatly appreciated. Thanks!

10 19

Rebooting Boost: Call for Lightning Talks @ CppCon
by Niall Douglas 23 May '16

23 May '16

At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; lack of ABI management and the consequent ODR violation when mixing Boost versions in the same process; the anti-social behaviour of Boost towards library end users, new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries. One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" Please keep each talk topic focused on a single design pattern, practice or idiom (see suggested talk format below). Each speaker may submit up to THREE talk topics (not all may be accepted if there are a lack of slots, so please rank them in order of preference). Please send your talk topics to me privately by email, only if sufficient numbers present to fill a session will your name and your talk topic be shared with the CppCon Programme Committee. We'll try to arrange a short panel session at the end so attendees can ask questions of the speakers. After the lightning talk we'll arrange a restaurant so all the speakers and any interested attendees can dine together, followed by a night in a Bellevue bar. If after the dust has settled it is felt there is a critical mass sufficient to reboot a brand shiny new edition of Boost, we'll start development! I should *stress* that it is up to the CppCon Programme Committee whether these lightning talks are approved or not. I'll just copy and paste your proposed talk to the CppCon PC as-is. If insufficient lightning talk topics are received by me to fill a 60 minute session, I'll withdraw this talk proposal from CppCon. Suggested talk format ================ Five minutes is not much time, so here is a suggested lightning talk outline: 1. A current widely practiced library design pattern (show example). 2. The problems it generates for library users or maintainers. 3. Your proposed alternative design pattern (show example). 4. The problems the alternative design pattern fixes. 5. Any mockup, prototype or even live demo (!) of the alternative design pattern in action. Suggested talk themes might be documentation, packaging, distribution, testing, tooling, quality assessment, barriers to entry, governance, strategy, important gaps in the standard libraries, automation and deprecation/removal policies. Here is an example of such a lightning talk: 1. Current design pattern: Library v1.00: namespace boost { namespace lib { void foo(size_t, char); } } User code: boost::lib::foo(100, 'n'); 2. Problem: Library v1.01: namespace boost { namespace lib { void foo(char, size_t); } } User code: boost::lib::foo(100, 'n'); // oh oh! 3. Alternative: Library v1.00: namespace boost { namespace lib { inline namespace v100 { void foo(size_t, char); } } } #define BOOST_LIB_NAMESPACE_V100 boost::lib::v100 Library v1.01: namespace boost { namespace lib { inline namespace v101 { void foo(char, size_t); } } } #define BOOST_LIB_NAMESPACE_V101 boost::lib::v101 User code: // Mount v100 of Boost.Lib into "lib" namespace lib=BOOST_LIB_NAMESPACE_V100; lib::foo(100, 'n'); // ABI stable! No ODR violation possible! 4. Problems fixed: a) Mixing incompatible versions of individual Boost libraries in the same process (or even translation unit) is now safe. b) Libraries can now depend on other libraries without worrying about breaking code which depends on them which uses a different version of the same dependency. This greatly helps reduce change ripple effects. c) Forward compatibility or alternative implementation shims are now very easy to implement e.g. library users can externally configure either Boost.Filesystem or std::experimental::filesystem for your library to use, your code simply refers to _some_ Filesystem TS implementation e.g. namespace filesystem = FILESYSTEM_TS_IMPLEMENTATION; filesystem::path mypath; -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 10

@boost-admins: permission to git-repo removed?!
by Oliver Kowalke 23 May '16

23 May '16

Hi, I can't push commits to git-repo boost.coroutine2: remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/boostorg/coroutine2/' Could you please re-add user 'olk', please. thx, Oliver

3 3

What C++14/1z standard or TS libraries would you like to have available on a C++11 compiler?
by Vicente J. Botet Escriba 23 May '16

23 May '16

Hi, I would like to have your feedback on C++ standard library features you would like to have available for a C++11 compiler. The idea would be to present a Boost.StdExtensions library that would provide some of these features for review with some of these features. Please , let me know if you are interested in participating in this project and working on some specific parts. This library should avoid as much Boost dependencies as possible. How the library could be structured? I believe that it should follow the C++ standard files. Which folder should be used? boost/stdext? boost/stdext11? Which namespace? boost::stdext? I have prefixed with a * the lines that interest myself and with VBE* those that I could work on. The features that need compiler help or that need C++14/17 language features are excluded and prefixed by N/A. Please be free to add a * if you are interested and your name as well if you want to participate. Best, Vicente P.S. The project could be as well extended to C++98 compilers with C++11 standard libraries (But I would not have time to invest in). P.S.S. I would also be interested in extend the project to extended to C++14 compilers. C++14 standard libraries ================ VBE* N3658 - Compile-time integer sequences * N3654 - Quoted Strings N3656 - make_unique VBE* N3462 - std::result_of and SFINAE * N3668 std::exchange() N3469 Constexpr Library Additions: chrono N3470 Constexpr Library Additions: containers N3471 Constexpr Library Additions: utilities N3302 Constexpr Library Additions: complex VBE* N3545 An Incremental Improvement to integral_constant N3644 Null Forward Iterators N3670 Addressing Tuples by Type N3671 Making non-modifying sequence operations more robust N3642 User-defined Literals VBE* N3655 TransformationTraits Redux (excluding part 4) N3657 Adding heterogeneous comparison lookup to associative containers N3669 Fixing constexpr member functions without const N3659 Shared Locking in C++ N3779 User-defined Literals for std::complex N3789 Constexpr Library Additions: functional N3887 Consistent Metafunction Aliases N3891 A proposal to rename shared_mutex to shared_timed_mutex C++1z standard libraries ================ VBE* N3911 TransformationTrait Alias void_t N4089 Safe conversions in unique_ptr<T[]> VBE* N4169 A proposal to add invoke function template N4258 Cleaning-up noexcept in the Library. N4277 TriviallyCopyable reference_wrapper. N4279 Improved insertion interface for unique-key maps. VBE* N4280 Non-member size() and more N4284 Contiguous Iterators. N4387 improving pair and tuple VBE* N4389 bool_constant N4508 shared_mutex for C++17 N4366 LWG 2228 missing SFINAE rule N4510 Minimal incomplete type support for standard containers N/A* P0006R0 Adopt Type Traits Variable Templates for C++17. VBE* P0092R1 Polishing <chrono> VBE* P0007R1 Constant View: A proposal for a std::as_const helper function template. VBE* P0156R0 Variadic lock_guard(rev 3). P0074R0 Making std::owner_less more flexible VBE* P0013R1 Logical type traits rev 2 P0024R2 The Parallelism TS Should be Standardized P0226R1 Mathematical Special Functions for C++17 VBE* P0220R1 Adopt Library Fundamentals V1 TS Components for C++17 P0218R1 Adopt the File System TS for C++17 P0033R1 Re-enabling shared_from_this VBE* P0005R4 Adopt not_fn from Library Fundamentals 2 for C++17 P0152R1 constexpr atomic::is_always_lock_free N/A* P0185R1 Adding [nothrow-]swappable traits P0253R1 Fixing a design mistake in the searchers interface P0025R0 An algorithm to "clamp" a value between a pair of boundary values P0154R1 constexpr std::hardware_{constructive,destructive}_interference_size P0030R1 Proposal to Introduce a 3-Argument Overload to std::hypot P0031R0 A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access P0272R1 Give std::string a non-const .data() member function VBE* P0077R2 is_callable, the missing INVOKE related trait Fundamental V1 TS ============ Uses-allocator construction Changes to std::shared_ptr and weak_ptr Additions to std::function Additions to std::promise Additions to std::packaged_task Class erased_type VBE* Calling a function with a tuple of arguments N/A Type traits (_v) Other type transformations Compile-time Rational Arithmetic Time Utilities System Error Support Class memory_resource Class template polymorphic_allocator Template alias resource_adaptor Global memory resources Pool resource classes Class monotonic_buffer_resource Alias templates using polymorphic memory resource Searchers * Optional Objects Initial implementation * class any * string_view memory Algorithms library

6 8

Boost 1.61.0 has been released
by Rene Rivera 22 May '16

22 May '16

Release 1.61.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains four new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries * Compute: Parallel/GPU-computing library, from Kyle Lutz. * DLL: Library for comfortable work with DLL and DSO, from Renato Tegon Forti and Antony Polukhin * Hana: A modern C++ metaprogramming library, from Louis Dionne. * Metaparse: A library for generating compile time parsers parsing embedded DSL code as part of the C++ compilation process, from Abel Sinkovics. For details, including download links, see http://www.boost.org/users/news/version_1.61.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.61.0/ Tom Kent has made pre-built windows binaries, and they are available at: https://sourceforge.net/projects/boost/files/boost-binaries/1.61.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

11 18

Boost Evolution
by Robert Ramey 21 May '16

21 May '16

What I would like to see is more encouragement for the idea of boost evolution. But I have well defined ideas about how that should occur. I articulated these ideas is quite a bit of detail at C++Now in 2015 to a packed house. It wasn't recorded so you'll have to take my word for it. All is not lost though. For those who might be interested I kept my practice recordings for the narrative on the slides and attached them to each slide. So you can get a good feeling for the presentation by checking out http://www.blincubator.com/C++Now2015/index.html If you do this don't forget to checkout the last two slides (including the audio)! in real life it was much better!!! When I articulated my particular suggestions at the conference there was a lot of push back and I sort of lost control of things. On the other hand, there was a lot of enthusiasm for my "call to action". I didn't expect any drastic changes. But as I look back a year I do see some real progress. I see: a) more and better reviews b) more interest, discussion and criticism of documentation c) 30 libraries in the incubator. Some have already been added to boost. d) Now movement on opening up the build/test system to evolution. e) A program in place to make more resources available for maintaining existing libraries. The complains of unmaintained libraries have diminished by quite a bit - I don't know for a fact that this is related to this program - maybe it's just a happy coincidence. A couple of things have made much progress. a) modular deployment and dependency management. No surprise here as this is a job of major, major difficulty. b) policy for library deprecation - not really hard but really very low priority. c) improvements in incubator - no real progress - but it's probably as good as it needs to be. d) boost website improvement - no discernible progress. There is one big lesson from all this: a) Boost is not a company - we don't take direction from the top. b) Boost is not a government - we actually do something. c) Boost is a religion - want something changed, start preaching. Get other people on board. Convince people people to start doing something. Take a look at the CMake history. There was a huge effort undertaken from the top to switch to CMake for build / test. It was a failure because it tried to do it from the top down. I'm thinking that the promoters of this idea concluded that the problem wasn't ambitious enough and added deployment to the task and built rypll. This had as key collaborators our most capable and hard core developers - including David Abrahams and Eric Neibler. Huge amount of expended effort but not much came out of it. I think if you want to help boost evolve - remember Boost is a religion. We are the jesuits of C++. Bjarn's marines - the tip of the spear. We ambush the world with a new idea which builds or replaces something else. We do it in an insidious manner. The opening up to CMake has proceeded steadily over years until it's a the cusp of victory. No one saw it coming and here it is. The world doesn't change from great initiatives, it changes when the old order collapses while espending it's existence to deny change. I've been told on this is a right wing world view - and so it is - oh well. So I encourage those who want to contribute to Boost and by extension C++ to consider using this approach. I think you'll be more successful. Robert Ramey

19 47

A comment on cmake and subprojects
by Biddiscombe, John A. 20 May '16

20 May '16

In our task of the HBP (Human Brain Project), we have a lot of libraries with interdependencies and have standardised on a reasonably simple system that works well enough – it can/could be improved significantly, but in case it’s of interest to boost, here’s a brief description (which I’m writing from memory and all the actual names of commands etc are wrong, but I only aim to describe the process) A top level cmakelists file would contain something like project(my_big_project) add_subproject(subprojectX ${CMAKE_CURRENT_SOURCE_DIR}/x) add_subproject(subprojectY ${CMAKE_CURRENT_SOURCE_DIR}/y) etc subprojects X,Y,….. Are defined by either including the source for those projects in the relevant subdirs, or by providing an additional command along the lines of git_external_project(name URL branchname/SHA/etc) Or by supplying a .gitprojects file in the root of the master subproject (subproject can if they wish do this recursively) which may contain a list of desirable projects + urls that we know will be needed if enabled When the user runs cmake on the top-level source project (my_big_project) it provides OPTIONS of the form SUBPROJECT X ON/OFF SUBPROJECT Y ON/OFF Which the user can enable via the GUI or by cmake –DSUBPROJECT_X=ON …. The macros defined will decide that if project X is not present to do a git clone (--shallow, --branch, --anything you want to add in the config) of project X,Y,… from the git URL supplied and checkout the repo into the correct location, add_subproject then enters the subproject and cmake progresses as usual. Inside the subproject, another macro can defined DEPENDENCIES of the project via more instantiations of the same kind which will also be cloned as git subprojects if they are not already present (currently if X depends on A branch1 and Y depends on A branch2 we throw an error, but it would be possible to support this tight control of include_directories). Seeing the ongoing discussion of cmake in boost (I am one of the many it seems who cmakeified the parts of boost I needed years ago and then gave up around the time rypll came into being – hoping that the job would be done properly). So the top level boost cmakelists would simple contain a list of all the libraries and their git locations and release branches, each sub project (library) can say dependencies(atomic, filesystem, threads, context) and let the cmake scripts do the rest. A user checking out the “top” level boost would get only a single cmakelists file with a bunch of helper scripts containing the macros needed for install, versions, git cloning etc etc and would then run cmake –DSUBPROJECT_ATOMIC=ON –DSUBPROJECT_THREADS=ON –DSUBPROJECT_CONTEXT=ON ~/path/to/top/level/boost-cmakelists (you could change the SUBPROJECT to BOOSTMODULE or something like that if you preferred) If one of the libs the user ‘wants’ uses another library, it gets enabled by the dependencies declared in the lib and everything just builds and works. A make install will install all the libs that got built including those dependencies that were pulled in (some public/private options could no doubt be added to make that better if necessary). To give you an idea of what I’m referring to, https://github.com/Eyescale/CMake/blob/master/GitExternal.cmake<https://github.com/Eyescale/CMake/blob/master/SubProject.cmake> https://github.com/Eyescale/CMake/blob/master/SubProject.cmake Are a couple of scripts that do some of the work. The process has helped us to simplify somewhat our build and dependency process and it might be a useful mechanism for boost to use cmake. It isn’t perfect, isn’t pretty in some places and has been heavily tweaked beyond its original purpose so the scripts would not be considered usable in their current state – but with some cleaning up … One very nice feature is the one can create a simple script project(mystuff) #set some options we might beed set(boost_optionX,y,x…) add_subproject(boost) # and some more set(hpx_optionX,y,z…) add_subproject(hpx) set(my_optionX,y,z…) add_subproject(stuff_that_needs_them) And the user does not need to worry about cloning the projects as the gitproject refs will do it for them and take what’s needed on a per repo basis. (I use this for HPX extensively - the individual libs/projects must be careful with relative path names and using per project prefixes for options, tests etc etc) I would be happy to volunteer as a helper should you wish for help cmakeifying boost regardless of the method by which you proceed. 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

1 0

Files in individual libraries
by Edward Diener 20 May '16

20 May '16

As long as library authors follow the normal Boost guidelines for placing the necessary files for using, building ( for non-header only libraries ), testing, and documenting their library I really don't see why an author cannot add to their library whatever other files they want in whatever place in their library structure they want to put it. Can it really be such a big issue that this should not be allowed ? And, if so, why ? If the real issue being objected to is that the placement of additional files gives the end-user an impression that Boost libraries generally support additional things which an individual library supports with the additional files, wouldn't it just be better to encourage and/or require that an individual library developer document the additional files as personal extensions to what Boost requires.

2 2

Re: [boost] [Boost-users] Boost 1.61.0 has been released
by Daniel James 19 May '16

19 May '16

On 18 May 2016 at 08:05, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > Tom has pointed a typo in file names in the file. Correct one is now > attached, and instructions > for validating are the same: I added the to the website, it's currently linked from the release notes, and if it's okay, I'll add a link to the download page at some point. Although it can't be underestimated just how little I care or understand about any of this stuff, so I'm sure I've done it all wrong. If line endings make a difference then it might not work since git converted the file to unix style automatically, so let me know. I also don't really want to add all the instructions to the release notes, so if someone wants to write generic instructions for another page, I could put that up and link to it.

1 0

DMARC and mailman
by James Sharpe 19 May '16

19 May '16

In June 2016 gmail is going to be changing its DMARC policy to reject any unaligned mail. This means that we will be seeing any mailing list responses from a gmail.com address to be considered spam by any mail server that enforces DMARC. For a while now yahoo.com has had this policy turned on which has meant that yahoo.com addresses have been considered spam. Mailman has released a workaround in version 2.1.18: https://www.mail-archive.com/mailman-users@python.org/msg64098.html The boost mailing list is currently on mailman 2.1.15. I'd strongly suggest that this should be updated as a matter of urgency else we'll find a lot of the conversations on this list will end up in the spam folder... Regards, James

1 0

Link problem
by Adolfo 19 May '16

19 May '16

Hi everyone, I am quite newbie on this and perhaps this is quite simple, sorry for the trouble. I am using VSC++ 2012, I have the boost version boost_1_60_0 and I have built it following the description in http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html. No problem with batch files (bootstrap and b2). When I try to test the example code from section 6, I have the following linking error: Error 1 error LNK1104: no se puede abrir el archivo 'libboost_regex-vc110-mt-gd-1_60.lib' I have realised that in my ...\boost_1_60_0\stage\lib directory, all the .lib files have names like libboost_*-vc140-*-1_60.lib. Can anybody be so kind of telling me what I did wrong or where I have to change this?? Best wishes, Adolfo.

3 2

Re: [boost] [Boost-users] Boost 1.61.0 has been released
by Tom Kent 18 May '16

18 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Wed, May 18, 2016 at 2:05 AM, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > On 17/05/2016 13:16, Vladimir Prus wrote: > > > On 13/05/2016 15:07, Rene Rivera wrote: > > > Release 1.61.0 of the Boost C++ Libraries is now available. > > > > > > For details, including download links, see http://www.boost.org/users/news/version_1.61.0 > > > > > > You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.61.0/ > > > > You can optionally verify integrity of the source downloads using the attached signed checksums file. > > Tom has pointed a typo in file names in the file. Correct one is now attached, and instructions > for validating are the same: I now get good hashes and a good signature verification. I'm signing this email with my private key "Thomas Kent <teeks99(a)yahoo.com>" for the record. Tom Original Attachment: - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640 boost_1_61_0.tar.bz2 a77c7cc660ec02704c6884fbb20c552d52d60a18f26573c9cee0788bf00ed7e6 boost_1_61_0.tar.gz fa1c34862b7ba8674ed6e064a14667a11830c6252f702d9458451834b74f7815 boost_1_61_0.7z 02d420e6908016d4ac74dfc712eec7d9616a7fc0da78b0a1b5b937536b2e01e8 boost_1_61_0.zip - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXPBG3AAoJEA8aPs1OrCMWL1QQAJCsQbr4rxpQMDssW5O0Fupg aw8Us0CnfPLSPW5gMdQoIQxu/n1SNobn4Vg1/hyTfweufqFwHFRxJnHiWtlbI/GB q1TueLPCxcJUi6lT7ZOVcpKb6AS6vOnSJRODQ0zk62phKBmLDUxiBI46FlCkzHbz uWVG+wttzk2Skeb3400xWEMtM0fgX3oJenh5Ye//oD7biJC0aIVPrnkauQ2Nze0l 2nG8e7w7ZzlXEx0Ei8KHiyBsFMj0/O5JIJKbxWorBAeELSgWun0YqB9EnrbADGDp XCEUUg1FB2llTmpG3a/dyv8fMlAS/ENka7e4aGuIHAlyfmTKGx+9Zd813XLiSjvw CHCyp+b7v0dGn2RFrVhgl9qRyFKgcvYjhhsA42iO0eFt7rgkoXV72qQzjSClzjkS jJrcj8dxJkZVMJ9tWKCmzGoPYRj4z8Nt8dw7HDqFGb7/2Rw6FZ18N9SsqHD+y9G3 TZhPPYQJVqckM9qo0CFzYwZpjiBgLhhQI6iEUh8UB8xXB09cJfgHGvyszXsvR+3l xQvKq19BYWHlPoi4Ie+YUzxF81Pgj98mbnwXLcgUoLBZWueXGfFdf+nBvyDoQyli LbHEpt0cGwWyfk+HXt+Qa5dmSRMr7zZpmWseBr9/6J1gCoNxAEOqHZ1hCrpFIHWt pM+LHXktogy3CpBV2IXH =6T/2 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXPIMxAAoJEO5CwwL7YZSoqjQQAME+iTB9MhE3Jz2AAl7+tohB +v8U25f1C2X6qbVTKCynG+FzdfthIOwdLeReIcY8fUD7O30LqhYpfjPgDJvRqvDT pjU/jxD4ORLn9aEtNGcEX+EtSuO9dV2eZP3cDcyNnTRUu26O6LkJN2wRb2BFa1kN coVuhNSD7I8BBpiNgWo/J09Ajv3GRags8y6WHjC6IUD5isGUGMGD7udhjD6qcX/q hiyTfdzkqMo5lDmGj20JCsuXg1Iqku5JKydeDH4vunpZokbDmtSja992kzMSRFGK CemHapPcml5ei8ubvEnROYLPcIpcrL9zpO6vTpKRQs5dzfJDkeiCeS9Zgvm/fb7h G4yoUD08ccU0HHwRVCNdpHXPRgSSh3JJp94XuWO/sFgNg0q+5pGeGoqnveBaroqu zAgdcteBmw+YoU39bWt+kPu5zVbVygHZNXpC0BOKc8+IP86wwOvEHDEUm1o5UQma QPWQrZuoMcGNE9SZn1K1Zg+oJ6KG5Ykp5SOhhb3SrV7Oqb3SN3lg9lbEyGBHa/lY SUSLdMlkcEtUITRu6KcYJAVw9Pbq2O8AZWYPZSjToZxpEFv4+53VOSr3mkpFQxMc dzral/n0Yyw+XsqIke1kdzWpbCGrPAy0Pm5BGB7Fsi9iq1JbVjVi47ZIk4L16L0H gmgII1jsJy8+R3XXpGRZ =x/tu -----END PGP SIGNATURE-----

1 0

Re: [boost] [Boost-users] Boost 1.61.0 has been released
by Daniel James 18 May '16

18 May '16

On 17 May 2016 at 21:42, Raffi Enficiaud <raffi.enficiaud(a)mines-paris.org> wrote: > > Thanks! > The boost.test documentation has the banner "click here to view the latest > version on this page" on the top: > http://www.boost.org/doc/libs/1_61_0/libs/test/doc/html/index.html > > Sorry for the late mention, I thought it was because 1.61 was not released > yet. > Anything I did wrong? Anything I can do? Sorry about that, it was a bug. It should be fixed now, you might have to shift-refresh to see the fixed page.

1 0

Review Wizard Report for May 2016
by Ronald Garcia 18 May '16

18 May '16

============================================== Review Wizard Status Report for May 2016 ============================================== News ==== 1. Boost 1.58 Released April 2015. New Libraries: Endian, Sort 2. Metaparse Library Accepted 3. Hana Library Accepted 4. DLL Library Accepted 5. Http Library Rejected 6. Boost 1.59 Released August 2015. New Libraries: Coroutine2, Convert 7. AFIO Library Reviewed 8. Fiber Library Conditionally Accepted 9. Boost 1.60 Released December 2015. New Libraries: Variadic Macro Data 10. Quaternions, Vectors, Matrices Accepted 11. Fit Library Rejected 11. Boost 1.61 Released May 2016. New Libraries: Compute, DLL, Metaparse, Hana Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been reviewed and await reports from their review managers: * AFIO - reviewed August 2015; review manager: Ahmed Charles. The following libraries have been accepted to Boost, but have not yet been integrated into Boost Git: * Contract - accepted September 2012; author: Lorenzo Caminiti. * Quaternions,Vectors,Matrices - accepted December 2015; author: Emil Dotchevski The following libraries have been accepted and submitted to Boost Git, but have not yet appeared in a release: * none The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * none General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot ubc dot ca" and "johnphillipsithica at gmail dot com" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Boost.Range Extensions * Nowide (M) * Array (M) * STL Extensions (M) * Countertree (M) * Process (M) * Application (M) * Edit Distance (M) * Mixin (M) * Dependency Injection (M) * Segmented Tree * Fiber ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. STL Extensions -------------- :Author: Vadim Stadnik :Review Manager: Needed :Download: https://github.com/vstadnik/stl_ext_adv_review :Description: The proposed library [stl_ext_adv] offers augmented array based B+ trees and STL containers that support the interfaces of the C++03 sequences and associative containers. The library offers a number of extensions and performance improvements that are not available in C++03 and C++11 standard containers. Countertree ----------- :Author: Francisco Jose Tapia :Review Manager: Needed :Download: https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip :Description: This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators. COUNTERTREE This kind of trees have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators. With unordered information we have a vector with the same speed inserting and deleting in any position (O(log N)). With ordered information, we have the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract them. SUBALLOCATOR The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator replace to the allocator in the allocation of equal size elements. It provides speed, return the unused memory and decrease the memory used by the program and improve the cache performance due to the data locality improvement ( 30% of improvement of speed respect the std::allocator with GCC 4.7) Process ------- :Author: Boris Schaeling :Review Manager: Needed :Download: http://www.highscore.de/boost/process0.5/process.zip :Description: Boost.Process is a library to manage system processes. It can be used to: * create child processes * setup streams for child processes * communicate with child processes through streams (synchronously or asynchronously) * wait for processes to exit (synchronously or asynchronously) * terminate processes Application ----------- :Author: Renato Tegon Forti :Review Manager: Needed :Download: https://github.com/retf/Boost.Application :Documentation: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html :Description: Application provides an application environment, or start point to any people that want a basic infrastructure to build an system application on Windows or Unix Variants (e.g. Linux, MacOS). Application uses behaviours modeled using 'aspects' concept proposed by 'Vicente J. Botet Escriba', that allow easy extension and customization of library components. The application modes uses these components internally to achieve the user desirable behaviours. Application provide many useful ready-to-use features, e.g: * Run application as Windows Service; * Run application as UNIX/POSIX Daemon; * Plugin extension system; * Process(executable) Single instance Instantiation support; * Application SIGNAL/Callbacks customization; * Windows Service Setup feature; * And many others. Edit Distance ------------- :Author: Erik Erlandson :Review Manager: Needed :Download: https://github.com/erikerlandson/algorithm/tree/edit_distance/sequence :Description: The edit distance is the length of the shortest (or least-cost) edit script from one sequence to another, where an edit script is defined as a sequence of insertion, deletion and (optionally) substitution operations. The function implementing the edit distance is named edit_distance. This function will return the edit distance between two sequences, where sequences may be any valid range object supporting forward iteration. The edit_distance function will also, if requested, return the edit script. Mixin ----- :Author: Borislav Stanimirov :Download: https://github.com/iboB/boost.mixin :Documentation: http://ibob.github.io/boost.mixin/ :Review Manager: Needed :Description: Boost.Mixin is a library that allows the composition and modifications of polymorphic types at run time. Types and objects are constructed out of building blocks called mixins. The library uses the type boost::mixin::object as a placeholder, whose instances can be extended with existing classes (mixins), thus providing a particular instance with the functionality of all those types. Accessing the newly formed type's interface is made through messages: stand-alone functions generated by the library, which can be thought of as methods. This is given while also having full abstraction between the interface and the definition of types. An existing feature in another language similar to Boost.Mixin and also an inspiration for the library are the mixins in Ruby. The library also has similarities with the pattern entity-component-system. Dependency Injection -------------------- :Author: :Download: https://github.com/krzysztof-jusiak/di :Documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html :Incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection/?gform_p… :Review Manager: Needed :Description: Boost.DI is a dependency injection library improving manual dependency injection by simplifying object instantiation with automatic dependencies injection. Using Boost.DI has many advantages over manual dependency injection. * Reduce boilerplate code (No factories, no objects creation in specific order) * Reduce cost of maintenance effort (Constructor signature change won't affect di configuration) * Reduce testing effort * Give better control of what and how is created (Policies, Providers) * Give better understanding about objects hierarchy (UML Dumper) Segmented Tree -------------- :Author: Chris Clearwater :Download: http://rrsd.com/blincubator.com/bi_library/segmentedtreeseq-2/?gform_post_i… :Repository: http://github.com/det/segmented_tree :Documentation: https://det.github.io/segmented_tree :Review Manager: Glen Fernandes :Description: SegmentedTreeSeq is a sequence data structure like vector and deque that supports efficient random access insert and erase. It is implemented using B+Trees and has an emphasis on speed and a low memory overhead. Fiber ----- :Author: Oliver Kowalke :Download: https://github.com/olk/boost-fiber :Documentation: http://olk.github.io/libs/fiber/doc/html/ :Review Manager: Nat Goodspeed :Description: Boost.Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Libraries under development =========================== See The Boost Library Incubator Project at http://blincubator.com for discussion of libraries currently under development.

2 1

Re: [boost] [proto][variant] variant crashes proto expression
by Igor R. 17 May '16

17 May '16

> // The values bound to the placeholders > Value *d[2]; <...> > // The result of evaluating arithmetic expressions > typedef Value& result_type; So, you store pointers to the variants and return references, thus preventing copying. But why does the copying cause the aforementioned crash? Does it look like a bug in Proto? That's quite weird, because I never encountered any issue with variant copying... -- View this message in context: http://boost.2283326.n4.nabble.com/proto-variant-variant-crashes-proto-expr… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Boost Build and Test
by Robert Ramey 17 May '16

17 May '16

I started a new thread to accommodate the widening discussion on CMake. Build and Test systems: I've always been a big complainer about Boost Build. Now I'm a big complainer about CMake as well. Just so you know. I always found it weird that the buiding of libraries jam file was stashed in it's own directory - build while jam files for other components like test and building docs was found inside their respective directories. I also added to the serialization library some other jam files in subdirectories example and in performance. So to me by far the most natural place to find the library jam file would be in the directory we've agreed to name src. I never made any issue of this as my whole progress through life is about moving on to get my own projects done. Largely motivated by the desire to do cutting edge C++ development I replaced my old windows system with a mac mini. Soon I wanted to build and test my projects in XCode IDE. I like to use an IDE, but setting it and maintaining it for a project like the serialization library is an incredible amount of work. So I resolved to setup CMake to do the job. I had exposure to CMake before and found it no better than all the other build systems. But it needed to do what I wanted it to do - create the IDE project and it was very popular. So I managed to make it work in this context and the result has been quite satisfactory. But making it run all the tests I want to run - different compilers, libraries, etc. etc. integrating with my own library_status dashboard builder looked like a serious pain and I already had an elaborate Jamfile set for doing all of that. So upshot is I use them both for different purposes. I don't see anything wrong with that. In order not to upset the established structure I put my CMakeLists.txt file inside it's own directory. If it was totally up to me, what I'd like to see is: a) jam files in the build directory moved to src b) thereby acknowledging the practice of having jam files in the same directories which contain the build sources. c) which is pretty much the same as the CMake approach. c) official tolerance for including other build systems at the same level such as CMakeLists.txt and maybe MS projects and solutions. d) official tolerence for including a top level CMakeLists.txt. Personally I don't think this is necessary or even a good idea - but I want to leave that as a separate discussion. Robert Ramey

1 0

Final benchmark graphs for Colony vs std:: containers now available
by Soul Studios 17 May '16

17 May '16

Re-wrote my benchmark code from scratch a month or two ago with some help from Baptiste Wiche, have run over std::list, std::map, std::multiset, std::deque, std::vector, and for GCC, Chris's segmented_tree implementation. To be honest there's not much point comparing against segmented_tree, as the goals are totally different (efficient random access insertion for segtree, vs efficient unordered erasure/insertion/iteration without pointer invalidation colony), but there was some interest last time I wrote here. In addition I compared against other methods for ensuring pointer/index validity using deques and vectors, to see how those things pan out. Graphs are available here: http://www.plflib.org/colony.htm#benchmarks and here: http://www.plflib.org/stack.htm There are also MSVC 2013 results linked to in the first paragraph of the benchmarks. Comments are welcome, but please read the page first. Stack performs particularly well, outperforming all alternatives in both GCC/MSVC.

3 16

Boost ICL tests attempting to pass non-bidirectional iterator to std::reverse_copy
by Billy O'Neal (VC LIBS) 16 May '16

16 May '16

Hi folks. I'm not a Boost.ICL expert, but we detected this one failure with our in-development STL and this test case: template <ICL_IntervalSet_TEMPLATE(_T) IntervalSet, class T> void interval_set_element_iter_4_discrete_types() { typedef IntervalSet<T> IntervalSetT; typedef typename IntervalSetT::interval_type IntervalT; typedef std::vector<T> VectorT; IntervalSetT set_a; set_a.add(I_I(1,3)).add(I_I(6,7)); VectorT vec(5), cev(5); vec[0]=MK_v(1);vec[1]=MK_v(2);vec[2]=MK_v(3);vec[3]=MK_v(6);vec[4]=MK_v(7); cev[0]=MK_v(7);cev[1]=MK_v(6);cev[2]=MK_v(3);cev[3]=MK_v(2);cev[4]=MK_v(1); VectorT dest; std::copy(elements_begin(set_a), elements_end(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( vec == dest, true ); dest.clear(); std::copy(elements_rbegin(set_a), elements_rend(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( cev == dest, true ); dest.clear(); std::reverse_copy(elements_begin(set_a), elements_end(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( cev == dest, true ); dest.clear(); std::reverse_copy(elements_rbegin(set_a), elements_rend(set_a), std::back_inserter(dest)); BOOST_CHECK_EQUAL( vec == dest, true ); } which produces this failure: C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1672): error C2665: 'std::_Reverse_copy1': none of the 2 overloads could convert all the argument types C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1655): note: could be '_OutIt std::_Reverse_copy1<_Iter,_OutIt>(_BidIt,_BidIt,_OutIt,std::random_access_iterator_tag,std::random_access_iterator_tag)' with [ _OutIt=std::back_insert_iterator<VectorT>, _Iter=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>>, _BidIt=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>> ] C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1645): note: or '_OutIt std::_Reverse_copy1<_Iter,_OutIt>(_BidIt,_BidIt,_OutIt,std::bidirectional_iterator_tag,std::_Any_tag)' with [ _OutIt=std::back_insert_iterator<VectorT>, _Iter=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>>, _BidIt=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>> ] C:\Dev\WCFB01_01\binaries\x86ret\inc\algorithm(1672): note: while trying to match the argument list '(boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<DomainT,Compare>>>>>, boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<DomainT,Compare>>>>>, std::back_insert_iterator<VectorT>, boost::iterators::detail::iterator_category_with_traversal<std::input_iterator_tag,Traversal>, std::output_iterator_tag)' with [ DomainT=bicremental_type_5, Compare=std::less ] and [ DomainT=bicremental_type_5, Compare=std::less ] and [ Traversal=boost::iterators::bidirectional_traversal_tag ] c:\dev\wcfb01_01\src\qa\vc\fe\3rdpartycomp\boost_1_60_0\libs\icl\test\fastest_interval_set_\../test_interval_set_shared.hpp(810): note: see reference to function template instantiation '_OutIt std::reverse_copy<boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<DomainT,Compare>>>>>,std::back_insert_iterator<VectorT>>(_BidIt,_BidIt,_OutIt)' being compiled with [ _OutIt=std::back_insert_iterator<VectorT>, DomainT=bicremental_type_5, Compare=std::less, _BidIt=boost::icl::element_iterator<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<boost::icl::discrete_interval<bicremental_type_5,std::less>>>>> ] c:\dev\wcfb01_01\src\qa\vc\fe\3rdpartycomp\boost_1_60_0\libs\icl\test\fastest_interval_set_\../fastest_interval_set_cases.hpp(61): note: see reference to function template instantiation 'void interval_set_element_iter_4_discrete_types<boost::icl::interval_set,discrete_type_2>(void)' being compiled We are considering reverting this enforcement of iterator category tag in our STL, but technically a standard library appears within its rights to reject this. Billy Robert O'Neal III SDE II - Visual C++ Libraries bion(a)microsoft.com

1 0

media file errors
by Rainer Deyke 15 May '16

15 May '16

"CDs/Reverend Bizarre - III - So Long Suckers (disc 1)" is redundant and should be deleted. In "CDs/Shadow Gallery - Room V": "Shadow Gallery - Seven Seas.mp3" -> "Shadow Gallery - Seven Years.mp3" -- Rainer Deyke (rainerd(a)eldwood.com)

1 0

Call for Submissions: International Conference on Information Society (i-Society 2016), Technical Co-Sponsored by IEEE UK/RI Chapter!
by Faye Bewsy 13 May '16

13 May '16

1 0