- Boost - lists.boost.org

[graph] A patch for an invalid html link in the docs.
by Jurko Gospodneti� 23 Sep '04

23 Sep '04

Hi all. I attaching a patch for file 'libs/graph/doc/using_adjacency_list.html' that fixes one invalid link in a '<A HREF>' tag. Would someone please apply it. Hope this helps, Jurko begin 666 diff.txt M1DE,12!#3TU005))4T].#0I0<F]D=6-E9#H@,3 N.2XR,# T(#$U.C W.C0Y M#0H-"BHJ*B!U<VEN9U]A9&IA8V5N8WE?;&ES="YH=&UL(#(P,#0M,#8M,C @ M,#4Z,S<Z,3 N,# P,# P,# P("LM,#(P, T*+2TM('5S:6YG7V%D:F%C96YC M>5]L:7-T+FAT;6P@,C P-"TP.2TQ," Q-3HP-3HR,RXP,# P,# P,# @*RTP M,C P#0HJ*BHJ*BHJ*BHJ*BHJ*BH-"BHJ*B T,S,L-#8P("HJ*BH-"B @/%!2 M13X-"B @("!T>7!E9&5F('!R;W!E<G1Y)FQT.W9E<G1E>%]D:7-T86YC95]T M+"!F;&]A="P-"B @(" @(" @(" @(" @<')O<&5R='DF;'0[=F5R=&5X7VYA M;65?="P@<W1D.CIS=')I;F<F9W0[("9G=#L@5F5R=&5X4')O<&5R='D[#0H@ M(" @='EP961E9B!P<F]P97)T>29L=#ME9&=E7W=E:6=H=%]T+"!F;&]A="9G M=#L@161G95!R;W!E<G1Y.PT*#0H@(" @='EP961E9B!A9&IA8V5N8WE?;&ES M="9L=#MM87!3+"!V96-3+"!U;F1I<F5C=&5D4RP-"B @(" @(" @(" @(" @ M(" @(" @(" @(" @(%9E<G1E>%!R;W!E<G1Y+"!%9&=E4')O<&5R='DF9W0[ M($=R87!H.PT*#0H@(" @1W)A<&@@9RAN=6U?=F5R=&EC97,I.R O+R!C;VYS M=')U8W0@82!G<F%P:"!O8FIE8W0-"B @/"]04D4^#0H-"B @/% ^#0H@(%1H M92!P<F]P97)T>2!V86QU97,@87)E('1H96X@<F5A9"!F<F]M(&%N9"!W<FET M=&5N('1O('5S:6YG('!R;W!E<G1Y#0HA(&UA<',N(%-E92!396-T:6]N(#Q! M($A2148](B-S96,Z:6YT97)I;W(M<')O<&5R=&EE<R(^26YT97)I;W(-"B$@ M4')O<&5R=&EE<SPO03X@9F]R(&$@9&5S8W)I<'1I;VX@;V8@:&]W('1O(&]B M=&%I;B!P<F]P97)T>2!M87!S#0HA(&9R;VT@82!G<F%P:"P@86YD(')E860@ M4V5C=&EO;B \00T*(2!(4D5&/2(N+W5S:6YG7W!R;W!E<G1Y7VUA<',N:'1M M;"(^4')O<&5R='D@36%P<SPO03X@9F]R(&AO=PT*(2!T;R!U<V4@<')O<&5R M='D@;6%P<RX-"@T*(" \4#X-"@T*(" \2#,^/$$@3D%-13TB<V5C.F-U<W1O M;2UE9&=E+7!R;W!E<G1I97,B/CPO03X-"B @0W5S=&]M($5D9V4@4')O<&5R M=&EE<PT*(" \+T@S/@T*#0H@(#Q0/@T*("!#<F5A=&EN9R!A('EO=7(@;W=N M('!R;W!E<G1Y('1Y<&5S(&%N9"!P<F]P97)T:65S(&ES(&5A<WD[(&IU<W0@ M9&5F:6YE#0H@(&$@=&%G(&-L87-S(&9O<B!Y;W5R(&YE=R!P<F]P97)T>2X@ M5&AE('!R;W!E<G1Y('1A9R!C;&%S<R!W:6QL(&YE960@=&\-"BTM+2 T,S,L M-#4Y("TM+2T-"B @/%!213X-"B @("!T>7!E9&5F('!R;W!E<G1Y)FQT.W9E M<G1E>%]D:7-T86YC95]T+"!F;&]A="P-"B @(" @(" @(" @(" @<')O<&5R M='DF;'0[=F5R=&5X7VYA;65?="P@<W1D.CIS=')I;F<F9W0[("9G=#L@5F5R M=&5X4')O<&5R='D[#0H@(" @='EP961E9B!P<F]P97)T>29L=#ME9&=E7W=E M:6=H=%]T+"!F;&]A="9G=#L@161G95!R;W!E<G1Y.PT*#0H@(" @='EP961E M9B!A9&IA8V5N8WE?;&ES="9L=#MM87!3+"!V96-3+"!U;F1I<F5C=&5D4RP- M"B @(" @(" @(" @(" @(" @(" @(" @(" @(%9E<G1E>%!R;W!E<G1Y+"!% M9&=E4')O<&5R='DF9W0[($=R87!H.PT*#0H@(" @1W)A<&@@9RAN=6U?=F5R M=&EC97,I.R O+R!C;VYS=')U8W0@82!G<F%P:"!O8FIE8W0-"B @/"]04D4^ M#0H-"B @/% ^#0H@(%1H92!P<F]P97)T>2!V86QU97,@87)E('1H96X@<F5A M9"!F<F]M(&%N9"!W<FET=&5N('1O('5S:6YG('!R;W!E<G1Y#0HA(&UA<',N M(%-E92!396-T:6]N(#Q!($A2148](G5S:6YG7W!R;W!E<G1Y7VUA<',N:'1M M;"-S96,Z:6YT97)I;W(M<')O<&5R=&EE<R(^#0HA($EN=&5R:6]R(%!R;W!E M<G1I97,\+T$^(&9O<B!A(&1E<V-R:7!T:6]N(&]F(&AO=R!T;R!O8G1A:6X@ M<')O<&5R='D@;6%P<PT*(2!F<F]M(&$@9W)A<&@L(&%N9"!R96%D(%-E8W1I M;VX@/$$@2%)%1CTB=7-I;F=?<')O<&5R='E?;6%P<RYH=&UL(CX-"B$@4')O M<&5R='D@36%P<SPO03X@9F]R(&AO=R!T;R!U<V4@<')O<&5R='D@;6%P<RX- M"@T*(" \4#X-"@T*(" \2#,^/$$@3D%-13TB<V5C.F-U<W1O;2UE9&=E+7!R M;W!E<G1I97,B/CPO03X-"B @0W5S=&]M($5D9V4@4')O<&5R=&EE<PT*(" \ M+T@S/@T*#0H@(#Q0/@T*("!#<F5A=&EN9R!A('EO=7(@;W=N('!R;W!E<G1Y M('1Y<&5S(&%N9"!P<F]P97)T:65S(&ES(&5A<WD[(&IU<W0@9&5F:6YE#0H@ M(&$@=&%G(&-L87-S(&9O<B!Y;W5R(&YE=R!P<F]P97)T>2X@5&AE('!R;W!E <<G1Y('1A9R!C;&%S<R!W:6QL(&YE960@=&\-"@`` ` end

