- Boost - lists.boost.org

Re: [boost] [gsoc15] Attn: We need 2015 mentors and project ideas for Boost!
by Antonio Colino 22 Feb '15

22 Feb '15

Here is a random thought for a project idea. Agner fog created a vectorization lib for the sse and avx instruction sets as part of a project called vector class. Intel created the equivalent opencl kernels as part of a project that is called ispc ( Intel simd program compiler ). Research both and submit a single vector lib that auto vectorizes avx, sse both gpu and cpu overloading the std::vector class operators.Just a random thought. Intel SPMD Program Compiler)

1 0

[mpl] Fix to Ticket #11001
by Bruno Dutra 22 Feb '15

22 Feb '15

I just finished a pull request <https://github.com/boostorg/mpl/pull/14> with a fix for Ticket #11001 <https://svn.boost.org/trac/boost/ticket/11001>, which, by the way, I reported myself, so I'm quite confident it's fixed. Could one of the maintainers kindly review it? Oh and it is worth it to mention that I also included a new test case to ensure the fix is working. Kind regards, *Bruno C. O. Dutra*

1 1

GSoC: Enhanced vector and deque containers
by Benedek Thaler 22 Feb '15

22 Feb '15

Hi, I'm looking at the "Enhanced vector and deque containers"[0] item of the GSoC projects. I have to following interface idea: boost::devector: Like std::vector, but the first call to push_back inserts the element to the middle of the buffer. Likewise, reserve puts the contents to the middle of the new buffer (if any). This allows a cheap push_front, pop_front, push_back, pop_back. boost::deque: Like std:deque, but segment size can be specified in the constructor. To make buffer operations easier, a `segment_end` would be provided: iterator segment_end(iterator begin) Which returns the end of the largest consecutive range starting at `begin`. I'm also thinking about the following twist: Assuming this layout: [a,b,c,d] [e,f,g,_] Brackets denote segments, letters are elements, underscore is empty space. Here, inserting `x` after `d` normally results several moves and this layout: [a,b,c,d] [x,e,f,g] But instead, we could allocate a new segment: [a,b,c,d] [_,x,_,_] [e,f,g,_] To make the insertion cheaper. This behavior is similar to a segmented list, i.e: std::list<boost::devector<T>> Are these similar to the "extra functionality" mentioned in the docs you were thinking about? Thanks, Benedek [0]: https://svn.boost.org/trac/boost/wiki/SoC2015#a5.Enhancedvectoranddequecont…

1 0

Enquiry about gsoc project Enhanced vector and deque containers
by Jasdeep Singh 21 Feb '15

21 Feb '15

I had a few doubts regarding this project and was wondering if someone could help me out.It would be much appreciated.

1 0

[MultiIndex] Memory consumption of ordered indices
by Olaf van der Spek 21 Feb '15

21 Feb '15

Hi, What's the memory consumption of ordered indices? Is it implemented as a linked list, so two pointers per element? In that case for a write-only data structure an external ptr vector would make more sense wouldn't it? -- Olaf

3 4

[filesystem] temp_directory_path() behavior on Windows
by Beman Dawes 20 Feb '15

20 Feb '15

temp_directory_path() on Windows is currently implemented by calling the Windows API GetTempPath() function. Ticket https://svn.boost.org/trac/boost/ticket/5300 points out that GetTempPath() does not work as expected for environmental variables longer than roughly 130 characters. I've added a test to Boost.Filesystem that verifies that boost::filesystem::temp_directory() is affected. The suggested fix is to use GetEnvironmentVariable to in effect implement GetTempPath() the way we would like it to work. That makes sense to me, so I looked up the specs for GetTempPath(): The GetTempPath function checks for the existence of environment variables in the following order and uses the first path found: 1. The path specified by the TMP environment variable. 2. The path specified by the TEMP environment variable. 3. The path specified by the USERPROFILE environment variable. 4. The Windows directory. (4) Makes me queasy. I suspect it will fail anyhow because of permissions errors, but I would prefer to have temp_directory_path() report an error if 1, 2, and 3 are not present. temp_directory_path() already reports an error if a path is found but it is not a directory. OTOH, excluding the Windows directory is a breaking change for anyone currently depending on that behavior, so I thought it best to ask for comments before charging ahead. Thoughts? --Beman

