- Boost - lists.preview.boost.org

lexical cast and locale
by Martin 01 Aug '04

01 Aug '04

This might be a stupid question but I couldn't find anything in the documentation about it. How do I control the locale used in lexical cast? More specificly I want to control the decimal separator.

2 2

Review Wizard - Status Report
by Tom Brinkman 01 Aug '04

01 Aug '04

I'm currently attempting to contact the authors of the eight remaining libraries to be reviewed. I will start the reviews immediately after the next release of boost is completed. If you are one of the eight authors, and I have not contacted you yet, please contact me directly, and tell me what your availability is. I will schedule the reviews in the months of August, September and October. Please tell me if you have a suggestion for a review manager for your library or if you have any questions about the review process. I will research them for you. Tom Brinkman Review Wizard reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

[algorithm/string] predicate failure for CW8
by Rene Rivera 31 Jul '04

31 Jul '04

It took some digging but I figured out what the problem with the failure on this test is for CW8. Basically CW8 is doing a copy construction on the use of static_cast for a reference when the type of the reference is itself a template typename. In all other cases it does the cast correctly. The work-around is to do the cast on the pointer type and dereference instead of the cast on the reference directly: =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/classification.hpp,v retrieving revision 1.4 diff -u -r1.4 classification.hpp --- classification.hpp 15 Jul 2004 21:48:25 -0000 1.4 +++ classification.hpp 29 Jul 2004 21:32:49 -0000 @@ -236,8 +236,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_andF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2) ); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2) ); } //! predicate 'or' composition predicate @@ -257,8 +257,8 @@ const predicate_facade<Pred2T>& Pred2 ) { return detail::pred_orF<Pred1T,Pred2T>( - static_cast<const Pred1T&>(Pred1), - static_cast<const Pred2T&>(Pred2)); + *static_cast<const Pred1T*>(&Pred1), + *static_cast<const Pred2T*>(&Pred2)); } //! predicate negation operator @@ -273,7 +273,7 @@ inline detail::pred_notF<PredT> operator!( const predicate_facade<PredT>& Pred ) { - return detail::pred_notF<PredT>(static_cast<const PredT&>(Pred)); + return detail::pred_notF<PredT>(*static_cast<const PredT*>(&Pred)); } } // namespace algorithm =================================================================== Those changes make it work on CW8, and it still works on VC7.1 and MinGW. OK to commit?? -- I'll assume the answer is *yes* after a few hours ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 5

[serialization] use of iterator_facade, CW8 build fixed.
by Rene Rivera 31 Jul '04

31 Jul '04

In another painfully hunt to fix the problems with the seriazation lib issues in CW8... I tracked the problem down to another instance of: static_cast<const&>(x) where x is a template with template ctors. The problem was in iterator_facade, and not directly in the serialization lib which made it even harder to find :-( Anyway, I applied this change (figured since this is a known problem by now with an easy portable solution it would not be a problem)... =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/iterator_facade.hpp,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- iterator_facade.hpp 31 Jul 2004 18:10:00 -0000 1.26 +++ iterator_facade.hpp 31 Jul 2004 22:56:49 -0000 1.27 @@ -814,8 +814,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - static_cast<Derived1 const&>(lhs) \ - , static_cast<Derived2 const&>(rhs) \ + *static_cast<Derived1 const*>(&lhs) \ + , *static_cast<Derived2 const*>(&rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } =================================================================== After that the serialization lib builds, and tests run. Of course not all tests pass ;-) VC7.1 and Mingw behave as before also. PS. There was one other minor change to the libs/serialization/test/Jamfile to account for locale requirement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[Graph] New branch for graph library development (graph_devel)
by Doug Gregor 31 Jul '04

31 Jul '04

I've started a new branch for further development of the graph library, graph_devel. At the moment it contains only a small amount of work (Brandes' algorithm for betweenness centrality and the Kamada-Kawai spring layout for undirected graphs), but it will be used for more aggressive development as well. Algorithms will be merged to mainline so long as we _aren't_ planning a release in the next few days, but any infrastructure changes will remain on the branch for a bit longer. I've only branched the boost/graph and libs/graph directories. Doug

1 0

[thread] barrier.cpp don't compile with msvc60 & stlport]
by Sven Johannsen 31 Jul '04

31 Jul '04

Hi, with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60. I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3" and get the following errortext: ...\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero."); because the StlPort defines invalid_argument as: class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif }; With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc") Sven

5 10

Boost-wide report -- explicit failure markup not working?
by Jeff Garland 31 Jul '04

31 Jul '04

