June 2005 - Boost - lists.preview.boost.org

Probing interest in fixed dimension matrix class
by christopher diggins 03 Jun '05

03 Jun '05

I have just finished writing a fixed dimensionality matrix template (kmatrix<T, Rows, Cols>) which appears to significantly outperform the ublas::matrix. Is there any interest? Below are the results of the benchmarks using Visual C++ 7.1 on an Intel Celeron 1.6 GHZ: Integer matrix multiplication: 2,2 X 2,2 kmatrix 94 msec elapsed ublas 578 msec elapsed 3,3 X 3,3 kmatrix 250 msec elapsed ublas 891 msec elapsed 100,100 X 100,100 kmatrix 593 msec elapsed ublas 1422 msec elapsed 100,1 X 1,100 kmatrix 172 msec elapsed ublas 266 msec elapsed 1,100 X 100,1 kmatrix 625 msec elapsed ublas 1718 msec elapsed Double matrix multiplication: 2,2 X 2,2 kmatrix 94 msec elapsed ublas 593 msec elapsed 3,3 X 3,3 kmatrix 297 msec elapsed ublas 1235 msec elapsed 100,100 X 100,100 kmatrix 766 msec elapsed ublas 1625 msec elapsed 100,1 X 1,100 kmatrix 203 msec elapsed ublas 328 msec elapsed 1,100 X 100, 1 kmatrix 813 msec elapsed ublas 2125 msec elapsed Christopher Diggins http://www.cdiggins.com

8 16

[filesystem] Generic path grammar corner cases
by Beman Dawes 03 Jun '05

03 Jun '05

I'm working to align the Boost.Filesystem generic path grammar with the POSIX specification. Doing so clarifies the specification of the library, and ensures that all native paths for both POSIX and Windows will work correctly. (Windows follows the POSIX conventions in some of the corner cases involved.) The particular cases involve extra slashes in paths. For example, "/foo//bar//". I was surprised to find that such a path is well-defined for POSIX and Windows, with a meaning of "/foo/bar/." In other words, multiple slashes treated as a single slash, and paths with a trailing slash treated as if a period was appended. The rules for more than two leading slashes are a bit more complex - for POSIX they are treated as a single slash, for Windows that is an invalid path. Question: what should path("foo//bar//").string() yield? 1) "foo//bar//" 2) "foo/bar/" 3) "foo/bar/." (1) follows the rule that the path string is always exactly as input. Desirable in that if a platform actually implements something a bit different from the POSIX specs for multiple slashes, implementations will behave as expected for the platform. Downside is much more complex implementation (because many more functions have to be able to cope with multiple slashes) and more complex testing. (2) Desirable in that if a platform actually implements something a bit different from the POSIX (and Windows) specs for multiple slashes, implementations will behave portably and correctly in a POSIX (and Windows) sense. (3) Desirable in that for all three options directory iteration will return three elements - "foo", "bar", "." - so it is a bit counter intuitive for the "." not to appear in the string() results. Not a strong argument. I'm leaning toward (2). Any comments? --Beman

7 12

fusion::for_each question: Why const operator in the fctor?
by Brian Braatz 03 Jun '05

03 Jun '05

I am using the fusion code in 1.32 with the vc 71. compiler. My question is, considering the following unit test (for_each_tests.cpp) struct print { template <typename T> void operator()(T const& v) const { std::cout << "[ " << v << " ] "; } }; { typedef tuple<int, char, double, char const*> tuple_type; tuple_type t(1, 'x', 3.3, "Ruby"); for_each(t, print()); std::cout << std::endl; } (this code runs correctly for me) If I change the function to: struct print { template <typename T> void operator()(T & v) const { std::cout << "[ " << v << " ] "; } }; It still works, but changing it to struct print { template <typename T> void operator()(T & v) { std::cout << "[ " << v << " ] "; } }; Does not work. Why does the functor need to have a const operator()? I have been trying to take a tuple<> and touch each node in the tuple (ala for_each in fusion), which I was *very* happy to find fusion has this as working functionality. But, the next step for me is to have the functor write to its local member variables. I.e. requiring const here really limits the usefulness of the fusion::for_each. I look in my compilers header and noticed that stl::for_each does not have a const requirement on the functor. Is this a mistake? Is there a reason I am not seeing why for_each would have this limitation? Thanks for any help and guidance. Brian "Remember, there are no stupid questions. Only stupid people....."

2 1

RE: [boost] Re: Probing interest in fixed dimension matrix class
by Martin Bonner 03 Jun '05

03 Jun '05

----Original Message---- From: Deane Yang [mailto:deane_yang@yahoo.com] Sent: 02 June 2005 16:57 To: boost(a)lists.boost.org Subject: [boost] Re: Probing interest in fixed dimension matrix class > Andy Little wrote: >> >> eg to find the point 1/3 rd way from the start of line(A , B) one >> could calculate 2/3 *A +1/3 * B. >> > > I think it is more natural to compute this as > > A + (1/3)*(B - A), > > where A and B are points and B - A is a vector. So you're really still > just adding a vector to a point to get a new point. There is never a > need to add or rescale points. Hmm. To me that looks a very UNnatural recasting of the original in order to satisfy the rule. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Sunday: Mailing list outage
by David Abrahams 02 Jun '05

