- Boost - lists.boost.org

[date_time] CW-9 failures.
by Rene Rivera 03 Jun '05

03 Jun '05

There are some failures for date_time with CW-9 (and similar errors in CW-8): CW-9.5 on Mac... http://tinyurl.com/bwhsw http://tinyurl.com/93nh4 CW-9.4 on Windows... http://tinyurl.com/75t78 http://tinyurl.com/br2b5 CW-8.3 on Windows... http://tinyurl.com/85nf5 http://tinyurl.com/9gfpn They have this as the reason: "[ J. Garland ] Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers." Now I don't particularly think of CW-9 as an "older" compiler. So is that really the reason? Or is it just that it hasn't been investigated? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 3

RE: [boost] Re: yield statement proposal
by Marcin Tustin 03 Jun '05

03 Jun '05

> -----Original Message----- > From: Giovanni P. Deretta [mailto:gpderetta@gmail.com] > Sent: 03 June 2005 03:15 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: yield statement proposal > Speaking of more Boost centric stuff? There has been any > proposal of a coroutine library? I think it should definitely > be useful and not really that hard to implement (fibers on > windows and makecontext or the setjump/sigaltstack trick on > unices). Anyone interested? What about a continuation library? Then co-routines could simply be built on top of that, along with everything else that can be built on top of continuations.

2 1

Template argument deduction question
by Vladimir Prus 03 Jun '05

03 Jun '05

Hello, the program_options library fails one tests on EDG compilers (Intel, Como), which a failure to deduce template arguments for a certain call. After reading the standard for some time, I failed to understand the reason. Below is the test program: char* cmdline3_[1] = {}; template<class charT> void func(const charT* const argv[]) {} int main() { // P is 'const charT* const argv[]'cmdline3_ // A is 'char* cmdline3_[]' // // According to 14.8.2.1/2 // If P is not reference type // -If A is an array type, the pointer type produced // by the array-to-pointer standard convertion (4.2) // is used in place of A for type deduction. // // So, A should become 'char**' // The following does not compile. func(cmdline3_); char** p = cmdline3_; // This does compile, even though the argument type used for // type deduction should be the same as in example above. func(p); } Anybody can explain what's going on? TIA, Volodya

3 4

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