- Boost - lists.preview.boost.org

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

typeof
by Arkadiy Vertleyb 30 Jul '04

30 Jul '04

Thanks to the workaround independently suggested by Daniel and Aleksey, the test now compiles successfully in both VC7.1 and GCC 3.3. The workaround actually also took care of the case when typeof is emulated. The bottomline -- GCC doesn't like typeof to be used in the return type of a function template, whether this is a native typeof, or emulated one :-) (after I performed some simplifications of my code, the error I ended up with is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11869, which is a duplicate of another error, which is "SUSPENDED". But, since the native typeof also doesn't work in the same context, and since the same workaround works for both, I consider the issue resolved) Neither compiler reported any ODR violation. So I invite you to take another look at the simplified registration process. Another small addition was two macros: BOOST_TYPEOF_TPL(expr), and BOOST_AUTO_TPL(var, expr) that are intended to be used in templates, when the expression depends on template parameters. These macros take care of adding or not adding the "typname" keyword depending on whether typeof is emulated, or the native one is used. http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit CVS) Thanks again for helping me with GCC issue. Arkadiy

2 1

Re:[boost] Javascript Tree Control [was: Serialization Menu
by Reece Dunn 30 Jul '04

30 Jul '04

Robert Ramey wrote: >Jonathan Turkanis > > >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: > > >I've verified that it works -- with varying levels of functionality -- > >on 26 browsersincluding some antiques such as IE3.02. > >I'm still looking at this but I have some preliminary questions >observations > >c) The boost "rule" no javascript. This should be re-formulated to be "all >documentation should be usable on any browser that supports frames". This >can be implemented using the approach b) above. If you are using Boost.Book, it should be possible to set up a parameter to control frames/no-frames generation to produce this style navigation (frames=yes or toc-navigation=tree) and the existing one (frames=no or toc-navigation=default). >d) The control presented is a very nice job - but I was hoping this might >take a slightly different direction. What I would like to see is: > >"Boost Documentation Navigator" > >1) a two frame page. Left frame containing a expandable/collapsible index >implemented by a control such as yours. The right page would be the >current >boost documentation pages. > >2) This "Navigator" would be automatically generated from the Boost.Book >xml >files using XSLT or some other appropriate tool. It should be easy to implement in XSL:T. >Boost.book might have to add a little bit to support this. Boost.Book would need to override how DocBook generates ToC's. The XSL:T code would need to generate the relevant code - which will be easy to do - for the main ToC and suppress the generation of sub-section ToC's. The only problem I forsee in writing the code will be getting the HTML file for the document chunk (I would need to look into how DocBook does this). >While I'm on the subject of Boost.book. I would hope that the formatting >is >in a .css so that I might replace it with my preferred look and feel. (I >prefer the "classic" one). I believe this would resolve the essentially >irresolvable about esthetics. It already is. The CSS is located at: $(boost-root)/doc/html/boostbook.css. When generating the navigation pane, Boost.Book should use tree.css instead of boostbook.css. The new look and feel has modified the way the top section is rendered, so it might look different when using the "classic" L&F. It also renders navigation controls at the top and bottom in Spirit style layout. To get the old-style header, you will need to add the following XSL:T parameters to the command-line: nav.border='Boost' (default: 'none') nav.flow='DocBook' (default: 'Spirit') I am not sure how nav.border=Boost interacts with the "classic" stylesheet. NOTE: There is also a nav.layout parameter that controls the "Home | ... | More" contents: 'horizontal' (default) - renders in "classic" Boost style 'vertical' - renders in a vertical box like in the "Getting Started" page 'none' - do not display the links. NOTE: this will display the Boost logo. For "standalone" docs. nav.flow also has the value 'none' so it does not display any navigation. This is useful for generating the "getting started" page and other standalone pages. This information should really be added to the Boost.Book documentation (e.g. under "controlling documentation generation"). There is a summary of these parameters, their values and a description in the navbar.xsl file. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re:[boost] Javascript Tree Control [was: Serialization Menu
by Robert Ramey 30 Jul '04

30 Jul '04

Jonathan Turkanis >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: >I've verified that it works -- with varying levels of functionality -- >on 26 browsersincluding some antiques such as IE3.02. I'm still looking at this but I have some preliminary questions observations a) Visually as displayed in the demo it looks very nice. b) I think that testing on 26 browsers and asserting it works on 95% of those in use is the wrong way to look at it. I believe it should be a requirement. "Works on all browsers" - has "more" functionality on browsers that support it. In the case of my implementation - it displays fully expanded unless its one of the three browsers known to work properly. c) The boost "rule" no javascript. This should be re-formulated to be "all documentation should be usable on any browser that supports frames". This can be implemented using the approach b) above. d) The control presented is a very nice job - but I was hoping this might take a slightly different direction. What I would like to see is: "Boost Documentation Navigator" 1) a two frame page. Left frame containing a expandable/collapsible index implemented by a control such as yours. The right page would be the current boost documentation pages. 2) This "Navigator" would be automatically generated from the Boost.Book xml files using XSLT or some other appropriate tool. This would have the following advantages. 1) Usage of this "Navigator" would be optional. Lots of times its interesting to send a page without the frame. Searching through pages without the "Navigator" would be the same as it now - tedious but relieable. 2) it would be "free". The contents/index would be automatically generated without my having to go through another layer of documentation and preparing an index by hand. Those using boost book would get a complete index while old documentation would have just an entry into the top level. 3) it would provide much incentive for boost authors to move their documentation over to boost.book Boost.book might have to add a little bit to support this. While I'm on the subject of Boost.book. I would hope that the formatting is in a .css so that I might replace it with my preferred look and feel. (I prefer the "classic" one). I believe this would resolve the essentially irresolvable about esthetics. Robert Ramey

3 2

[assign, python, range] New inspection errors..
by Rene Rivera 30 Jul '04

30 Jul '04

Latest results of running the inspection tests: * Thorsten Ottosen you need to fix your editor to not insert TABS into code, see: http://www.boost.org/regression-logs/inspection_report.html#assign - and, http://www.boost.org/regression-logs/inspection_report.html#range * Joel de Guzman you need to fix your editor and possibly CVS setup to insert consistent end-of-lines, see: http://www.boost.org/regression-logs/inspection_report.html#python -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 5

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

30 Jul '04

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 -----Original Message----- From: DY, JERRY U (SBCSI) Sent: Tuesday, July 27, 2004 12:54 PM To: 'boost(a)lists.boost.org' Subject: RE: [boost] Re: counting_iterator_test.hpp fails on aC++ Dave, As you suggested, an auxiliary function template is defined (outside of the iterator_adaptor class - aC++ doesn't like it if it's a member function): // workaround for aC++ CR JAGaf33512 template <typename TR1, typename TR2> inline void iterator_adaptor_assert_traversal () { typedef int assertion[sizeof(detail::static_assert_convertible_to<TR2>(TR1()))]; } Then the old static assertion is replaced like so: # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ iterator_adaptor_assert_traversal<my_traversal, random_access_traversal_tag>(); // typedef iterator_adaptor_assert_traversal<my_traversal, cat> assert_traversal_t; I tested this by adapting an ordinary pointer to a forward traversal iterator and if the program calls the operator+= (calling the adaptor's advance member function and triggering the static assertion), the compile fails, the compile succeeds otherwise. There should be no additional overhead incurred due to the workaround because the function itself is inlined and all it does is a typedef. Is this workaround acceptable for check-in? Thanks! -Jerry

2 1