02 Jun '05

-- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

set arithmetic proposal
by Dominic Herity 02 Jun '05

02 Jun '05

I've often wished that STL sets supported set arithmetic operations. Addition, multiplication and subtraction operators could be overloaded with set union, intersection and difference respectively. For example: set<char> s1; // s1 <- {} s1 += 'a'; // s1 <- {a} set<char> s2 = s1 + 'b'; // s2 <- {a,b} set<char> s3 = s2 - s1; // s3 <- {b} set<char> s4 = s1 * s2; // s4 <- {a} Achieving the above results with the existing STL library is by comparison cumbersome, error-prone and unclear. Although this proposal does not follow the STL design philosophy, it meets a real developer need. It can be implemented using global operator overloads, which should avoid conflicts with other uses of STL sets. Comments and suggestions welcome. Best Regards Dominic Herity Red Plain Technology (www.redplain.com) T:+353-87-2208233 F: +1-603-909 6570 E: dominic.herity(a)redplain.com

6 7

Re: Typeof: Review result
by Tom Brinkman 02 Jun '05

02 Jun '05

>> >> I am pleased to formally announce that the Typeof library has been accepted into >> Boost. > > Congratulations Arkadiy and Peder. > >> There were 3 reviews, all in favour of accepting the library. > > While I'm not questioning the value of accepting this library > specifically, doesn't it seem less than ideal to accept a library > that -- for whatever reasons -- garnered only three reviews? >> Yes. > While the library was truly peer reviewed, and the reviews were > by knowledgeable folk, the base of input is narrow as a result. > Should this be the norm? >> No. Not sure what we can do about it. I think the review wizard > should weigh in here. Three positive reviews is not sufficient in my opinion. However, the precedent has already be set, as other libraries have been approved on a similar limited number of reviews. I'm sure most would agree that the review situation is not ideal and could be improved. However, it has worked to some extent and the boost c++ libraries, are arguably among the best available. One easy improvement would be to require that each approved library be endorsed/sponsered by a least one prominent boost member, such as Dave Abrahms, Jeff Garland or Thorsten Ottosen. Another easy improvement would be to add accepted libraries under a probation or beta period of say six months. The library would remain beta until its stable enough and has additional time for more user scrutiny. A prominent boost member would make the judgement about when to remove the library from its beta period. During the beta period, the library author would be asked to complete the libraries documentation, examples and requested changes from the additional user scrutiny. If there are no objections, I will start requesting that libraries under review be sponsered by at least prominent boost member. This would ensure that accepted libraries meet the approval of a least one prominent boost member. Review Wizard, Tom Brinkiman

11 14

Boost/SourceForge statistics
by Beman Dawes 02 Jun '05

02 Jun '05

SourceForge has markedly improved project statistics reporting. See http://sourceforge.net/project/stats/index.php?group_id=7586&ugn=boost I found the pages viewed numbers interesting. Looks like www.boost.org has been serving an average of about 22,000 page views a day in recent months. I suppose some sites serve up that many pages in a minute or a second, but 22,000/day doesn't seem too bad for a C++ library effort. --Beman

2 1

Pointers to member function templates as template arguments
by Jonathan Turkanis 02 Jun '05

02 Jun '05

Hi, Consider the following code: template<typename T, void (T::*) (int)> struct MemFn; struct Foo { template<typename Int> void bar(Int) { } }; typedef MemFn<Foo, &Foo::bar> type; This compiles with VC7.1, GCC 3.4, Intel 8.0 and Comeau 4.3.3 in strict mode, but CodeWarrior 9.4 fails with the message: Error : illegal implicit member pointer conversion example.cpp line 9 typedef MemFn<Foo, &Foo::bar> type; Looking at 14.3.2/1, I notice while the third bullet, on function pointers, explicitly mentions templates, the fourth bullet, on pointers to members, doesn't. But perhaps pointers to function templates are covered implicitly. Looking at 14.3.2/5, bullet 6, I see that no conversions are applied to pointers to members. But no conversions are needed in the above example. What's needed is overload resolution, which is explicitly allowed. So who's right -- Metrowerks or everyone else? Jonathan

2 5

[iostreams] failure do build zlib.cpp in cvs HEAD
by pedro.lamarao＠mndfck.org 02 Jun '05

02 Jun '05

It seems the declaration of zlib_base::reset in zlib.hpp doesn't agree with the definition in zlib.cpp. After applying the following trivial patch everything compiles fine. -- Pedro Lamarão Index: boost/iostreams/filter/zlib.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/filter/zlib.hpp,v retrieving revision 1.18 diff -r1.18 zlib.hpp 194c194 < void reset(bool compress); --- > void reset(bool compress, bool realloc);

2 1