- Boost - lists.boost.org

[range] iterator_range::operator[] broken
by Eric Niebler 14 Apr '10

14 Apr '10

Neil, I know you patched this a mere 5 hours ago, but it's still broken. The attached patch *really* fixes the problem, I think. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 4

[GSoC] Boost.Matrix RFC
by Kornel Kisielewicz 14 Apr '10

14 Apr '10

Hello all, Last year I submitted a proposal for Boost.Matrix as a GSoC project, that provoked quite a bit discussion. Considering the fact that it wasn't unanimously rejected, and that a few things have changed since then (Boost.Geometry acceptance) as did my skills, I'd like to take the liberty of resubmitting my proposal to the list, with a request for comments. The proposal follows: == Boost.Matrix == uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t Rows, std::size_t Cols, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations (matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. In general, this library would be similary scoped as Boost.Quaternion. Recently a new library has been accepted into boost -- Geometry. As the library is deeply about matrices and vectors, and has much in common with this proposal, I'd like to take a deep focus on providing maximum interopeability between Geometry and Matrix. == Rationale == Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors - a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable - due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side (optimization). Finally, the uBLAS introduces a lot of unneccessary bloat for users wanting only a 2,3,4 vector and 3,4 matrix classes. == Primary deliverables == Boost.Matrix library, with the following features: * a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind * specializations for efficient vector (1xN matrix) handling * operators for readable but efficient vector/matrix math * operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation * efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS, Quaternion and upcoming Boost.Geometry in particular) == Secondary deliverables == * performance test suite, for testing optimizations * unit tests for the whole library providing full operation coverage and code-coverage * documentation for the whole library in the BoostBook format, as well as doxygen markup for all the code == Bonus deliverables == ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) * performance tests on different compilers/architectures, further optimizations * support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) == Design issues == * compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) * usage of template expressions to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) and elimination temporaries * care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) -- possibly an alignment trait * design with architecture-dependent optimizations in mind ( ease of expansion ) * keeping all the standard boost practices, including workarounds for non-conformant compilers == Research == Several existing implementations were studied and evaluated before the repeated submission of this idea. I intend to encompass most of the good things I found in the following implementations into a small but very useful library: * Boost.uBLAS (obviously) * Eigen - http://eigen.tuxfamily.org/ (heavyweight) * CGAL - http://www.cgal.org/ (license issues) * Matrix Template Library - http://osl.iu.edu/research/mtl/ (similar issues to uBLAS) * VCGLib - http://vcg.sourceforge.net/ (GPL) * nVidia's vector and matrix classes (found in nVidia examples) -- regards, Kornel Kisielewicz http://chaosforge.org/

9 16

Re: [boost] [iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

"Stewart, Robert" <Robert.Stewart(a)sig.com <mailto:Robert.Stewart@sig.com> > wrote in message news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com <news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com> ... > this->base() calls iterator_adaptor<>::base(), which returns a reference to the underlying iterator it holds. Passing that reference to boost::prior() means that prior() pre-decrements the iterator within the iterator_adaptor. It would be odd for that >decrement operator to return anything but a reference to the decremented object, so boost::prior() returns a reference to its decremented argument, a reference to the decremented iterator within the iterator_adaptor. > I see no problem. boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it. I overlooked that I already filed a defect a while ago for it: https://svn.boost.org/trac/boost/ticket/2640 <https://svn.boost.org/trac/boost/ticket/2640> It would be great to have it fixed, because the bug is quite subtle and may go undetected for a while. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

3 4

[serialization] serialization lib not thread safe?
by Jean-Marie Auffray 13 Apr '10

13 Apr '10

I use boost serialization in multi threaded application. Sometimes application crashed. I manage to avoid bug if I recompile boost serialization with BOOST_SPIRIT_THREADSAFE defined in jam file : http://archive.netbsd.se/?ml=boost-build&a=2008-07&t=8023861 But I would like keep boost default installation. I read multi thread limitations here : http://www.boost.org/doc/libs/1_42_0/libs/serialization/doc/special.html But I don't find how to use singleton to avoid crash, I attach test files to reproduct crash. I use 1.36 in test files, but same bug seems to occure in next release. How can I add singleton from serialization to avoid crash? I try some solutions but failed to find a good implementation. Thanks for help.

2 1

release managers: permission to merge?
by Frank Mori Hess 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to the calendar, the release branch went into "closed except by permission" yesterday. Is it all right for me to merge to release the fix for this ticket: https://svn.boost.org/trac/boost/ticket/4089 The changeset in question is https://svn.boost.org/trac/boost/changeset/61243 I've tested it locally, but have just comitted it to trunk so the tests there haven't cycled yet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvEbewACgkQ5vihyNWuA4XawACg1jS8IZun6NJ52GkCa2V3i4nc PAIAoJlaXBs4NqY5mfGiHMoVAYJsTSVp =NiyZ -----END PGP SIGNATURE-----

2 1

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

[iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, boost::reverse_iterator::dereference() is typename super_t::reference dereference() const { return *boost::prior(this->base()); } boost::constant_iterator<T>::reference_type is T const&. So reverse_iterator< constant_iterator<T> >::dereference returns a reference to a temporary variable. Not good. I suggest removing the reference from boost::constant_iterator::reference_type, making it T. The rule would be that reference_type must only be a reference if the reference is pointing to some underlying container, not to the iterator itself. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

2 1

[iterator] Re: counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

> > counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. > You are able to override the difference_type by providing your own type. > See: > boost::counting_iterator<int,boost::use_default,int>::difference_type I know and I did it already. I just want to question whether the default is sensible, given the rest of the language. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

1 0

counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, I am sure this has come up a few times, but I could not find the answer in the archive. counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

2 1

[svn] request for commit permission
by Daniel Walker 13 Apr '10

13 Apr '10

Hello, I recently became the maintainer for Boost result_of. May I have commit permission on svn? Also, if I need to make an account, where do I register? Thanks! Daniel Walker

3 2