July 2004 - Boost - lists.boost.org

Range/workaround test: SFINAE defect on EDG?
by Stefan Slapeta 31 Jul '04

31 Jul '04

First of all, the most important question: Why do we test workarounds for partial spezialization on compiler which don't need these workarounds? I've isolated the problem with the failing range/workaround testcase on Intel 8. IMO it's a compiler defect because the function template in is_array should be disabled by SFINAE. This code fails to compile with the current comeau release, too. template <class T> struct wrap {}; // this one should disabled because it's not allowed to return an array: template< typename T > T(* is_array_tester1(wrap<T>) )(wrap<T>); char is_array_tester1(...); void f() { sizeof(is_array_tester1(wrap<int[42]>()); } Shall a submit a DR? Stefan

5 5

White cells
by Stefan Slapeta 31 Jul '04

31 Jul '04

Please could anybody explain me what the reason for white cells in the regression tests is and why these tests are not executed? Concrete examples are: - test: ifstream_line_iterator_test - numeric/ublas: test7 Thanks, Stefan

2 1

Javascript Tree Control [was: Serialization Menu]
by Jonathan Turkanis 31 Jul '04

31 Jul '04

Dear All, There was a discussion a couple weeks ago about the javascript menu in Robert Ramey's serialization docs. I suggested making a menu component available Boost-wide and testing it on a large number of browsers to address portability issues. I've written a preliminary version, documented here: http://tinyurl.com/6a9ym and downloadable from here (its a bit large because it contains a bunch of screenshots): http://tinyurl.com/6w56v (tree_control.zip) You can see the control in action here: http://tinyurl.com/6tdvy I've verified that it works -- with varying levels of functionality -- on 26 browsersincluding some antiques such as IE3.02.

8 25

typeof: automatic ID generation and GCC problems
by Arkadiy Vertleyb 31 Jul '04

31 Jul '04

Hi everybody, I modified the code to automatically generate IDs of registration groups. The registration now is as simple as: #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(...); BOOST_TYPEOF_REGISTER_TEMPLATE(...); ... I also added some tests that should cause the ODR violation (see odr.hpp, odr1.cpp, odr2.cpp). VC7.1 is fine with them, however I can't make GCC 3.3 to compile this, and it stops much before the ODR could be diagnosed. Looks like this compiler totally can't handle the case when I try to use typeof (native or not) inside a template. When I force the typeof emulation, I am getting: "sorry, unimplemented: `method_call_expr' not supported by dump_expr" on every attempt to use my encoding/decoding stuff inside a template. From searching the web it looks like this is some kind of known bug related to improper handeling of sizeof(). Since sizeof() is the central part of all this, I don't really know how to work it around... This would probably be OK, since GCC has the native typeof support. However, when I use the native support, I run into a different problem that can be illustrated by the following code: template<class T, class U> typeof(T() + U()) sum(const T& t, const U& u) { return t + u; } main() { sum(5, 3.14); // this is line 9 return 0; } The compile of this code fails with following message: a.cpp:9: internal compiler error: in write_type, at cp/mangle.c:1555 GCC appears to be fine when the native typeof is used inside _class_ templates, though. I would really appreciate if anybody shed some light on any of these problems... The code is in the Spirit CVS and at: http://groups.yahoo.com/group/boost/files/typeof.zip Again, eveything is working fine in VC7.1. If anybody could try any other compiler (to build main.cpp, odr1.cpp, and odr2.cpp together), I would really appreciate this. Thanks, Arkadiy

5 6

Boost.Python -- Works With Qt?
by Robert Bell 31 Jul '04

31 Jul '04

Hi boosters- I have some Qt widgets that I need exported to Python for use with PyQt. I've been looking into sip, but I'm also curious if boost.python is up to the task. Has anyone tried this? Bob

2 2

Boost Threads Link Problem
by Joel de Guzman 30 Jul '04

30 Jul '04

Hi, Has all the Boost.Threads problems been solved yet? I am still having link problems with Threads on intel-win32-7.1 -vc6 (w/ or w/out stlport- 4.5.3): http://tinyurl.com/5c2dg Any clues? TIA, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

5 11

Exception safety guarantie
by Pavol Droba 30 Jul '04

30 Jul '04

Hi, During the review of the string_algo library, there was a request for better specification of exception safety in the lib. I have put some info into the docs, but I'm not sure if it is correct and sufficient. Could some of you, that had lead the discussion about this topic (namely David Abrahams or David B. Held) check it out and tell me your opinion? I'm open to any suggestions. I want to make it reasonable and correct. I have written a general paragraph about the basic guarantee here: http://tinyurl.com/639ex and there are notes besides several algorithms like this: http://tinyurl.com/4yqp8 Thanks, Pavol

4 36

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 30 Jul '04

30 Jul '04

Dave, See attachment. Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Friday, July 30, 2004 7:22 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U \(SBCSI\)" <jd2419(a)sbc.com> writes: > Sorry. This is the correct version of the new static assertion. > > // workaround for aC++ CR JAGaf33512 > # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ > iterator_adaptor_assert_traversal<my_traversal, cat>(); > // typedef int > assertion[sizeof(detail::static_assert_convertible_to<cat>(my_traversal( > )))]; > > -Jerry Please post a patch as an attachment. I don't know how to evaluate this otherwise (especially not during my vacation ;->). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Mini-reviews
by Tom Brinkman 30 Jul '04

30 Jul '04

Mini-reviews would be very useful. I�m shur that each boost developer/user could contribute a few small, useful algorithms. It would be a great way to increase the level of participation by developers who want to contribute but don�t have the time to write a complete library. To get things started, as Review Manager, I could start by collecting submissions by other boost members and present them to the group monthly or bi-monthly. We could call this the Monthly Boost Algorithms review. (I have at-least ten algorithms that I could contribute for consideration for the first few reviews.) We should also discuss to where to place the algorithms /code within the boost namespace. I could create a document that lists all the algorithms under consideration with a small summary. The boost members could than accept/reject each algorithm and offer suggestions. More to follow in the next few day� Any thoughts? Tom Brinkman reportbase(a)yahoo.com Review Wizard On May 23, 2004, at 6:06 AM, Gennadiy Rozental wrote: >> I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. On Fri, 23 Jul 2004 Herv� Br�nnimann` wrote: >> There was an idea of mini-reviews tossed around. This wouldn't include range / container traits (as Thorsten Ottosen or John Torjo are doing) since it's a much bigger scope, but for one or two functions, a single header, it seems an overkill to have a review. Can we have an Algorithms Review Manager under the Review Manager (as he see fits to forward requests) for the subspace boost::algorithm? _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com

8 11

RE: [boost] Re: Threads Rewrite?
by Glen Knowles 30 Jul '04

30 Jul '04

> From: Roland [mailto:roland.schwarz@chello.at] > > It is fine to hear, that there are serious attempts now to > move forward with the threads library. > > However it would be too bad if we needed a _complete_ rewrite > of the threading library. Could anyone please drop me some > lines why this should be necessary at all? > Is the new license thus incompatible to the old one? This is entirely about licensing. The thread library needs to be under the boost license and it is not. All attempts to date to contact the copyright holder (William Kempf) have failed, without his permission we are in the position of needing to rewrite it into compliance. Glen Knowles Centor Software Corporation

4 3