- Boost - lists.preview.boost.org

GSoC: Student applications can now be submitted
by Boris Schaeling 23 Apr '13

23 Apr '13

Student applications can now be submitted to <https://google-melange.appspot.com/gsoc/homepage/google/gsoc2013>. The deadline is 3 May. Boris

3 3

[iterator] Code/documentation mismatch in iterator_facade
by Gabriel Redner 23 Apr '13

23 Apr '13

Hi folks, I've stumbled upon an issue with iterator_facade. When creating a random access facade, one must implement the distance_to member function in order for std::distance to work. However, it looks like the arguments passed to this method are reversed from what the documentation states. Specifically, the docs [1] say (paraphrased): a.distance_to(b) is equivalent to distance(a, b). However, when I call std::distance(a, b), I find that b.distance_to(a) is invoked in the facade - the mirror image of what the docs say! This is not a problem if just wrapping some other random access iterator, but in my case the calculation of distance is nontrivial and this issue led to a rather tiresome debugging session and the solution (negating before returning from distance_to, knowing that iterator_facade will re-negate my response) is annoying to explain. Should I file a bug? A test case is appended to this message. -Gabe [1] http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/iterator_facade.html… ==================== #include <boost/iterator/iterator_facade.hpp> #include <vector> #include <iterator> #include <iostream> class vector_iterator : public boost::iterator_facade< vector_iterator, int, boost::random_access_traversal_tag> { public: vector_iterator(char tag, std::vector<int>::iterator it) : _tag(tag), _it(it) {} private: friend class boost::iterator_core_access; int& dereference() const { return *_it; } bool equal(vector_iterator const& other) const { return _it == other._it; } void increment() { ++_it; } void decrement() { --_it; } void advance(int n) { std::advance(_it, n); } std::vector<int>::iterator::difference_type distance_to(const vector_iterator& other) const { std::cerr << _tag << ".distance_to(" << other._tag << ")\n"; std::vector<int>::iterator::difference_type result = std::distance(_it, other._it); std::cerr << "result = " << result << '\n'; return result; } private: const char _tag; std::vector<int>::iterator _it; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); vector_iterator a('a', v.begin()); vector_iterator b('b', v.end()); std::cerr << std::distance(a, b) << '\n'; } ====================

2 2

[REVIEW] Boost.Predef
by Joel Falcou 23 Apr '13

23 Apr '13

Hi all, first, I want to apologize for the delay in getting this review results out. Looks like my last email get lost at some point. Anyway, after the initial review of Rene Riviera Boost.Predef, my decision was to Conditionnally Accept Boost.Predef under the request that the comments raised during the review period were addressed. Since then, Rene worked hard on actually making those changes so I now feel confident to announce that Boost.Predef is ACCEPTED as a Boost library. Regards

1 0

GSOC 2013
by Computer Vision 23 Apr '13

23 Apr '13

Hello, I was very busy with my studies, am I late? Are there any free projects left? Kind Regards

3 2

Going forward with Boost.SIMD
by Niall Douglas 23 Apr '13

23 Apr '13

> Unfortunately the concurrency/parallelism group has decided that they do > not want C++ to provide types representing SIMD registers. > I'm afraid I don't quite understand the rationale for such a refusal; > proposing more high-level constructs similar to valarray (or to our own > library NT2) was suggested, but that's obviously a more complex and > limited API, not a basic building block to program portably a specific > processor unit. As much as a refusal can be heartbreaking, trust me when I say that indecision or indifference is worse. The fact they gave you a definite refusal is actually one of the least worst outcomes from an ISO standards proposal, because you can now move on without uncertainty. > Development of Boost.SIMD will still proceed, aiming for integration in > Boost, but standardization appears to be definitely out of the question. > Any feedback of the API presented in the proposal is welcome. > <http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3571.pdf> If I were still part of ISO standards, I'd observe the following: 1. GPU and CPU stream computation technologies are still merging. In other words, it's too soon to standardize this technology lest we accidentally break some novel form of new convergence. Happy to reconsider post-C++14. 2. It's hard to standardize current CPU SIMD implementations due to extremely irritating inconsistencies between vendors. For example, a generic straight port of SSE2 to NEON will have awful performance because SSE2 code does a lot of flipping between SIMD and non-SIMD, and because NEON is a coprocessor on ARM that generates poor performance. Another bug bear of mine on NEON is the lack of an equivalent to _mm_movemask_epi8(), which can be emulated in about eight NEON instructions, but in so doing you'll make code which was very speedy on SSE2 pretty slow in most cases on NEON. My point here is you cannot standardize such non-uniform behavior in a universally performant way, because you'll just get lowest common denominator performance across all SIMD implementations which kinda defeats its purpose. If all vendors were like NEON, or like SSE2, then we still have to see how CUDA and OpenCL pan out long run. 3. I am unsure if C++ is the appropriate language for SIMD standardization when perhaps a meta-form of JIT compiled C++ would be much superior (i.e. you supply LLVM bytecode, and it gets delivered to a GPU/CPU/whatever). We'll have those on the table with LLVM-type compilers. In other words, I would vote to wait and see what the market throws up. I appreciate that none of these three rationale are what you want to hear. Still, I hope my observations are useful to you. None of them suggests you shouldn't proceed with Boost.SIMD. Boost has a much wider remit than just as a testing ground for future C++ standard library features. But I suspect that if SIMD ever does get standardized, it won't look like your library or proposal because it will be based on technologies which don't exist yet. Hope that helps, Niall