2 1

Workaround macro for intel-7.1-vc6-*
by Jonathan Brandmeyer 23 Sep '04

23 Sep '04

What is the correct BOOST_WORKAROUND macro for this platform? I'm currently using #ifdef ((BOOST_WORKAROUND( BOOST_INTEL_CXX_VERSION, == 710)) && defined(_WIN32)) which does not seem to be enough. Thanks, -Jonathan

3 3

[Optional] Inplace test is broken
by Aleksey Gurtovoy 23 Sep '04

23 Sep '04

"optional_test_inplace" fails on many compilers with the following diagnostics (from http://tinyurl.com/5nnh8) In file included from ../libs/optional/test/optional_test_inplace.cpp:22: /boost/head-regression/boost/boost/utility/typed_in_place_factory.hpp:15:52: boost/detail/in_place_factory_prefix.hpp: No such file or directory /boost/head-regression/boost/boost/utility/typed_in_place_factory.hpp:54:52: boost/detail/in_place_factory_suffix.hpp: No such file or directory Date: 2004-09-23 04:40 Looks like a result of incomplete/inconsistent checkin. Fernando? -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] Re: C++ GUI - another view
by Reece Dunn 23 Sep '04

23 Sep '04

Matt S Trentini wrote: >John Torjo wrote: > >>Could you elaborate a bit? What do you think is the window handle limit >>under win32? > >I think that perhaps Mathew is talking about the GDI object limit. At >least under Windows 2000 and earlier versions (I'm not sure about XP) there >is a firm limit of 16K handles that can be allocated system wide - >regardless of your particular specs (ie adding memory does not help). When >this limit is reached weird stuff [1] happens which can only be fixed by a >reboot. > >Any object that allocates a handle under Windows (pens, brushes, dc's, etc) >consume those resources and if you've got a graphically intense GUI using a >greedy GUI library (ie one that holds it's handles for a long duration) >that limit isn't too hard to break. Wouldn't you process the pen objects, etc. when handling the drawing event. Instead of storing a pen handle for each line (which IMHO is overkill), you would do something like: namespace gdi = boost::gdi; namespace colors = boost::gdi::colors; namespace units = boost::units; void draw( gdi::canvas & c ) { gdi::pen mypen( colors::lightskyblue ); gdi::font myfont( "Times New Roman", units::picas( 12 )); c.set_units( units::picas ); c.attach( mypen ); c.attach( myfont ); c.set_color( colors::red ); c.draw_string( 1, 1, "Hello World!" ); // uses myfont + colors::red c.line( 10, 10, 10, 15 ); // uses mypen c.line( 10, 15, 15, 15 ); // uses mypen c.line( 10, 10, 15, 15 ); // uses mypen c.attach( gdi::default_pen( colors::red )); // ... } Likewise, with the component framework (windows, widgets), it should be possible to implement windowless components that do not have a handle attached to them. This would be useful when implementing the layout managers. Handling an event should not be bound to the component that generates them. For example, MFC provides handling the exit message on the application object and not the main window object. This would then allow you to bind events to a graphical object without using a window handle. IMHO, line information should be separate from its colour, thickness, etc. Otherwise, you would need to do something like: class line_object { private: unit x1, y1, x2, y2; gdi::pen * pen; public: void draw( gdi::canvas & c ) { c.attach( *p ); c.draw_line( x1, y1, x2, y2 ); } }; which wastes a call to attach the pen each time. This is especially bad if you have 1000s of lines (e.g. drawing a hilbert curve or serpinski's triangle fractal with a fractal depth of 4 or more). Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Bugs-1033370 ] atomic_count_gcc.hpp does not compile on cygwin gcc 3.3.3
by SourceForge.net 23 Sep '04

23 Sep '04

Bugs item #1033370, was opened at 2004-09-23 16:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1033370&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Latoshek (forester22) Assigned to: Nobody/Anonymous (nobody) Summary: atomic_count_gcc.hpp does not compile on cygwin gcc 3.3.3 Initial Comment: this operator long() const { return __exchange_and_add(&value_, 0); } causes error because on cygwin __exchange_and_add() is declared as: static inline _Atomic_word __attribute__ ((__unused__)) __exchange_and_add (volatile _Atomic_word *__mem, int __val); value_ must be made mutable or cast must be added in operator long() const. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1033370&group_… ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Minor mistake in getting_started.html
by Michael Stevens 23 Sep '04

23 Sep '04

The example in section 2.2 reads bjam "-sGCC_ROOT=/usr/local/gcc-3.3.2" this should be bjam "-sGCC_ROOT_DIRECTORY=/usr/local/gcc-3.3.2" I will commit this change if look correct to everyone -- Michael

2 1

Re: [boost] [Test] Current failures
by Jonathan Wakely 23 Sep '04

23 Sep '04

On Thu, Sep 23, 2004 at 01:01:15PM +0100, Jonathan Wakely wrote: > On Thu, Sep 23, 2004 at 06:22:58AM -0500, Aleksey Gurtovoy wrote: > > > Gennadiy, > > > > Could you please take a look at/comment on the current Boost.Test > > failures as per http://tinyurl.com/5wojs? > > Attached patch fixes the failures. ^ test - token_iterator_test / gcc-3.4.x sorry - failed to paste in the string that identified what i was talking about! > > jon -- I would like to suggest that you not use speed, and here's why: it is going to mess up your heart, mess up your liver, your kidneys, rot out your mind. In general this drug will make you just like your mother and father. - Frank Zappa

1 0

[serialization] white cells (continued)
by Stefan Slapeta 23 Sep '04

23 Sep '04

I don't know if that's the same as in boost.python but the serialization library now shows up white cells, too: http://tinyurl.com/3pvzv It's remarkable that all these are results of compile or compile-fail tests and the tests would succeed if they are reported correctly. I attach an excerpt of my bjam.log: please have a look at it, it seems to me that everything is correct except the interpretation of the results. Stefan ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************

2 1

[assign] fixes for msvc, msvc-stlport and vc7
by Joaquín Mª López Muñoz 23 Sep '04

23 Sep '04

The attached fix makes all tests compile for msvc (not all run, though) and hopefully also for the other two toolsets (can't try myself.) Two changes applied, both in list_insert.hpp: 1. MSVC++ 6.0/7.0, in the presence of a templated memfuns, interprets additional overloads as if they were specializations of the former (which is not legal C++, AFAIK). This introduces problems with the copy ctors of list_insert, which can be workarounded by a) making the template copy ctor accept const references b) declaring and defining the plain default copy ctor of list_insert *after* the templated copy ctor. 2. list_insert::operator()(T t) has been changed to accept a const reference instead. With these changes, all tests build, though three of them crash at run-time (list_inserter, list_of and multi_index_container) I've checked the changes with a compiler other than MSVC (GCC 3.2), seems like nothing ain't broken. I've got two questions: 1. Could somebody (the author, I guess) validate these changes for commit? 2. list_inserter follows a strange convention (IMHO) of not forcing template params to be const references in its various copy ctors and assignment operators, for instance: list_inserter( Function fun ); template< class T > list_inserter& operator=( T r ); Any reason for this approach? I don't know if this can pose problems, but to me having these qualified with const & seems like the usual way. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 164c164 < --- > 168,170d167 < list_inserter( const list_inserter& r ) : insert_( r.insert_ ) < {} < 172c169 < list_inserter( list_inserter<Function2,Arg> r ) --- > list_inserter( const list_inserter<Function2,Arg>& r ) 175a173,175 > list_inserter( const list_inserter& r ) : insert_( r.insert_ ) > {} > 239c239 < list_inserter& operator()( T t ) --- > list_inserter& operator()( const T& t )

4 7

[utility] fixes for assert_test and current_function_test
by Joaquín Mª López Muñoz 23 Sep '04

23 Sep '04

Again, BOOST_NO_STDC_NAMESPACE-related trivial fixes, which make the two tests pass for intel-win32-7.1-vc6, msvc and msvc-stlport (for the two latter, current_function_test passes but produces no useful result, as there's no __func__ macro or similar available for these platforms. Anyone sees a problem with these fixes? Thanks PS: I could just go commit these trivialities without consulting, but I'd rather leave a trace at the mailing list just in case some problem arises. Sorry for the noise caused. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 53a54 > #include <boost/config.hpp> 60c61,65 < std::printf("Expression: %s\nFunction: %s\nFile: %s\nLine: %ld\n\n", expr, function, file, line); --- > #if !defined(BOOST_NO_STDC_NAMESPACE) > using std::printf; > #endif > > printf("Expression: %s\nFunction: %s\nFile: %s\nLine: %ld\n\n", expr, function, file, line); 20a21 > #include <boost/config.hpp> 25c26,30 < std::printf("%s(%ld): %s in function '%s'\n", file, line, msg, func); --- > #if !defined(BOOST_NO_STDC_NAMESPACE) > using std::printf; > #endif > > printf("%s(%ld): %s in function '%s'\n", file, line, msg, func);

2 1