8 39

[log] custom architecture and address-model
by Vladimir Prus 19 Feb '15

19 Feb '15

Hi, it seems that Boost.Log defines, and checks, it's own log-address-model and log-architecture and log-instruction-set properties. Naturally, if I'm trying to make regular address-model and architecture properties always set, these are getting in the way. Do we really need per-library properties? If a user wants to build Boost.Log with a particular architecture, I would think he can do: ./b2 --with-log <whatever> If so, is everybody fine if I eliminate these custom features eventually? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

3 6

[Review] Boost.Endian mini-review
by Joel FALCOU 19 Feb '15

19 Feb '15

The mini-review of Boost.Endian starts today and runs through Sunday, February 1. The library repository is available on GitHub at https://github.com/boostorg/endian The docs for the library can be viewed online at https://boostorg.github.io/endian/ The objective of the mini-review is to verify that the issues raised during the formal review have been addressed. Those issues are documented at https://boostorg.github.io/endian/mini_review_topics.html which also describes the resolution of each issue. Comments and suggestions unrelated to the mini-review issues are also welcome, but the key question the review manager needs your opinion on is this: Is the library ready to be added to Boost releases? -- Joel Falcou, Endian Review Manager

16 57

[endian] Post-mini-review status: endian ready to merge to master
by Beman Dawes 18 Feb '15

18 Feb '15

Here is a post-mini-review status report to support a pull request to merge endian into the boost super-project master branch as a submodule. (It has been a submodule of the super-project develop branch for months.) The mini-review ran from January 23rd through February 1st. There were over 50 messages posted in the main review thread ("[Review] Boost.Endian mini-review"). The key question Joel Falcou, the review manger, asked was: Is the library ready to be added to Boost releases? All seven responses to the question were "Yes" votes (Peter Dimov, Nevin Liber, Philip Bennefall, Jason Newton, Jeremy Maitin-Shepard, Cliff Green, Bjorn Reese), and none of these votes were conditional. Other things that came out of the mini-review discussion: * Major concern: The default alignment needs to revert to unaligned. There should be no problem completing this before the final 1.58.0 release, and probably before the beta, but I need to carve out a quiet couple of hours to review the discussions before actually doing the revert. * Major concern: Floating point support needs an additional test program tailored to the characteristics of floating point numbers. A warning needs to be added to the docs alerting users that FP support is much less mature than integer support. The plan is to create the new test program in the next few days, and ask on the list for contributions of test cases from FP experts. * Requests for new features: A couple of simple to analyze and implement features have already been added. Other possible new features were added to a "Future directions" section of the docs so they won't be forgotten. * Technical fixes and suggestions. Most of these have already been applied. * Documentation fixes and suggestions. Most of these have already been applied, with three or four docs change emails still to be processed. Today is the cut off for 1.58.0 new libraries, so I'm planning to submit pull requests to merge endian submodule support from the boost super-project's develop branch into its master branch. (endian submodule support has been in the boost super-project's develop branch for months.) Thanks to all of those who contributed to the mini-review! --Beman

1 0

[GSoC] interested in implementing numerical algorithms for uBLAS
by Ganesh Prasad 17 Feb '15

17 Feb '15

Hi I am interested in implementing numerical algorithms optimized for distributed/parallel architectures for Boost.uBLAS. I have been applying for this project for previous 2 years, so I have definitely done some research in this field. Also, I have been working on Clusters for last 7 months as an Academic project (Product Development). So, basically I am acquainted with programming for distributed architectures with MPI. best wishes Ganesh Prasad

2 1