3 2

[log] Patch: rotating file collector (Was: Boost.Log: Any Comments?)
by Alexander Arhipenko 23 Apr '13

23 Apr '13

Hi, Just to remind the context, I'm pasting content from previous mail thread. On Tuesday 09 April 2013 18:43:05 Alexander Arhipenko wrote: >> ... >> [snip] >> ... >> >> It would be very nice to have rotation feature work the same way as in e.g. >> python logging library or Apache web server: >> * latest file has the name filename.log >> * previous file has the name filename.log.1 or filename.log.YYYY-MM-DD >> AFAIK, it's impossible to achieve in current implementation. >> >> Andrey, what do you think about this? >The library does not provide this behavior out of the box. But the file sink >uses a file collector object to collect rotated files. This collector can be >implemented by the user (it should derive from sinks::file::collector >interface) and it should be possible to implement it the way you describe. >Would you like to submit such implementation? I've added implementation of rotating file collector - the patch against boost log trunk attached. This is not the final version, I'm going at least to finish most of the TODOs. However, it would be nice to receive feedback and questions from library author as well as from people interested in this feature. Andrey, could you please find several minutes to review the attached patch? Also, I would like to discuss following question with you : rotate_file invocation in ~text_file_backend - I would prefer to have this call during text_file_backend construction phase. Regards

1 0

std::optional<T>
by Fernando Cacciola 23 Apr '13

23 Apr '13

Hi People, I'm pleased to announce that thanks to the outstanding effort of Andrzej Krzemienski who wrote the standard papers, and Ville Voutilainen who champion it during the meetings, we now have std::optional<T> in C++14! Cheers -- Fernando Cacciola www.scisoft-consulting.com

11 15

Plugin/Extension : DLL/so loading?
by Mathias Gaunard 23 Apr '13

23 Apr '13

I remember there were a couple of projects (Boost.Plugin or Boost.Extension) to support dynamic loading of a DLL/so plugin in a portable fashion in Boost. What has happened to these, and is there some code I can use somewhere?

3 4

Boost Graph Library: why are `source()`/`target()` non-member functions?
by Max Moroz 22 Apr '13

22 Apr '13

Why is `source()` not a member function of the graph class? (See http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/index.html for description, and boost/graph/adjacency_list.hpp and boost/graph/adjacency_matrix.hpp for implementation.) I thought the reason was that it was a generic algorithm. But it's not. There's no interface (beyond `source()` itself) exposed by an edge descriptor that would allow `source()` to avoid digging into the implementation. If I interpret the code correctly, `source()` reads directly from the internal data structure of the edge descriptor (`detail::edge_base.m_source`), which I am pretty sure is the implementation detail (`m_source`, despite being strangely exposed as a public member, is not the standard interface; otherwise it would have been defined as such, and `source()` would have been entirely redundant.) I think I'm missing something, but what?

2 3

GSOC
by Flórián Deé 22 Apr '13

22 Apr '13

Personal Details: Name: Flórián Deé University: Budapest University of Technology and Economics Major: Engineering Information Technology Degree Program: B.Sc. Email: deeflorian(a)gmail.com Availability: -starting after the exams, best case: June 10, worst case: June 21 -ending on at the 2nd week at the university: Sept. 15 -planned time spent on GSoC: 32 to 56 hours per week, as needed -other factors: two 3-day long trips - would catch up afterwards with extra work Background information: During my B.Sc. studies I'll already have finished all courses that are related to calculus, linear algebra, number theory, combinatorics and digital technology until summer, so in my opinion, all the educational background needed is present with the exception of the Signals and Systems course in next semester, which would cover digital Fourier transforms in detail. I'd gladly make up for this by reading the needed material. As for my programming background, I've fallen in love with C and C++, which now I consider to be my main languages. I'm currently working on a project as an outsider member of the dorm's Coder team (a poker framework for AIs), and I'm also a "consultant" for students with their C/C++ assignments. As a result, I've seen, written and debugged lots of different (admittedly not so enormous) projects with different coding styles. I'm interested in contributing to the Boost Libraries because two of my friends used a quite a lot of them while researching, and their feedback was always positive. The C++11 implementations also sounded nice, so adding to this codebase as a summer project would be an honor. I wanted to do a Solar System simulator during secondary school because I thought that I could calculate the acceleration (and approximate path) of a pen somehow shot near Earth. Then after the first console-based C++ implementation I realized that doubles aren't sufficiently precise to determine if an object is near or inside a planet, so I tried to write a "double double" class - which was too childish to work both code and mathematicalwise. Since then I know that I'd needed a precise mathematical library, and that radix-2 is my best friend when calculating on CPU-s, so I think that this project would be an ideal fit. Rating of knowledge: C++ - 4 C++ Standard Template Library - 4 Boost C++ Libraries - 2 Subversion - 3 Development environments: Eclipse, Visual Studio Documentation tools: Doxygen Project proposal, schedule and milestones: I'd like to work on the Boost.Multiprecision project described on the wiki page. As the description there is more than detailed, I wouldn't like to copy all that text here, but I'd follow the main steps described. I think that the I/O and the +, - operators should be finished, and the multiplication already started by the end of July. The *, / operators should be finished by the end of August at least with the Karatsuba multiplication, interoperable with Boost.Math, and the FFT multiplication should also be started by then. The final goal would be FFT multiplication, with passed correctness tests of wide variety from the beginning of the project.

1 0