Looking at the boost-wide reports today, testmicrosec_time_clock is marked as failing red on a whole series of compilers. However, they should be 'green' (and have been in past reports) as they have been explicitly marked as failing: http://www.meta-comm.com/engineering/boost-regression/developer/date_time.h… <test name="testmicrosec_time_clock"> <mark-failure> <toolset name="msvc"/> <toolset name="vc7"/> <toolset name="vc7.1"/> <toolset name="cwpro8"/> <toolset name="borland-5.6.4"/> <toolset name="gcc"/> <toolset name="borland"/> <toolset name="mingw"/> <toolset name="meta-como-win32-4.3.3-msvc"/> <note author="B. Garst" refid="22"/> </mark-failure> </test> Seems like there is something amiss in the results reporting... Jeff

5 5

Re: [boost] Re: Boost-wide reports: Time to join in!
by JOAQUIN LOPEZ MU?Z 31 Jul '04

31 Jul '04

----- Mensaje original ----- De: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> Fecha: Jueves, Julio 29, 2004 7:52 pm Asunto: Re: [boost] Re: Boost-wide reports: Time to join in! > > > >I'd be extremely grateful if you could run MSVC 8.0 tests to > >check a fix I just commited, even if you don't upload the results to > >the Boost-wide reports page (of course, if you do that too so much > >the better.) > > I just started a rerun my testing > Big thanks! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 8

RE: [boost] Re: Re: Re: Javascript Tree Control [was: SerializationMenu]
by Reece Dunn 31 Jul '04

31 Jul '04

Jonathan Turkanis wrote: > > If we do this, then it should be possible to do something like: > > > > <span onclick = "follow_link(1.5)">Chapter 1.5</span> > >This would be embedded in an anchor element, to allow links to work on >no-script browsers? I think this should work. I'll see if I can get frames/tree_control working in Boost.Book and start experimenting with the code. > > With regards to the page refreshing, this happens when you select >"sync" > > anyway. > >Yes, but I was thinking that "sync" would be used relatively >infrequently, whereas following links within a page is common. Sure. > > Is it possible to use '#' instead of '?', so the browsers won't > > refresh the docs. > >If we use Rene's idea of displaying the tree in the content frame, >then yes (I think). Otherwise, the url with the correct fragement >identifier won't be displayed in the address bar. Okay. >Including the tree in the content frame is a big problem, though. When >I replied to Rene I was mostly worried about download times when >viewing the docs online. But if a large part of the docs eventually >use trees, it could unnecessarily increase the size of the Boost >distribution. We could use iframes, but this won't work for old >browsers. Sure. It would be a good idea to have a working XSLT for Boost.Book/tree_control first so we can try out the various ideas. >I'd like to focus on: > > 1. Providing a tree control which library authors can add to >hand-written docs > 2. Allowing docs generated with Boost.Book to have a built-in tree >control, with automatic synchronization if possible > >1) is basically done, unless someone has an idea how to eliminate the >need for [sync] >2) is doable, with hitch that linking within a page causes a reload >(unless I misunderstood your suggestion) The main steps for writing the Boost.Book XSLT code are: 1. Disabling section ToC's; 2. Overriding the default ToC mechanism in favour of the tree control menu; 3. Providing "chunks" for the main frame page and the ToC page; 4. Iterating over the various sections and extracting the names of the "chunks" to use as the links; 5. Modifying the way sections are generated if necessary to accommodate the new control; 6. Anything I've forgotten. >I think only time will tell whether it's more annoying to have to >manually [sync] the documentation or to reload the docs when linking >within a page. So I'd say two variants of 2) should be pursued: one >which produces docs using the existing tree component, and one which >produces auto-syncing docs. Once the code is written it should be possible to play around with what it generates to test the ideas that you and Rene are suggesting. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] White cells
by Rozental, Gennadiy 31 Jul '04

31 Jul '04

> > - test: ifstream_line_iterator_test > > Commented out by the author -- > http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/test/te st/Jamfile?r1=1.23&r2=1.24 > I'm not sure whether this is a good practice. I'd say that if the test > failure indicates a real issue with the library on a particular set of > compilers -- even if that set includes most of them -- then marking it up as an "expected failure" with a corresponding note would be more fair. > Michael? Gennadiy? Above test actually should pass on almost all compilers (as it does locally). For some reason it fails during regression test. Something about couldn't find pattern file. So, because 1. I do not know how to fix that. 2. Nobody responded on my request 3. This test is not critical for this release 4. We have enough on our plates already I decided to comment it out for now. I plan to reinclude it after release. Gennadiy.

2 1