- Boost - lists.preview.boost.org

[logo]
by Andy Little 02 Dec '04

02 Dec '04

"Happy" logo :-) regards Andy Little begin 666 boost1.PNG MB5!.1PT*&@H````-24A$4@```F@```#E" (```!H/)PQ`````7-21T(`KLX< MZ0````1G04U!``"QCPO\804````@8TA230``>B8``("$``#Z````@.@``'4P M``#J8 ``.I@``!=PG+I1/ ``*WI)1$%4>%[M73L6++>M]%N@]N%%> E>@3?@ M_.6.E2IUZ-"9=B"73+DUFIENHO#AI[LFN.>>>T$V60!1!/C[OU]^^>5/^@D! M(2 $A( 0$ )&!$"<^@D!(2 $A( 0$ )&!/YDE).8$! "0D (" $A\&N:5B@( M`2$@!(2 $! "=@1$G':L)"D$A( 0$ )"0!&G;$ (" $A( 2$`(. (DX&+<D* M`2$@!(3 XQ$0<3[>! 2 $! "0B 5@9]__OG''W_\___^_O:WO_W][W_'7_ O M^/?4[TRK3,0Y#7I]6 @(`2%P,P3 CG_^\Y\O#D."06_091'G#92H+@@!(2 $ M)B. :!+!I>7^`)#KY+:&/R_B#$.H"H2 $! "CT?@.M!\(]3=T1)Q[JY!M5\( M" $A,!F!GW[ZR1)K'C+_^M>_)K<X]GD19PP_E18"0D (/!Z!O_[UKQ1Q_OO? M_]X:,Q'GUNI3XX6 $! "DQ$`"U*L">')+0Y_?OL.A!%0!4) " @!(>!'X)__ M_"=%G A/_1];HZ2(<PT]J!5"0 @(@3T1^,<__D$1)Q9$]^SH[ZT6<>ZN0;5? M" @!(3 3`6IGT%_^\I>9;4WZMH@S"4A5(P2$@!!X) (XEVF/.&\0;D+)(LY' M6KHZ+02$@!!(0@"7`=F)<_?]M TS$6>2[:@:(2 $A, C$4#VU4Z<]T!(Q'D/ M/:H70D ("($Y"-A9\QX+G(HXY]B9OBH$A( 0N <"N*+63IRXS/8>O5;$>0\] MJA="0 @(@0D(4(<X<7!E0A,+/BGB+ !550H!(2 $GH$`=8@3+,NB@LU$V(B+ M%SW;2BK^Q%ZDZ5?=BCA9/4I>" @!(2 $?D/ ^)182^=>/V0-.@2S@HE!C2#( MZ^=6YKY-)N+4`! "0D (" $G`KXMM8TC09 ME/SAAQ_L"Z6'Y,0CH2).I[FH MF! 0`D) "%"$Y^;(KU\!W<["7\0Y"WE]5P(a)(`2&P-P*.=U$HHNT*STK8BCCW M-ERU7@@(`2$P!8&V'MGEME(!)'NG]%W$.05V?50(" $AL#0"X$7$<UA';.N1 M^#M8"B^"48N:I:R)RF>=;Q%Q+FV[:IP0$ )"8"0"X,BEJ/&:>F>=2Q%QCK1) M?4L(" $AL"@"."NR$66"4+4Y:%%+4K.$@! 0`D] `*QY?6ZR.NGJJ'_6`B?L M01'G$P:%^B@$A( 0.$5@1]9$N'E]G4*IOD6<I?"J<B$@!(3 Z(a)A0#VHZ0L.* M(H[;^Q+5(.),!%-5"0$A( 3V0\!W<4\%'1KKG'AG4-.NB',_*U>+A8 0$ )9 M"%#/FQB)K4@,!(_S,+AU(:OO[GI$G&[H5% (" $AL#T"U"WM18S8JL7NI/;X M"4YG@LX/@L3?\9NXHOFI8Q'G]G:O#@@!(2 $W A,(4[$CN!(W/ .FGSE2'<O M!A<4<0X&7)\3`D) ""R$P(!K\Q!*'APYZ\J"7,1%G+EXJC8A( 2$P$X(( 5: MFH!%Y7-WP%8H0\19@:KJ% )"0 AL@P#NH2WESJ66)U.T(N),@5&5" $A( 3* M$3@N6\?2(-8(C]_G>9+V7VT%T=*L"^X\JGK=LT-=SF=IP%XR(LZ]]*76"@$A M\!0$L!S8WB0)OO\,6K6\6XE=K!##7B$L2:((5B4O2-<>H:+Q]U.8B/-^.E6/ MA( 0V!4!D"68LN+:6'!AUL8<ZOWJB3?*UAF!B+,.6]4L!(2 $.@C@"7 %NK9 MPSBW9 IWXN(>>P,LP6X?H\4D1)R+*43-$0)"X!D((&XK"BXO6 VQ;'RK#G6W MK7&1=2^=BSCWTI=:*P2$P/8(@$MP=9P]:,N5Q!Z?(()4XX/?6K.XB'--O:A5 M0D (W V!EI*=?J-Z?+>.?0D6DG?3XG_[(^*\I5K5*2$@!!9"`%G9,4N8EM@T M3IR6KS09Q*8+J2&O*2+./"Q5DQ 0`D+@CP@@RER',E/(C'I-Y99;:A5Q:I0+ M`2$@!*H0H':?VL.XH&3P,4OJFJ'@MZH4$ZY7$6<80E4@!(2 $/@C`LC-4G?K M!+F0*A[4%;6E-N7T2[#!%<5%G!6HJDXA( 2>B\" ]T8HIGP5CN=.J0G!78U MQ'E7S:I?0D (C$8``99]QZF;_-P%L=H:1\3^]?@NI'AKBVH0<18!JVJ%@!!X M%@+5*YK@(3!?N[?]]7>@?+UW%W?/QO5!O4&6PM/Q-E?4(.*L0%5U"@$A\"P$ MJ"TSEJ -D2LX$M6"(ZF[?B ,"C^>3VF54#5<:$Y;:ALX(LYG#6_U5@@(@70$ M$ED345HBSZ7WE%J^O>5E>R+.=*-2A4) "#P.@?@Q3=PEA+APBPVH5&>SPMP% M34H1YX)*49.$@!#8`P&*2#XSM,C'[O5XB+;4*N+<8V2JE4) ")PA<.R1F1+< M1%(a)3#+1C)M.R.MMD;KRE5FN<"1X)"18,`*3^\</%C.UW=H\S)IA-H,FC+#;" M)32B5\7K?K^[7KO<PT#_OS$"&":(S)#/Q-B!1[ZX)QW_BQ\&5_7(HE;[7OEF M4\J$]5#O5Z=LXEW69)6JY50#JL,`ADU0#^MTIVD82Z@3-5>,]K>;/FZ\1YS3 MI:271P###?SD/AF)@D4,2E'(Z_#?*S'[9B#4>9NM>]H=&2+.+D2_(*!L>[N[ M_)<ET$+2E,T"X..W5MW;H/OJE,3R"&#$P6X3G]_"X,V=DCJX'(-Z2CXY4=O4 M97N)B>AV/O7PP"UO-W?OL8CSNUU!5:"ND61Y1KK-1!S#_NRVS!0^3AR-JDH( M' B4/E<9?\"YM9/BCS:NZV:K(..W^Q 2&>O-,JDT6XI5HW<7'P6#SIJ+B#C_ MH-_TJ6Y6#(IZ, ''-!S9DJZM0. ST#Q:DF+0JD0(Y")02IF'\<=#3\P[V4&= M.%5%5<?E!MUFI(=E]C@;SBK%/+I?A( CJ(BW3<3Y*X8PQ]S44->F@P(P%^0N M6CKW&)9M_?5ZI]]=WY6-CP35, N!,93Y.N+<KA934BJ!G.+6V\8H*MI[<R_P M"=W9MD7[=J^5XF<N9O^O+9FR"^G1Q ECBFP]L)O1.I+QMQ$L`TPR0L""P'C* M;"/1G>)C;PB*Q)J(+'-G\\%,]>#+]NS;K[*B6XO%'C(/)4X80>0,UCI$R+:D M;OV#,CL)/QR!Z:^(^$X94F&?;ZR!+^M<4V3>3$T:XN]74PO)XT?3XX@3&NWF MS5DVVDA^O(7IBT+@#0'W"<C<@<:>RRI]&*24+U/.PU!,%@FUV]H9I>OQ0^Q! MQ(GA2JU/4)IKPNTXYMO2XZM2D7]HR_OMMH3J]KQU05<?C!]@^N(K`M>;)!TC M+EB$"@JID,M8\S"^C"_Q4D<,(F;/LJ92M1&T3\MBK&*N5$=1[?4?XSCY;"6H M%,7'!,%35M%+E*I*-T2 6B0+,J*Q.)6PI?*TU_H!-]3E8[M]IWK]^ZI>M][_ M"?CJ;Q]B61/?#*[=^D;2S2/.NJ10.QSBWI[WJ:VVL]=LG![!NL-D/N-3J><@ M0"7Z/,;M+6,<PE2>%FWYNHMUG=-N;"J5ZCZ;`S]&`173'PI/V3#,CL3;$F== M8A;187SI^TQ/UT<PO<[AMW)&'\':D.2%P 4",.DQ"17?Z#!Z>=:GMS.4QT76 M5+3JZPA5BMTE1&4+V,J;\; (M_ZZ4WW!,7M#XJS;XUY*F:^*Q'BC5A2,8R9H M*RHN!%@$*E@3P[!M)H"#QI]Q5K9,*"=F5HVCFQ)CMSM0J3L'F?E8T\?0K U_ ME;\5<=;M<4=BMB[*/%-D;G8KY4ARBLVIDH<@D,B:[=W*,X9KU\ZY5SHL2Q@5 M$UF*ZM*%*2.DL*5RIQ#V34J,J0*JFW;AFQ"G&WV+.4Y9?&XJA#O(VM8TL1=V M<Y1D!(&YCU.^M3R%-6'\F#Y:(L)(NL_B@N]'G'94@2W5?;L-NT,=B\KLS7!( MWH$XZY8SXS=;.E3R5@3VG<*=COQ)O/&JH0*!!1^G3&=-A)@^BW4D_2SG&59; MI+3,^*]E*'CMG[-OJ75HJC5C.FO"VO<FSK,'0.QJOI!<)T1+X<X*#SZ]SK;Y M`K_VRG$[%X0?E2R:W@MC`Y9]G#*=-2VYTPO0J)TLS0-TPZ_<=9,4!Q6LQ+ZQ MUG[['9ID.?,621"NP)I[$V>=*:=<S6STAD:Q('>R>P&,K1HI=KP+@;F_<3_( MZRZ2\4O46>"DGV$HS:,$,[1PNRF3'J.%'-S3-0_J#><@I5T41[_:$TE'O BX M?+>AV>V3FHAT)ST1)-<)9K:,.$L#S45F-)]F'>%.RS30/I &2+;M'I@;V6G2 MXJV @WVB/:";UY^HVQ\.K"I\4(0U00F)JJ%V@0(-R_[,E!43BY5^RL I==\3 M9)MG-V\J1+G(``?]=I>2[3V*2^Y'G.R0H"QU*=U\:M<]6>M.J..6%*^A+=VE M'#"X5CK(N)N:BW<G4D,I91[@I(>>ONV1;=4J)= \,*>RBT;BI (ORNV<"3>^ M-!H2Y1BI/?;4^NY9:RGV_00D<5)EQ/-:;#/BI%1(V2[F:]1J>0KZCDI\]E?- M$_!Z[<G UQ09_'+W,D(T# ,>#H*=+U/*_2IL"3(<"@H6&4.9KX!DV89[5E<1 M^T(+5+;62"34YE*WB5)\>=@;M=>&PIQ"\NMT/S*ZW6_ !4?B38@3,XX(^M=& MC)JSW$>IMEKEE!VCXY9-@^YF6Z[M_IR1M/L%V8ZX/='%C-[=\?2"XRFSP9+B MF-@([]!(W6R5BL",>T'=W;28;KMLR!UY4^$^Y>XLC6\R;ZXF?I'+LFM,>T2< MU&3*KN8F:1PSZ8[272%[#[)Q-NUH#X:?D?R:.VA\63<!8E7?DH2.CN<6<9]F M<_3W:Y'X$'"$8KF+FI\:H3*K=@32?5&0+X^.VXV!VBK(>AO CB) R6$2;UVP MIZESQZ.EM@V(D[JTPFX]F[)F4RJ5LJ;2,A:C:3+4[!MDN11?OMK)W)PM%1BQ MYFV7CTP@',L', 9W:&4TT2+B;)8?9X4LOFQH4'ERRB&D3Q0L-KG@N88WJUN= M..,&>J$G^S33.%:'B5'3P*)U]=()C65T)<I0F:LL+5NRW(E][%;ERYI2IGBT MH<@F7U5#$:<C)>B8\6"ZX%N_[)H<Y2<I:W?,BKJ6=BT0F<-U@<H26)<X(Z<O M+)K;ES79H#/+5M[G7!:4-Y$9/U8IMSX&1<>(`/<[$(a)D#6!.V2H5*OJS#L0_\ MC+?:26)4WCU,$AFD5$_9'0\4)<<-=?%S#;\GQB,*JRM;S9I4EK^NFY&:C3-] MAS>TM(H:J_'A5%T#ZTTL$%W(C)_%&P&D8A%TD-J0TMHP;.&*`CG%7P.]=G%5 MT#RHXNS<A9TB."9&1F-[$TL_'$7!R JO&'%2^7J'DO;:0WNA4<O&'$<.RF)# M#H_IT-3((BQG6%#ZE(E<$3 `#2KRIA:Y6^-3^,F(/+64,)CMC%VPB+$CD5I: MIMZOCM@GM>QJ@:5:9CGBK&9-:'>,BZS6G#$9533!'YS B8Q)8]D!KK."-:<\ M3MELFW7917.XLX%FF58>MC% ^Q4.@9H<H+,L/PU84*C>7%T!.^I<BS@'L&81 MD12IY[I:RWRP:); .DTC>TT4JW:=B:PY_7%*F*4CW*1BG>" L@R-5V,+?FY* M<7:YQ+$^Y=@`10UA-F\\!>>O'UV(. >PYKYZ.K.8Z\BO;NEN@++>1B#Z@LYB MBMU>0?G\X;\@X Z%2XDSA377>9S2$6X.GK!2I%(W3.H</=7!-I0<%DZM$U.4 MN6F@>2AT%>(<X(CK[@&H&Q[=FJ_'#[5DU?W6JT#U5!2#$$,+[4<'V4V88"G' M@&>_8H<KSIJK/4[)AIOCAQZ5$6%SR.TQNZ)<CL6NV PM1I//%3C&D84^V8RQ M!9/!,DL0YP#6W'%2:3&%:Q=69Z".H6L94?"PW>MM+;! AJ+V.O.(LV9P0XUC MF:I+"10M0>\CD[3-/*B]H,9H&+!\7CR".0TLK8N8T6B[8D#2EU/QJ2"=.+.> MC>L"52TPGS@=`]OB@M]DZN*):@UUZ[_P$76]]HW>KXI#^]L3@]V>4@)4+LLW M'^^V)\B:65Z&VB8#'5WK@ET^K)N]G>%O/*EU6&-7CY9YF(^9+)\^9-Q7,[KG M7M3L\]HM[W7:I*N7R<19?5ZSZ?)^2YNO>KV8_G?5[Q9PS%W>BK0G>>NHG6(+ MQ_)/%[H(:^:N`+'N[WJ\4%%(72A_(a)3\5$%OF3)8N.[;>=$WH$/"M/K019^G@ M64O82=)7MP#*K!A?=O0J)&<2)WMTU^>LBVX`J%"&K\XSMUC7<7:)ZTUQ<$/5 MJ2TJC5$$%.6^7R%:^7%*UI..#S=9X^Q&8W9;*K)J) "HS/.;+?F\RE'*,FDX M\\RWI,R&S$SB3$SW77!JD34'S3&Q^%EBJB[.MKN25[U@\$=>3:(0HR[![[I. MZM--V+UL7\0T5/Q]L9>'#5X')##?M,/.5ZY;2$T4TN.JX&WR64&P@[:AA;ID MDF,\IA>91IRL??O"S3KR2-=$I,*OX*2O&KHGH9@AU37F$S?*N5>$FVS0<Z@O MW?,>X&1A0LU((DE"WW!@D>]N]Z5P2YPEH".14*]M2L]J#QIC=->#MTKYC"2E MU!SBI,S11YG-=%(P6K^2KU/"K&'SV7WC*&J**PJASI3"1L,5\V)'*B5W4?,3 M' J6B\D$-1C')WLHRT1?NC,5>Z2>Y6TPQ:1F)V<:21_^C3X_;;O=735R:_$* M#GD"<;)[WJBQ^BI<X1-7T-EG&SY'6NFF#+LWL?BF1$C9(a)(,]P&=IJB-0V.5Q MRBSVM<#HD&&UWPV(J0J#R:T68CJ2HI_NL7H2UE0S]R2KPSQRBXPFSC$;@H)[ MR1K$GQ:9"WUB;9^G*KM.(?)U:BH3^1!5%O,DRN]DA0BOC?1-"@?,\"C..YM/ M4(=W*U:.K^V!FL_!AKL!,9L8PZ#KUOG:!3A#Q)?@2[;E%P,0<^CT6),:A@\1 M'DV<*5F(KN-.F<)O1)R?([PN04IQ0P4Y?1V95*N:9BD?9W$'ODGA`-9$XZE3 MK6?!$^7?T^&]5@%%ZL:)M2-YT&H^N^ZJ73D$LD1K*3"['J\)!*->BY%+YK>P M:B00[ S.:"Z?8BFTL1%Q?N[AK'/'U'[1[N:+%/.C6*&IM6*S$KO 5M2,KY!2 M'/ U6*3VEPZ;,+7.4C9IGS91H%TX*RH1XG9Z%2:=,CQO6<FXB)-:,'!;#PIF M#=J-B/,SWJHS5LJ;#)@"4^UI.JW((CK,NZ(99WJG`K*O6V:HV4G%XO%9UQS( M&\W285H1Q^4NB[TY=1/E.D^R=<WCB-.QU=!G25DSKWV)LS3.H_28I8NS]*PC MWU5$5VRX.9):@!X%U%?BI#I8JO<W8Z"ZU@:U<1700<D^EQ4I563/6[/:U\:_ M@ASOW2#B'):DS0HW@>Q&Q/F61C-.J'W60^6=ZA:Z?-% 2@[_$S>'AS7Z;I^. MWDI165:8_=>/4GH?UCLJDFXCFAH=U#0QPG^.LNC(,)Q3['!*)5^!C;=D!'$Z MW(K#C%J1[L$L.V0;$><;S2>"\ D7I1H[VG;)\5===]M&16,`<&1 AL936=:O M!YFHO5>)D]=KY*E^-;ME[[MP?((:(#[AFUV8WAU?K$ 75;;"+VXP7D6WAC$[ M:0%6;HIR7^*LFX=2IQI8)]4U)/L-)I^ZJYM,L//"7"OM@@8!BM>_YI I_AC3 M04>LZ=ML/\Q]==T]!-"%.DNVV-*R,A;T#IEX+\HC3L>&-PJ"5^'<%?*]B#-N M"I8:J)1[XEG2R.L0U>?!*5J"4=5-:\XT2&59OT;#5&*<RH5:K.Y3AL6\C66? M?XB\<N-V99\%,0W5<F8P`;83<5*#-F)GZ?-<$>>GF5+3_)0%Q0AE0H-93UJ> M^7=V^3 %$XILJ"PK$/M:.15U51.GCS4CR+M7!R(.[2A[^PO3*7M^6Y;R(<Q^ M<72JE@I0?! <I7S3R0L$19R?X%![)8(Y):1 *9Y^TU=UH-G H4*QTGL0SRR9 MHIFS) &E]](57*H[K]P3])68(5&SAZ W:\6U_>=5:RF0MDJ"QO K><>KR)J, M1W"IV(\@X@PF1GPY291"2LIQQN!57Y'PPCXBU@\WV?77LV0@-3;KP/>Q9N([ M(>C:@!2:LK+'&*0,SRYL'^-GDH7$&0D7[! TR8I)KHCSS6A8+\Q:)R)4GV<\ M--6>_&2_ZY9G$RJ^F82[>2C(XGG60FH\5J1JT3"V+W6Y*-A8.GVB0G00?FR\ MD40,K*(L96P^X7BSJXB3G8S[^M]*582;7S/I<;BWKJ%B2VV[YQISK+@G0B7I MZ?IK?5&YN\2M4D8K8B<Z%[L$J.&9OILZLL18-Y%"J^)V"\R?]B#7:0Q'&9E+ MV#AP+&)5Q$GY%!<(OQ<J&ANS(LY9W^V:"[6>=QUV@(-S'X7X:D(@8SAQ>#?X M)GPQ?2Y/V6W=71 IJYOHR\6:--73ZZJZ9O8F$-F67^09/C,Q@ XV!I.&W_NZ M'MP>K<3_0@8_="JX`X"%<4%YUJC<\A5]+R%.=B.?&Q$4K-MP,8O 9GVW:UY4 MKNS59X$SFF<!AU';3"*&\;5L6SU*8="*^+NK`KL`&VY>!\1L/B KO(XL]XQA MS0N-P T.3H'8S6.69/J(/JNPNH,EQ$EYV""4=7=^SB*P6=_MFAJU8:<]%D\5 M"5H"53Q^3(7RZ>.=.(O\=4#L2" %(VS,2]@NO!I Q::'[@"1P%<$J($9$1Z) M?SYQCES=!,HIT8-1WV,4LRQQ1FQZP;*(HB+NE7+K019A#8\B=:BF&R!26?JF M:TR;?&,36#EX^M7 %.>Q!I,N/W*\IS?>4F$^<;*#-@)Q^J4'KY#-(K!9W[TV MEY'I]XA)L&6[G/$5%FIV6+1Y[4Q?CD7!+J\[ZFR*H*8FL+%XLDJL:?'[%3+L MT(O(5[2?JC.9."F'$@'.,2PI7" \B\!F??<:'[?KC&NYN@8'=U)WM]:M)GRJ MC%W:!+:6TR.1<8W9+?*N9]S<CNW&^;(9B5B3]7)!^>JQ^59_L+6)Q9.)DSW9 M%L&];EM0PW<6@<WZ[K55.9)U$>4.+LL&A92CIZ*NX-BF$L@-9&-"E>KRF?J0 MOVT_1SN[)B'6#!J/I7A7"^D"EE:-ETDF3G;W701ERTPY`N@L`IOUW6NLYNZ& MC=B)L2QE3I2=&YDI8JNMK&.5Q-YK1RQK1#XNEG@W4%P+]ZLAKB"VAO4QS"3. MP=F\:W_$JFJ,O,4@UB1.BBK&@)G^%>/1.FJYEXUE+1;R58;*'C?HV)L*@GMV MTO75*D0H/&QJXM;.7(a)6+--6M=B.4,HESY+CJCOFNDJ8(6"QC3>*<`M?@CQK? M:Z0HJG3_VF%.CEC3V-E7BZ5F#&-T-_Z<CV4([R@S1E]O7]D1J-\6\K*:'MD^ MX-!9=]W(4>> (A:T%R1.ZK#_`!CK/F%QQ-1RKST7:K&-KS*^U4??BN#(30S7 M6A[S^HU;*>L7K!M$US6OCXREA6D1Y^ 1U>W;++.(&\V"Q#E8N1-U9PD0J<Q* M-7'Z6#/R@ G5_2)5QN^OZ#J0^PD4Z<)2[0W!S.I2Q3:Y,Y58S@]8U#E>QH+V M@L3IR 2RV+;-ENTF3P2XQ^_BB"&2'$WLN":4_>A7^>Z"&;5/JIL:L9C$F8R/ M-2W#YZ)5@W-+;SI"AMFX%!T!]AYE4X:#NY)[8'C6BYR(<_"..XLS<NN[M*#% MF!8D3HHJN@!BC@7??1"D!1.[#$PQ^)QG-UO;[>"K0"2VN^ZUCS53-J#.6NS4 MP\[7)D%99H6P?9SN+IE#G-2J3UQA8T"?16"SOGN!:E!E+93$=,>WKN93M_NR MTVZVED*C(E6[PN.4:,/()!.4TKW>R&<G6Y>B3+%(>&L`W8W/(<Z10RB8:+(C M-8O 9GWW#!E?.J&]0S+=V3G"LMP-V]W:[ ;9))=ZG'),#E^YV<-(BLB/JI:U MV%O*)Q#GX#4/2YXV156S"&S6=\] <VRI'1E9=G7-YIF[5$=Y&0@G^OW(4>EN M"KJ+Y%<!ZG .!5V[J\_7JMN4HA"K$[X-GED=22#.NI'SU0ZR>MZM9Q:!S?KN M&2!L'GXU9\=&S%WB9.^"R,J11,*[(M8\; ;UL["<>7FDK]#3Z;F*KG^H$*AC M/K;FBM[=J<X$XARY/;WKU!)U,XO 9GWW##HJVSE2079=4SZ]VP6'P0=IP+U> MVVQI6)(&[63C^];"1I9H9W=+LUWI6TBR?%8JOP5BBS0R@3A+=?E6>=T>Q4]] MS"*P6=\]LTAJ`;LZLO$-&\J;=[?SL"$X%/JHQRDQ2SC."+W=YWY<\H[)1SMZ M]#2R'.DMN]_RC2:5`@)1XAR\,3TX<Z=4/HO 9GWW#)SN\'L5&*D@NS8IXNQ. MSMP+C53DI\<I[?I=5I(:.P.$EP5JNX9%B7/DG3+5[XB]*6\6@<WZ[E?;I29& M@Q5D'VR42^KN;(KLAM/CE':M;2=)F=D8X>TPW*7!4>)TK/>X+29KDX51-SX" M<_>NM*"QRY]B5'35/0'I;D:D(-4%(_=3Z[YGFM7CE!&U3B];.F#=E4^'Y2$- MB!*G6\&.@H/7ST2<& /4>EYW=7#*H*)(SC(a)Y8W?J.JS=723E;J IFEKYHVYU M5!=<&;0;MRU$G(/=Q^#U,Q$G[)Y:':36\,8,*C:M:I^<C<RUV)VO'J>,VY4= M[2F2\0ZJAC@"(>*DDF!!(S/FT.*('#6(. $%=9!C\,S&HFOVD+&]"]3J;]#X MC<7MK&^![B$R1FPGBCU$$7MU,T2<5!XO:'GCU\]$G#!E2FL+FCYUEL:8ISVZ M.7)GW+4B]#BEQ?8H8YXE;.F(9*8C$"+.D=FJ[B&!="A%G-1E>]U[`](5U*V0 M);;N?MK/+XX<`F>N7(]3?NIE%NTYOMLU8PDLB$"(.*D\GL.D7HLXG%H0;A]Q M!C_Z-<B+U^FK@2(>-ESS-<E>BEV ]Q$_NX8:' 5OQ?4X)9L4R<7?5YO=AB6Y M+ (AXO39C:_4> 1%G-3EJ.-3`A<FX7CTRGW%[JS%SF<^3NGS'A-+C7=<^N(` M!/S$.=)?8 EG`!9OGQ!Q4EMJW<13H5GJ" H4[0LWCY8[>#KBRA_R.&4$HEEE M*XQ9=2Z(P![$.7YGT,24Z2S"#BX4K7,]MV//6LI"`!6@^SP["'ZI"4JB1_,! M,K=48O=5U5X(^(F36@`+VO>4-. L`IOUW3?#9=<(%[%[!VLFWMO GGZQCXL[ M/4YI[_52DHM8N)JQ`@)[$.>4D_6S"&S6=]_,<<<MM6R&%E!C?TUZK*S'*5]M M:2GR,S9F!=>L-JR,@)\X'4[*:+6?8BF9-%8-LPALUG??\*%"M\2@C573(>\S MR+K,YS,?IW2/\8D%W2:G@H]%P$^<(T^P35'/+ *;]=TWD"D>FGMGC7MO#E8E MJTWKQH]33J2ZR*>K-:[ZGX" B',Y+2]"G+MLJ:52RJ_8!G?2+F<WQ0V*<-7$ MLL6HJ/J'(N G3LJQ1D;.E"VU$\UA$>*D5#8++BJ?_-HC/2%RK3)*^XL(SS)" M??>!"/B)<]AH$7&.MTOJD.[X^_<!"%I(W4/[9J[I&X+&ZRCWB\.&<_Q#N1U7 M;4+ @< &Q#GE+(H#RJPB*T2<U+LWXV<V[D"S83MEKUF6>:34$V>O,36D=%:5 M"(%T!$2<Z9!&*UR!."EF&KFE%BN:P1N2IQQMBMI$K/P8DHM_)=9+E18"XQ#8 M@#CG[M@<IXK_?6D%XJ2V3(^A(FQ/I5KUU8\_)-:,<UAU#>.'E;XH!!(1V( X M'^+L#J6N0)Q45%>M(*Q'4F=CSIQ^=3L3AR5;537/!>MGNR-Y(; X`B+.Y12T M`G%2CK(.05 FE30^:_;]WGFF%#18N,X>5+,06 0!$><BBOB]&=.)DSH9670: M,HLR`>8]3IX,)C_CYY8;/&J0$!B"P ;$^;23`].)D[JI//W]:JQEIB1F&XQ8 M%MW1?HR\-5ALB$?21X3 !@AL0)P;H)C:Q.G$23V/E;BE%I%N?/O/*WI['60: MS(+=SZ4:M2H3`K="P$^<PVX.NA7>ALY,)TY*LRF7I"/&C=QF\(D8-C=ML16H MRUXC!0RV*1$A( 1^1<!/G+G!P86#>)JBIA,GY:PCB5!P&Z);:@>OI6V+IV<M M71@@\[1AI?X*@40$1)R)8.94-9<X0824UW;T&:N82**F\V5K]H+I60K/(F&' MFE1$" B!,P3\Q$FMA$7<@90W$H&Z+;6@9+!:;DKVU:Z0808EC\3JXEL1@T\I MNP@.:H80N"4"?N*$$TP9X=U*;HG[LIVBSDU:WK,$$Z-.:MVT:Q*?`F-N+[K6 MFJ/9B466M2@U3 C<#P$_<5+W@$<<Q/U 7[E'U%&0L]L0L7B)>=6857"0=V2= M-:B+B&$'RP9;KN)"0 BX$? 3)_7R5,1'N/NF@@X$J-#PV%*+OX!$!T26KX8T M\3Z@B#V[RSJTJ2)"0 A4(. G3K3&[0*H@A7=5IUG"%"J`<L6[?&Y;(a)8^.O[J M?PJ9N+!,5 @(@641"!'G&*>YQ8&\915,-6Q8%B'"*R/WS4;:Z2A+*4O"0D ( MS$((a)1)QC%K%$G&.,`RN%=5M>'2SR602IX#'+F2FM-58R1KGZBA 0`HD(A(AS MS,9:$6>BOB^J&C,-,M+)F]A7RDRYM.@`Q-<P7ZDQ"M57A( 0*$(@1)S4F3^? MBT&ID:FY(I37KW;,',AA`]51IJ-)CB+K&X!:* 2$@!V!$''B,PXGPA81<=K5 MZ99<+4F+;4>EVW]8(W3(NW6A@D) ""R.0)0XJ=,+#N^#(D@A+@[B[LW#A3L^ MU:27PG8SRZ4*;L#3&_Q6H;MA*B@$A,!&"$2)D[IHQN>V$ QM!.B.35TA3XN+ M%^H6LWV&9RRUH\;59B$@!"((1(ESS#)GI(<JVT5(a)P.SG*PEA2H1/BR^["I* M$! "2R$0)4YT9L!ISCK?NI0R9C5F,'$BN,3Z9=W!$F.DZ!";I2!]5P@(@:40 M2"#.`<^D:']0J=$,2!M4!Y<-'P<7=HN4(J_*A8 0V!&!!.(<X':?MC_H[0)] MA&C5ME6QR0MU8E)5&ER*+ZL-0_4+`2'PB4 "<:+2`8<9GJ.\MXD(,N$#^IZR ML?9@RC&I]6ZPR H,P%F?$ )"X 8(Y!#G@&V9N=?$+*LY$-C;FO&PCF/1D7I3 M;"*&+"->RT_LB#XM!(3 C@CD$"=\;JXO^ZQM0+IRNOX^61/;=@:W"FU HAC? M1985$>3Q0[8<_XC?Q">C<VUL,+#ZG! 0`K=!((<X`<> +4*W`?VL(V^Q)DCK M]ETV=C"1,HU?E)@0$ )"X R!-.),622[]H^E=[!--Y'/[3F ='JKIC<@BS*G M=T0-$ )"X#8(I!$G$*E^7N/&5PA]LN:]9PG=\2.^[$(D`2$@!&8AD$F<`X+. MB0ML=1KZ9,TG+.B>YD R.+-.6:I9" @!(9!)G$"S>J7S?D'G)VL^=FDS@S&3 M[5D.0@@(`2'PB4"RH\'VVNH;^&Z3P_S<0POF`'I/6]H47\HQ"0$AL!<"R<2) MSE>?Z1QS(4"U%K^R)BADV*G-Z@Y:ZH]3IN4KDA$"0D (Y"*03YQH7\7];:]. M=O<E0*S4?HW+'W4E;Y U<X>!:A,"0D (V!$H(<X!NX3V3=BBY5\YH_0!9[M! M#)",4.: YND30D ("(%K!$J(<T#"%LYWQ[7 L\U3#]D0),J4/Q("0N &"%01 M)Z"I/M:YUSX:T/Q9!OL)K"G*O(&S4!>$@!!H"!02)VJOWF&["W<B/7L&!?Z] M[DGG%:S<39DK-%YM$ )"0 A\(E!+G&=[1]W.]+/@XMP)4KR(O!=O?'# N+4< M_*Z*"P$A( 1*$:@E3C3][4UFMS.]* CZ&?,`)*N)BT#S]D<V?8IF$9:\$! " M0F \`N7$.88[X::7.LL!(K\^DW/C6--!F>/M7E\4`D) "+@1&$&<:!S><73X M4[8(DJ+3UPM!F=U=47=E359?3=YMNRHH!(2 $)B"P#BW57V-[>&U9X6>%LJ\ M:X96E#EE].JC0D (3$%@''&B>]6W\1WN&R'=2/K$6B9NG[>0!\1V/'YZ;9J6 MCK_)3+%U?50(" $AD(+ 4.(<MM[9W#3H$V%N'5%AWQ,N_[/3QEW/:]H14&(V M9="J$B$(a)!.8B,)HX&W=6G^]\<^6(\[#(FG)_.BI!58[+>&]\HYZ1..<:NKXN M!(2 $,A"8 )QHNF(`HVY3:-3MHN!\Q F(I$+"L2JY%D\BG_'_^('2?RPWR?2 MX)%YXRS+H.JYQI^J2L)"0 @(@<41F$.<#10JSVFGQJ4DESUCFFB78LU$,%65 M$! "ZR,PDSB!SME3(4N1G[LQNS]_9C3?,WR,Q24F!(2 $-@+@<G$V=*VW8./ M;NJ:51"!)I9R]S(%=VL_0797I8)"0 @(@?41F$^<#:/KV^EF\9_ONS?>!W1F MT =0ZUN\6B@$A( 0""*P"G&V;HRY8,A'AY92")W7O#4W:"4J+@2$@! 0`@<" M:Q$GFH4[\X;=,63A0J.,*%.#2@@(`2'P$ 26(\Z&>Z//P<<]C1SY)H8=0(HR M'S):U$TA( 2$`!!8E#@/W6#MTW';@(\"J5+M4H7I=\K+B(6 $! "0F P`JL3 M9X,#.V_!4I$K""A2O!!NU_BE7$(T6-/ZG! 0`D) "*0@L =Q'ET%@R(&'7]\ M!5_$[3]UU]ZFZ%*5" $A( 2$P `$-B/.5T3:?7A88JS(Y:).1)8@::U?#K!" M?4((" $AL!$"&Q/G&\KM=MEVM2S8%#%B]X+9)H,?.!*E&DUJV7(C\U53A8 0 M$ +C$;@/<8['3E\4`D) " B!!R(@XGR@TM5E(2 $A( 0\",@XO1CIY)"0 @( M`2'P0 1$G ]4NKHL!(2 $! "?@1$G'[L5%((" $A( 0>B("(\X%*5Y>%@! 0 M`D+ CX"(TX^=2@H!(2 $A, #$1!Q/E#IZK(0$ )"0 CX$1!Q^K%322$@!(2 M$'@@`B+.!RI=718"0D (" $_`B)./W8J*02$@! 0`@]$X#^OQZP]"K)^:P`` *``!)14Y$KD)@@@`` ` end

1 0

Re: [boost] Re: Re: Re: [multi_index] announce: serialization support
by JOAQUIN LOPEZ MU?Z 02 Dec '04

02 Dec '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Jueves, Diciembre 2, 2004 0:36 am Asunto: [boost] Re: Re: Re: [multi_index] announce: serialization support > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote in message > news:206712203b1d.203b1d206712@tid.es... > > > ----- Mensaje original ----- > > De: Robert Ramey <ramey(a)rrsd.com> > > Fecha: Miércoles, Diciembre 1, 2004 10:15 pm > > Asunto: [boost] Re: Re: [multi_index] announce: serialization > support > > [snip] > > > > If you guarentee that the container itself is always serialized > > > before your > > > indices, then de-serialization of the indices would automatically > > > be reduced > > > to providing the original (tracked) pointer. In such a case, I > > > would think > > > the whole isse would never appear and that the implementation > > > would be very > > > straight forward. > > > > > > I think this is not correct (but I'd like to be > > proven wrong, that'd mean I could simplify my code.) > > Consider this: > > > struct foo > > { > > std::list<std::string> cont; > > std::string* pos; // pos points to an element of cont > > > private: > > friend class boost::serialization::access; > > > template<class Archive> > > void serialize(Archive & ar, const unsigned int) > > { > > ar&cont; // before pos, as you suggest > > ar&pos; > > } > > }; > > > My thesis is that loading a foo will get it > > wrong --pos won't be pointing to an element of cont, > > but rather to some random address in stack memory. > > I'll check it out on my compiler tomorrow, but I was > > already through this when designing multi_index > > serialization. See my point now? Am I missing something? > > Hmmm - let me consider this. My view is based on the test > test_list_ptrwhich serializes a list of pointers. In this case > each list element is > tracked because its a pointer. when a pointer is de-serialized a > secondtime, tracking assures that the pointer is reloaded. > > In your case - std::string is tracked on output. When it its > serialized a > second time, only the object ID is written out. So when it is > read back in > the second time, the serialization system recognizes that its a > copy and > just reloads it. > > This only gotcha is that most primitive types are not tracked by > default.and std::string has been assigned a serialization trait of > "primitive" that > means don't track. So I believe that this would work for non- > primitivetypes. Oh, I choose std::string cause I thought it was tracked by default, my point was meant to hold for trackable types. So, replace std::string wit the user-defined type of your choice and I still maintain that serialization of foo will go wrong. So that we don't keep discussing on thin air, please allow me to get back to you tomorrow with a complete, compiled example of what I mean. If in the meantime you do the check yourself please tell me what you come up with. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

[logo] Google-like Boost Logo
by Allen Yao 02 Dec '04

02 Dec '04

I drew a Boost Logo by stealing the design of the Google logo.:) Just put it here to see if there's anyone who likes it. I am not sure if there is any legal problems:( begin 666 boost_logo.png MB5!.1PT*&@H````-24A$4@```.@```!W" (```"&^YNY`````7-21T(`KLX< MZ0````1G04U!``"QCPO\804````@8TA230``>B8``("$``#Z````@.@``'4P M``#J8 ``.I@``!=PG+I1/ ``$Y-)1$%4>%[MG<^+54<6QWO^#TT@)LM&PA"& M#KK)MB'@RC] &1@1G&84$H2LDGT/N$I6C1LWO7 1LLC"(8)!B!D##5$')2JV M$@UV[+']D7;>?.\[[U57GSJG?KU;W>_VK<M#VO?NN_?<4Y\Z=>K4J?/^-!@, M9NI1-= Y#0#<>E0-=$X#,YV3N I<-="X"54+50-=U$ %MXNM5F6N%K<RT$T- M5(O;S7;KO=05W-XCT$T%5'"[V6Z]E[J"VWL$NJF "FXWVZWW4E=P>X] -Q50 MP>UFN_5>Z@IN[Q'HI@(JN-ULM]Y+7<'M/0+=5$ %MYOMUGNI*[B]1Z";"JC@ M=K/=>B]U!;?W"'13`17<;K9;[Z6NX/8>@6XJH(+;S7;KO=05W-XCT$T%5'"[ MV6Z]E[J"VWL$NJF "FXWVZWW4E=P>X] -Q70@'OSYN"''W+$IR]J+WQ:CZJ! M0AIHP'WO/=2]:_Y-?>%;_A==\-"AP;ES@]750H]0+]M'#6R!&Z1PPA- \)$C MC76O1]7 Y!H8N0KGSP^^^*)YP3J2`8XQI:Z%CODB[E6/JH$)-2!,SM;7&WQ% M!$$JL/,XQ/@(7@$LJY]^G%./JH%)-"!'%4"G""Z CCS@T1X[YC/;ERY%7JF> M5C4@:$ &%X93!!>F-.G0.@`N'M\'DNY83YYR#0`M#.F3'VG@P@E./> 5:(YO M=793E=GI\S'&PO !AE3S)SZU#"X&>M%)S0`7=R5QW5<K#]#IMNR)\ 998J"5 MP59=.6L17,BM3?5ZTG*]?4Q8.A>D///'=+(a)3X.*68C? F_78VQH0!]LN@:O% MU_*6FO=V8^^EIP.C[F"["^">/+GZ[Y3CZO@X>/"9^P#[][_X]ML57._NW;M/ MGS[=2PU6GX4T((+;2B0TS54X?OS.O[*.V=DU%]Q]^S;LBP'R&S=NO'KUJK;Z MGM& "&XKPVP:N+"X9$-3Z17!Q9ON=7#Q1X\>[9F6Z_F#3 NXY)W *&)\U]A= M65G!T _XGEG'@0-O7(M[ZM0M[2*X0L^;?&\\_G2!"YUN;&P;Y0U_L)>NQL6H M,% &XA[+_>3)D[W1>'U^"A=<A)):27!-<Q7L^:#H,(C@BHMG=*D'#QYH[(J7 MZC,$77QV$=S@@VQN;@;/:1E<N!#N+=U8F+UV`J>BB,. *0"FKY2L22_\MY5Y M05"IP@E(0\8F$W16\T)R9]:VDYR[\^]@V\JYP3E+-8V"\.;JH.5L_U1P$5S" M. R;A2'=_Z#%P15%9_P@F""RFVQTD:9^^G0@IYBV9$"L5D8LGW8!`=(WD5"' MA1;H67SA([Q.#P:7V@`R< W >FAP"+M2M'1KV@1S9' $9]X<M)#S'P\N(6LP MP/RH%+CB_(Q97#<[#(IQK1YF>UJD(MCS1H^'.VF+'%J.#VW):"6HR'4,"I%' MY^%5A!B(E\JQAT'U\.KA^/QD(L6 BXDX:_T8@Y5O<8/@NJXMT-*V[FAABF#/ M:Z[(%A;)H-I[.$$G++&6W(Z/6CN0L7=LNW$U!A6.@7G!80"F(KX@OLWQ&@X` MK*Q!TQA4L\GUTN 2L-8L,=[/U@V&-'?)%XU@NV^???82BP/LM6O@POPQB4E< MSZ%Y"X&X&#J'C2.0]5M02";BZ^E2">T&0VM;6?SMMZ X7\077[R8<%O]5-A+ MV]#"!_!XL?C(-<QYX*(1L(T@9@^8.QPBNM\^N+9M,C9R>?G*EU]>6UR\CG[S MT4=K3-P@LJ1V`"JZN0(a)[J.W"MEC@OS$'TIC%U _1B8FYX-A9V6Y!061DOC3L MO6AZ)W4;8%-M:H\U0T'X@&MK6^A4<&%)4ETVQN[1H_?:!]?>Q?[66R^Q9DLO MM]] >E >OZ=7`U=U%?*H-0W7,KN S(8O=7C%8-0^N\Q#"#,[/F-]L&Z(C\2= MOJHE7@>WT-HGP **L2DF?YJ/&R^!J:@`P,CA]!\BN.AY<NH"HS8O,UFT##F7 M8M1BH,^8CS//F#C.NU2C:80%["G7Z29PD7# QZ"OPWF(_YKMO-+?KK<`!;,* M,DM+*QBQS0L#;_O@VOO1;8NKV5T;=)K$:]MU1!]7?@!WTI>W!TC+;T^;JX%1 M%CV(&I$=&N!7B%&(5.,]NK!M;L$?W(9X_NA,,KI)X+JW\(?PZ7PWH-0^N/8$ MRXT#H--\_ODO.,=?G &?NJ2)404AV\9=/IXD'5T;VQ)B9&QV!?BR8P*:PY!@ M\P@%3+-8\*M;X"*@&^QF::Z"'UQFY/VA57LJ)<9QY6[G[GE/,Y#;%:(9W=C= M<,Q)@#(S#>18+-'H)F\4`:8L-)L!+MGL7;&X,2E6!<&EQA#S(a)]BF.='!%9)L MQ&R=^ F@U(O??/BAD*,?FPGB!K,FJG3RQQ]_;V66YH*;ZN-"50N;"W.;<Q<V M+I@DOZ 5;,M5F IP\3">Z@HPEZ*YA<LKJ,GU;M/]!-P.(39:$,?Q\]FSXD[. MYR=.A%+:X=VZH8 T5Y()<^7*\L;&/O>RKU__)23,-FVYX,)S0*P@2![)@[%. MS+JF-VG'2GAA:'BS/!]W6L#%`P!0+2+QU5?_81%<F=I(->B-`X^9>+5O=V5Y M&?$\5[BUV5F<B?/U/45N_#5A3!>%@6 BN'@S)$P`7 SZ&/H][ )9J#UIBP") MY,\^[3RXS2Q5J:5W^/!CFZ3;MV_+[(E^0EST"O"QR1^4CG9"S\;Q\H,/7'!! MLY$*9TJ)=JX_&@6N7YC??_^KZ"U<O[Y(\BC"<)V)F0EX$SZKNWC&L@6,627] MX" ;K"5">;(0@^"*XRT8L'<AN'_CCL5]7*-1S=E%* UK;S2Q\VV9%!V.B)D9 MM&!K7#"B2I$SA!;M!/GMLB%TX((;GIF%A6E6B87%B#MWCNO""#T=J[N>U!E8 M7WB]R%+ -^V<+-#I&::A`3=JZ5_E\H"+]*E4&V\T`$EV#EQ83'$##UR(3SZY M']YG)H+O3X 8#)BAE1>0E2X%]Y?9&$M(^+(N7@%PHX1I`JX"N \?SNO"".!> M'%P,E8IM?+>W7[T]NS9[]-[1Q>N+0##&<V4C1@:XY":E;ENT^RWL=,O@XNHT MT+"#_'IQRR3T%Y5E("YT><%EH*A]0RGQAYPE5[GCBX@Q5Q^XL<(T$ I!L;6U M65T8V;?":FT,N^:<=S;?@26.S,0UCY,*+@H59"-+7Z0[M@^N1ZSY^8?B%&UN M+KQ50\[=T,%EH*BN,W2@@/MX84%\EJ'/D 9N@C *N!L;?]:%42>D;/TLGF,B MV!.%@!)('O\JEVMMWG__O\RHN<^%QC+NM?L'30=W%%RDCXG@4B8;G@<2JYGC M*1:7C43A;".E4IJ><YP`;K(P<J[CH6 "M,A9JMVUX0:^Y >+!TW74L%ETVDX M)RZX,1Y+R^#B,3SSP3-GGFK@!N9/8BQ,*?SG;L ,QP45<+7]<+_]]@_)$Q6B M"CG"*.!JPO@&DR%Q@ ]SM8P=$ 0QW&417.I(>P=<S_BB!1;$RB \FAN=S,4" M-_AO.'HO@CLL^"_:N?OW_Q8);HXP,KA-36U1F*@''!.,8()_VYGK3H!X,?V< MUCM[#2X+Y1KKNTTI(KC.RIF[>NS7[*B;B> .<S%%.X?@E +NM@R;3&%D<)M4 MFVRCZUJ3I94E;)E!2 $)U4'?5\S*Q6!":Q >4Q6,XTZ1JY!A<3_]=%V;TFW9 M77'QS0'7C9.'_81F'N^LCECI"NXUL1R@)!5L6_+-%$8&=[0A0EP("#OQ3JO8 MUT$L[.-?/W[W?^]Z0K^>9ITB<+7?(a)$C*#G.?1\LBQ.VT'1 `>K2HJ-7DMW+4 MQ?HZ474@17#'#^ &':]>E9<)AM&&T9$OC #N5K:D%@&-F=#8+>)V``Q-B"1H MKG#>;O6=MKB%P!4'9&,T10=NRXM"%I@XL[,Z$UN7(BL>;E'Q::W8LCA BTD% M=EICIC -7+[%9,U;B!I8+')%RXTF^.G7G\0@6D9BI#BC+AM5* &N!IXAQ%/2 M9F0UM0VZX_9PT8^:N(A9N58NN6@[L93EGY]E"B.#N[7Q1JO:9KORL([(2? ' M8K5MU>CJ<'^QHC9Y1N\>`5?,"&")KUHFQ\C3#;FY[M>CG#\WV.'D[J2XN9>H M'V4*(RSY\ET5FK$T]A34`CL,^A[O4^L`-$P=?GR8@?O]Z^\SW%QQSYE]G98G M9ZU;7.P)%\TE2Y+1S,#(G&A&>QBW$ELB"ES7$7-^^5)T8UZ\V"\9W29NE2^, ML";'?UQ."XHE@8N316>&P$7 P087D8>O?_P:RD0#1<T9QJ)T'ES1W+HYB5KQ MQBW^Q/G=\$)BWXT"EVE72I5,C.:NY@O#9V;")K:VP(72M'F%"ZX=]J$H6 S! MW0973$C$([F;;L3V-GD533?&=Y3%@DQ67#]!VBDI#@7#7B&6HCF6*4RSOLI2 MPX2=DKHP(T-'KD+DYE[Q:O,/YVV+B_0Q,5X)[OW%W;S1FD;:EET%+?24$0[3 M]NV(&VG#X.)9%4]W_99<WSQ0-H^I5DGPU<H^#&LE"5F(&QL7Q)8.U?"#5Q N M+*(+DP,NOH-I,3.]]JH$_EZ^LJP%VM%[/2FIHI&Q#5;+X&IKLZG@BM?!PUQ4 M2F-%(a)2M.5F=F-N?F1.7ZPF&L#^C[*;RL"#64WKPY@ UDB>DCK ^H.]WCP?4' M%MAD"YV*-IR=^>6,;6[A-FC4TOM@5^N0XG*GO8>:M3AM*0A',+7LL,G!U?:F M4R$3[8@%5YGK/9SGV=;0@NJ*L;' NPM(9,6*0#%+V5A-9-!>OOP-:W+=+X12 M[/ M_E;5%!(&56M.$WD(+'C2N\168!7'#CX[Z*>6/M46?K6]AE V#;G4XN?/ M7SU[]F>DK& [#/[.!U=;XH*Q!--4V9L-+K@?"H)(a)+P.^JVTO"VZTT< 5\@T@ M@=2=L<GQ\C?;<)$C\XS:4"$%D97MK26PBT6*:]>V]O^@A91E`D8M_&;?;N&@ M,&P%(;XV`J.6*M[!FOJWG9'1%3.9M,(5M)0$3K IQJX]!W9A='/ Q08;90L6 M7[?"S^N9HG=BW3M[G2NR@G)R$HG$+O8YWCIURM@);@S<)PSV)Z68I+,12*C_ M!7;OW3MJW ;),F'Z9=M:'OQR[:((KBV,NVR+=V"&_<NVK,:H6Z<1:"*"IL7: M-4\WOA(>]AE0JR6#ZRE^'%_NSJT7%E_02(OC^B(O8FFUF1G@"\\!!*\L+8W* MK.%,-AR8$2L46Q?#1I)C!S]5V'@#?!\_/HR<LI65I7%Y9\2>`3IS#Z+JB02% M\1?+1VXN^_4'ENA(E&LJP5.+`FAKSEH(GQ%EJ,T!U]@OV'#/RP,Q*N'AB[@. MS'9&*;K,U">W*'FPGXD%S'1\Q?5;Y70J2BX64_+\$D1"@;"@,-EIXU2O/)A/ M`W:3$M^TDL2FE5 3U_:DDRTN1E$J`>D_Z!Q6'9+*1.*W>4/&2_W<;&-BLX'8 M])&;-S<7%E[LWR\6^!BY5.A5Z%+Q0\!8V*1V&GYI=7/SG\^>'51R<4P543@& MR06<(X4!?Z@62F7RR:9JEACOXP2QY(+66NZJ6["98%ZH(")>9!;QQXD3SS$[ M8BV>#&X2<\$5\Z2KX>1@7#WF@K!&*$YS?7'1_EV!U9,GFZZ6^S,[[OIMU(+< M>%T*\S,X">:UNGIR^!L[&35T&P5D"]-TIL$J_?3#=\^_HXJT^"-H7T6UN]-H M7^UXO>5$?[U+X&KF-O7W);7I7<SZI*;>K'UCS<6F2AC[Z0QV,8A$@AM:6Y&U MVWEP17\_N U05(9XJ9B2JQJX[()1>X'&UYHJ8<P#&G#SS"2NPPQ-Y!#D:E@$ M-UP=QK,]W3\N:[],EM2HYA9BZZJE[T(>@V:\\QK)M9I)QGNJA''!#3JFD3YN M]G5$<&.:7MV>[L<C8:7 >R'MA]@G,9"XH;8HFC&<L4Z5T4)3)0RUAFF^O#$- M->?L&4Z>M6*2L.RSX,;LW007+2K.\&(Z7,CLRE.]5!6S^6*V8 F_<*$_6%O" MV.!"_QEN+I,D:0ABS^<9NMW+4M$QLAV9X&K3#B@"]_-T%WR$[VIE^O#UU-F8 MAV#1`\&;D4W5(B@0<JJ$L0<!Z#S)B6)JB?%'_59&RPFFE61\2H>Q<60^<L!U M*[RR.!SN08>Y*]V8#C%I`^]'5GX-VEK[!"W$YA_QT;M8\<W)FP=238\P;A06 M#11\1J86M&/P*S&-Y=EKZ*)B?)LT<.$C3E(@TH-LT*>)48%X#M6M<&^--ZF ML/D69* 2L,R!R_",-6FG1!C-R.'!:2R&6NS#_/B 42,-K=F-PK[HV;EI-YS= M3]+ ]50_B$E^LQ^;=-1*EPVJSS45;"H@C@8Q1BAX:_>$:1#&_4F!^.:C#I_Q MX/ZO^-G%31DJ:>!2AAL.7(5U2ON_=(YXH._BS'+VU:,=UYIJ(\ .]*A=%X8F M&T#0>'%^=LGQ0YN6:SNC$S/BD4$!T^Z@EP9NZ_UL5RZ(GH,&`)VV"P[MT!"Y MPR)-CS"0!.B(YF;G;0U(];=%'\'=833K[4IHH();0JOUFL4U4,$MKN)Z@Q(: MJ."6T&J]9G$-5'"+J[C>H(0&*K@EM%JO65P#%=SB*JXW**&!"FX)K=9K%M= M!;>XBNL-2FB@@EM"J_6:Q350P2VNXGJ#$AJHX);0:KUF<0U4<(NKN-Z@A 8J MN"6T6J]97 ,5W.(JKC<HH8$*;@FMUFL6UT %M[B*ZPU*:*""6T*K]9K%-5#! M+:[B>H,2&JC@EM!JO69Q#51PBZNXWJ"$!BJX);1:KUE<`_\'K.^]H(S]#DX` +````245.1*Y"8((` ` end

2 1

[Boost-bugs] [ boost-Bugs-1076691 ] Don't work multilevel hierarchy of test suites in dll.
by SourceForge.net 02 Dec '04

02 Dec '04

Bugs item #1076691, was opened at 2004-12-01 14:10 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=1076691&group_… Category: test Group: None Status: Open Resolution: None Priority: 5 Submitted By: Talash (talash) Assigned to: Beman Dawes (beman_dawes) Summary: Don't work multilevel hierarchy of test suites in dll. Initial Comment: I create main testsuit in .exe file. Other testsuits I placed into dll's. My test system doesn't work because static data different for objects test_suite that creating in exe and in dll. in exe: test_suite* init_unit_test_suite( int argc, char * argv[] ) { std::auto_ptr<test_suite> test( BOOST_TEST_SUITE( "ProjectV" ) ); HMODULE HM = LoadLibrary("BugBoost"); const INIT_DLL_TEST_SUITE InitDLLTestSuite = (INIT_DLL_TEST_SUITE)GetProcAddress(HM,"InitDLLTestSuite"); test->add( InitDLLTestSuite() ); return test.release(); } in dll: struct TestDLLSuite : public UTSuite{ TestXMLSuite() : UTSuite("TestDLL"){ boost::shared_ptr<TestXML> instance( new TestDLL() ); }; extern "C" __declspec(dllexport) test_suite* InitDLLTestSuite(){ return (new TestDLLSuite()); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1076691&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 02 Dec '04

02 Dec '04

Good idea, thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Bruno Martínez Aguerre Sent: Wednesday, December 01, 2004 8:46 PM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? Just use an auto variable: // some code { boost::thread t(&some_proc); } // thread detached // more code Bruno Martínez On Wed, 1 Dec 2004 17:10:57 -0500, Caleb Epstein <caleb.epstein(a)gmail.com> wrote: > On Wed, 1 Dec 2004 16:29:59 -0500, Tim Laplaca <tlaplaca(a)voiceglo.com> > wrote: >> I would have never thought of that, sounds dangerous! I tried it and it >> seems to work though. Is that pretty safe? > > 100% safe. See the discussion here: > > http://boost.org/doc/html/thread.html#threadconstruct-copy-destruct > > That said, it might be nice to have an argument to the boost::thread > ctor to start a detached thread w/o needing to resort to using the > heap. > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [logo] boost/c++
by JOAQUIN LOPEZ MU?Z 02 Dec '04

02 Dec '04

Looks good! I think the bulge of the "b" could we a little wider, so that the "c" would fit in better. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Rene Rivera <grafik.list(a)redshift-software.com> Fecha: Jueves, Diciembre 2, 2004 0:17 am Asunto: [boost] [logo] boost/c++ > > -- > -- Grafik - Don't Assume Anything > -- Redshift Software, Inc. - http://redshift-software.com > -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 5

[logo] Sweet
by Fredrik Blomqvist 02 Dec '04

02 Dec '04

Seems like a Finnish chocolate maker has a suggestion.. :-) I bet this is what Vesa and especially, Jaako have been secretly chewing on ;-) // Fredrik-the-half-finn begin 666 boost_tupla.jpg M_]C_X `02D9)1@`!`0```0`!``#_VP!#``8$!08%! 8&!08'!P8("A *"@D) M"A0.#PP0%Q08&!<4%A8:'24?&ALC'!86("P@(R8G*2HI&1\M,"TH,"4H*2C_ MVP!#`0<'!PH("A,*"A,H&A8:*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@H M*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"C_P `1" #N`D8#`2(``A$!`Q$!_\0` M' ````<!`0````````````````$"! 4&!P,(_\0`4A ``0,"! 0#!08"!P0% M"@<``0(#$0`$!1(A,08305$B87$'%#*!D14CH;'!T4)2%C-B<I+A\"2"PM(F M<W2BLP@7)31C@Y.CLN(U-D-$5&2$_\0`&@$!`0$!`0$!``````````````$" M`P0%!O_$`"D1``("`04``@,!``(#`0`````!`A$#!!(3(3%!404B810R<15" MH9'_V@`,`P$``A$#$0`_`+L3I1SM1:$4?7TKZ!\X5Y4>H@=:*AJ!I^-""A,5 MT&U<R3IM2I@4%BSO2AM%(G44L&@L$0*,41[4"3&T4%BM.]*Z;USWVVBE@10( M/I0H^FE T*%VHU;4"(BCZ&@"!T\Z!F-:`'6E$RDT( :Z49H)%&JA0*V%$/AZ MT"=:`G82* !^'K0&HFC,QJ:,"-!0":.-?2CW-'&M"B9(HS1D4%;4`8% F-0* M`^$4#0!3/<48T$S04(V-&GM0! ^8H*)C2C4(%! TH #4T"(B*!3UHR(UH 3% M%-&4@ZZT<:10!$0*(>AHU3&E$D28DT 9/2A$@^5 IBATB@$FC(VHXH$4`6M$ M9Z4<41% $=XH;BCZ444`"*)6U&?+6BWWH!'4B@1UI9'44DBA!)CK28@S\J7U MI)&NE @$10H:G>@=!I0H2QII2=AM1DD]J!&E`)F1231C?RH&@$SX03220>]* MV31;Z;4`D;]:"J5'F:(T`DZSY":+J/2C/7STHB-J$L!$[TDCUH'3N:'R-!81 M$),47;TH*.AHB=J%".M$1 FAU-$HDB*$L* 4ZT*(D1!H4*=!$Z32HH "C!TH M0'K2HD"BW30!TC;83VUH989FE3H?2:8XKB>'X4PA[%;^WL67)Y:[@D!1!V$` M])^E13?'?!RUE(XGP])C^(K ^N6IN0IOX++,QZ4I.E0]IQ-PY>+2W8\28,^\ MH0E'O.4GZBIIU!;.5:5)61F$]4]QW&VM5._!X#?8T2@<NI-%MMVI1U&M"6 G M0&EC7>DQ( HY(-!8JC&M%\Z$QI,T%A]_*@>W>B)@^NE!4CU%"IA]/G2NGK29 MZ>4T<G+.E"BA0)HA0WB@#U)HR#$S1G3;:B!TH `#O1T1$;4HP$^=`%KO2J3K M&PB@H[4`"32MZ3N(%&3&V]!8KI1$:#UH3I0F@L/KK0$]!1'>CF4T%@4209$4 M8T BB( %*VB@L+6AOO1JT&E 4 2C`TZ4)\(/6@L2*$:10!D2!11%&3I0H4 U MH';6?E0`UHXH2Q(@[30-&=!I14%@(HC,4HT0H5,3L**3K%+RZT2A06)D]J U MW%*C_0HB".I/K0C"6/#2#TI1DR#1'I0J8F-:"A1Q- B@L03%$#Z4HC2BB@L! M$BDJ&E&=/.B.M!8E6U%U^5&8U!H:=*"Q*AI2>ORI2MJ2:"PB:(Z4<>=)4:$; M"4:254%&30B*M&0LVNM'KWTHNM'UJ%0E6U$1K2C%$K;K2S2$J&A-(6-)I:MJ M(B1!H/D3VTH49&M"A3H-4T(C2A,`10)UH9 =$T"(:=44R4-J<@]T^+]*`,I5 MO,$B/+6L_P#:WQ_;\+V#V&V"D/XK<!3:T[AMLC28(UU%<YRVHB3E*D83[0.+ M;WB[%U7=V2AE)AEH$Y4#ZU5XWBC(TWHXD0*\?O9]%125(4A.63!4,NOEV_&* M]$^QKC%:\+L<)Q1Q:V'4\JUN22HH=E*0VKR*E "O.H(C^UT\JOWLP*[E-W;< MQ2!*5)4DP4K)$*'F%!*AYI%=L#J5'/*KB>IR")20H03NF(&D`^>OX&@=0*B^ M&<3.,X!9WRAEN%)+=TD'1+R%*0L02=R@K'DL5*CI->L\`>6!UHR-J'2AO4 9 MVTH#4QUHR)%$1 TWH R.]',)]:+I0B=*! `UGRBCCIK0.@H]MJ%L,#3>CVHM M,L]:,^>]"6'T(HPGI1=*.306'$:BCZ4#('2CDQTH+$^IH'6CWT-&1I06)&U' M1"@*%L$4<:4.E#RH0$30VHR([T82#WH$`[4<3% C2@#0U8%ZT * )C6@= 2* M$L!%!1B@>E B3K06$=:,30VVHY,4%A32NE)/:E1I5 E0,4GI-*)D0-_.B5\, M#O4``9-#:@! FAZT`"3.E$9.]&:23T@4%AZT1\Z'2B(D;G>@L(;T2AI1I$$Q M1R=9H2Q&HH3KTI6\?6B5IJ*"PCKU%%%+&U$10TF((TZTB3'SKJ=NM)*1&E6A M9R5-(DCK-=%5R,TH@:B:2K:CU/0_(3^M)4I,P5 >O7Z32A81,;41W'7L-I/: M@ 5GPI)\DF3^E<[UYJSL+BZO70Q:M-%UUQ8@)2->^NPT&IJ43WH3=7%M9V[E MS>W#;%JV`5O+D)&L&(!F)J-_I5PRHD)XCPTPHB I<CM(R5@OMEXFN>(V;"X2 M76,,YUPFVM\VB4 H@J[DR3/8^1G+BHD1^@KE/+M='IA@35V>TV\9P5V.7C-D MO^ZZK\LHIRF[L5F&[VV63M#G^5>(@8H$S6.?^&O\R^SW`5MJ(#3K2C(!AR9_ M"A((B?%.TS'K7C;A7&KKA_&6+^R40M!&9,P%)D$@_2O6O#.,'',`L<0+3K!N M&PLH6WDS& 24R3(D[UJ&3>Z.63&X,D^M!1TTHMZ!%=B"3(UH4HIH4(*C2BW- M)*XKFITD'RUH0Z+4`@@J*9!!,]P8_&*\[?\`E#84U8\:)O[920UB=NV^6TJD MMK2D)4(W`TFMQQ_%SA&"WF(I8<N!;MEPH;W$`D'TF*\I<2XU>8_BK^(8BLK? M=5.AT0#T%>?._@ZZ=/=9%=!%`R#I1D"8!D=Z2JO.CV .@JQ<#8^U@&+BXNF% M/VZPE"TI5!2,Z25#N8!'SJMDF*$D58MQ=HC5JCU)[(,=L,5Q;&++#+L/(N+= MF\2VY"%I6@E"I'<A:)(_E&E:02G;4*@&#)[SK%>&["Z?L[A%Q:/.,/-^)+C9 M(4#/<5IN#>VCB5E@6^*7;EXRD!(=!"7$CY@@_2?.O3',GZ>3)I_F)Z:#:R(# M:U=9`@4>4"?&T/5U/Y5@UMQ2UCK6=K'75.$_^KW#W+5]!O7==^S;J2AMK$;I MTZI:9MU+/J5$Q'RZUUM,X;'\FY**0@DN-A(U42XGP^>^NL:>=+;2%)!T!R@P M%29Z]-/K6$8D]Q:UA[][AO#J64-I*LSKJ%NA(!459(VT]:HF*<=8JK#6&V[N M];Q(.J6]<(=4`ZE4%(RS`C7I699%'TW'$V>LR$@02D+B<I6!^E!3<"=?4$5Y M-PCVCX]:.*1B%Y<7EJ2"4J(S#S!J]X9Q39XDCF6^+I:41)0ZZ4D?I2.12\$L M4HFZEM6GA7'RH\BDB<BC)C:LEM<1U_\`Q^W3(F%/S4SA^+63CS;8XGMLRVEN MB'NB1JGUK=F-K-"R$#4*^E#8:@U2/MU*+4/-X@RY-L+A/^V)&>3 0-/BZZ] M:1<X]<V]MB+ZL3L$MX>TTIY2+H'.M>R$E13IW,$Z: S(62F7LB>L>H-&8R;Z MSVK/\3Q?'K"WNG5W-FM;##;W*3<ISO!<1RTGQ&)'\,>=+N+OBUJ\5:(=:6M% MDJ_4IM1<A"8E(2!*G/$`$^<SI2PHLOVZ3\6@[&C3H!H?H:S_``Q_C6_N.4EY MI@^[)>5+F;[Q9^[8U"0'" HJ@J#8&I)@%O:7O&=W;73EM>!;C;R;6W0VD_[4 M[D*G`)@H2D)S%2AW2 <I-2R[&:5Z3]#0C397T-9#=8[QXTBS5;A=VF]#BF#; MO@!26R IQ14D)0V"0,Q.Y ZTW8Q[VD76*,6-C9NONOVOOJ%)N65H-OF"0X7$ MK* G69G;ZTW)%6-LV6)/AS?2E%I>H*53TK",,X[XUOL+-X[A6(+LN7SB\F$` MH!REQ)5&=,D:@1)"9DU-8)CN)8_AS=]:#$G+</!J4J3F4YE*B@`;E*<I5&B2 MH#>EHKQR1KW(<C1M1CL10Y*YU01/F!637-V^EM!<7=I2OQ%;JU)\C IL[<!2 ME)1B!!$9%9EZGMJ?]15,J#9L2FSU2N.\B@&U#9*OI-8ZFYN4MN*3B6(+,0V& MTG+FZ""-3Y CK2T7U\EP)4YBC_+"$OH;F4.*T"3IX3,::Z30J@V;%REY=4*' M]HC2BY:AID4:R(WF*>,-V>(E2'3;_$KQK&IRZ]!2,1Q'$K)FV=NDW3+3Y(:* MEDYXTBEE6)MT; &C/PJCJ1'[T1;(2 H*!.IU'[FLG6O'Y*DX??!(4A!3G2?$ MKX1KM.\T;+?$CMP^RU87I<%Q[N22A(#@!*DR#M )^52S2PO[-7*>O3IJ*!3) MZ'_>%9/9HXDNU,)8M+K[\.K:S+3JEL@*4?%IJ8^=<V$<072,)6TTY.*VR;AA MKG#.$0E1)F/Y@-).NQU(J:+P/[-<R=Q'JH4>41J1]:R-E&/O&^RK2A%C:"X= M//2YN3X)0HPK390!T.E=%X=Q.FY7;E"U.)=;8)2[`+BDYLH&I.A&(a)!.A^4M$ MX.ZW&LE&T$2=M:(I!3HI/R4*RFTL>*WG/NK5W[JX5;KETJA2=YR(a)A.DZK*/W M;6EGQ-<LV3K=O?0^PY=HRE2@4(RA0D)()E8^'-I\R%HUP5\FO%((WZ_S"CR1 MMK_O"LD=LN)FK!5XXEP(2TA\IYIE04K*(44A&Y&RCYP=*[NX3Q4R[;)N"IOF MW*+;52T0M:5$`%:0%?#_``%5+'^>^]QJ?+.8=O[PH<N"8G_$*QV\<QJUO[RS M>NB7+)\,OK2]E ,B3"@%1!)F(TWI>#G'L1P]-_9O.Y%735HE*W/B4LI$2 >I M4-CJGKM2R_YFE;9KQ0<LPKY:T1;.^51^45D.-OX[@=DQ<W]PLI?<<:2E#JT* M#K:"I:<JT),0#K&F@,2*F'K+BBWOD6:;YE;ZK55V1SBG*D$^'L50E1Z"ED>G M:5V:&1'0D]HHI$:@_2L_9=X@9M\3?O\`%6[9FQM&[J=7.8'-$"(&4S C7?>G M]P[Q#:WKMJSCMC<.6[#3CY$@)4O^$#?L1$F#UWJV<^/^EN*AT.OF#1R(D;'2 M2?\`*JE98OCZVG'7+K#BTA[D:K<*E="O*$9@F2!)3&N^T][#B*ZNTX+#M@/M M)*E@MK'W83EG,HJ,3G3ND#SV!)H/&T683O$^E'!.PZ3K5;ML2?Q&^M;*UQ,N M7%PP7PEA:%I;RJ"2E2D@IDD@#7Y&H57$;+MA>W#&,)>-M>)LRA3R42LJRJ(, M:A)@SU"A2T9VLO\`D, Y5 491"9T&O58%9]=NW5Q=XHU;\26++-GR2AQ2@.: ME:4K)DK $!<:QJ/E4$ZT_<80]B'],L.2A+KB4I!2%$)^$ZN>*>Z01M3<@HFN M*4T!XGF!!UE]-<'+VQ;$NWUHCU>%93BN`6:+&Z6.(7';A%DQ<I0IYH N+N"V M4E)A49((TWZ["HKCKAZRX<PE-\WB2KM*+\63AS(A0Y3J\R2"=);&_10J;T:4 M-WAK=SCV",@EW%[(1V<FH]SB_AM&^+,J[Y=:\W*X@L\H*$ J*03)'[4W=Q?W M@PA:4 Z0G+^U3D1I8F>@,6]H.%)MG!@*%8G>(!.5Q)0TGS)U\M/.LV/M>XLQ M-]5MAMIAS*RK*GEQ`[^,D ?.!3?AX!NQUD!>XF)^E0MWAEO;8P+QN$J"@N!H M`9Z1!'YU)2E+PU#;XT2%[QOQRJQM+QS$@[;OK4E(94@J!$@^&)@=Q(\ZXW%W MCW$&'MV^+XF\NT"@YRB@)VV)TU@U#WS]PU=/\IQ*$K7S"&T!,^O<^M-+C%[M MNV7GN7 D^$)TDUARKTW5^(X\36;Z6TI0[S[9I&6!ND G7\3]:JA';:I2[>N+ M<'[XA3Z/$ >G:HLGP[#UKSR=NST05(+I0 DQ0Z4I!@G2?*LFS0O8G@^!8MQ6 M$<0.>!H(6RPI0"7ESLK34>0BO3IE*$HF,J4)"8C0)@>F@Z17C# V[UW%;1&% M-N+OBL<A+8E15.E>O\":Q)C!+%K&EA5^EE!=RS ,;:SK7HP,\>=5-,?*T-$2 M=NM&=:(Z`QKZUZ#G01)H49@@4* :.+@"#3=QSPDR.F_K2'')&M-UKDP)/I_K MY>L4(<\8;<N\-O6;>X=MU\E[[Q*921RE0%2-C^@KRI?,M,.<MEP/) !.4: D M#,/RK7?:EQ/Q#@[KMFA#0P[$+9*&;A)4`J4#-'BT4,Q!FL92M( 4I 5E,P9@ MGUGRKR99)L]&"+5L)XHS2VE243H#7(Q79UQ!1 92DYB9!)^5</D:Y'H`J@11 MK$?6DS0J#&@-+ E*_*N<UT;,A0[T(=+5U3+B%H("D^(&!N-J]-<#XJC%^'</ MO0HH6^.6H:@)4D $:'JI*SZ17F!$$&=H-:W[%>)+:V8Q##,3=;88;!O&W%DB M3X4J0-=]01_O5VPSITSEF5JT:3Q;CK'#^ W%^L0^M"FVA/BS%*A.O2)KS-<O M*??<=6!G6K,J)ZU8>.N)WN),2*IRVC>C2-0(UUWWUJM@3IIYZ[UC+/<S.&.U M6_0D@F #MK2BF=P"KO%%_% VI:3\))@=8KFG]'7I'1AE;[F5O<#<]*?!M)&2 MQE*T@A1,==#%+"1:X<F-''/%)-=,-M>8L &22->LD[UTB^Z,.2]%6N'W2@4E M3B<R0G*=H_*K+A^%8@X'?O7R'D)0Y]X8< $`*_FWZS5FX6LN8TA%TD+ 2D@] M9,_M6@X;A* $<I(6F=M*]"B>>62S/;# +M5ER5O.G( 4I"R `)&G;?I3K[(O MI*N<^L\LMF7E:I)&A$P1(!UG4 ]*U^RPEL*&9E'TUIVO!6'#'+R^@K=,YV8H M_:8DPDO>]7JGUA(4X;A6?P@Y2#N".XB=C()%0ESB&.6+S#Z+^^2\P^NY:7G$ M(<6#G4!$#-)D#34Z5N>(\.YIY:) [B*J.-8`LH6%-@@#M-1IFE(RI?'?%%CJ MWB!6A-L]:A#DE(;<() &: 04@B /.:6/:?C-RC$V+RVM'4WN'C#_`(3F;0D. MY,N8JVYIT_LH.Z9+WB+ "C,>5$IC1/3]ZI;V$7;CRF[:W<<<"944HT&O<;5P MDY6=H[7Z6_$_:)C6(VCS!8M+95S:LVKJFX*EI0A0&8QF41.@651\A26N,+_# M\'P"R;N#:G"\QMDVYUE6;,3 &BBI2C.I)'0`"%#MM;V;2.>RO$$:&7H*#V ` MU/K-.L,X5QJ^;]Y9P;$'VUK'WSB5-LSW*U )'U K2;/5(a)P.;VI$DCC7%2RPF M[6;MIHG+SW<I$F>@\JF__.(^X\P\,-82M"8T)(]=JCCP>BT<_P#3N(LVI*9Y M%F>:M7D%1'S$CSKJSA-JEFX;L,%<N"X,J+FX4%J3UU!&7IT$UJY'V,'XS#7[ M=G1/&E\&$H#@90ESFD *'BZ:G]-:=?T[Q5-J\A-T@*>=#ZG1\2E#:=?SIJC# MR^PQ=/89:LVJ$Y5*;0VC,1WA,_C7!.$M!TK0PA;:]4I0)(I;7IW_`,.E75#C M^FF(H6VIN]>);=4\GKXE;FF5UQ)<WJ6$W3SC@8)+<[(DR8^8I[8<&O7BO&R4 M-&8)4$G\JG,+]ER;O.T[<+*D@+*6=21VFN<LJ7R'I=-!7M*X_P`7X@XI]2KU M]9=6AU>LYBCX=(HQQCB64GWFX4"XIT^ ;G?H/WJX,^R[AY2$%YW%0YJDH"@` M"#Y@^==[WV3X!]A_:-N<32R"))6)ZS_ >U8>=)I7Z9EAT\8[Y1Z,_/&MZVXV MHWK@<;0MM)(1LH(a)GI_9%(MN.;]E-IR[^Z0;5DLMY7CE2W*?#&T>%.GE5]M?9 MM@2;-'(N[K,H!<K#:CZ:M58,(]DN"XK9X@AV[NBWDA*@AL0>^C5<LVJEB='2 M6DT\,>]JK_ACKO&N(K2[%[>++J4I5!)!2DR(DD#MH-C1N\;XJ_.9V_=ET7"@ MJ(4L`@$B-8!_*M,M?9_AC-LRT,2N1RP4F$($ZZ:ENID^RUD6X>5=WR&BF1F4 MUK_\JN<M7D3I([+0:.*3G*F_X8VCC7%&,N6[O4.!9<0I202A1W*21X?]V*X_ MTFQ9QDVC+MP\E+>0H4A+F9)RS)*3.J4[UJ[OL[PJY 9=Q&[6E:LN7[N?_"II M9^S'"\,>NFV<0NDD&!G2V=-^K7E6XZG)+IKLDM#IUD4+]_A0KOCCB%["S8>[ MN6UL>6%N-)<2XK(92,Q,?KVBF2N)\7?=#Z[ATNAXO*("4'/!`S$"50"?BFMA MP;V>X<_B;#8O+ER5)4H!#>T$F?NQI7'C_P!E^!VW$@7;W%\S[PT'5(9"$@$: M?R^=8Q:K++)LDCEEPZ+3Y%C]O^&-O8I=.ESF2XIY14X"K*'%$$%2@ `3!-=S MQ+C+&&,V*+E35FS<BY2VE13+@*E:GJ)6K2M%/ 6"(00;C$U=-<M.[7V=\/\` M+2[%VVX/A)UD>8.8?A7NE<([CHHZ?(]BC_\`#';C'+RZ82W<W1<;;$!*U `3 MO 2!J=I[$]Z<KQS&GG0^;RY4YDR9@2?!/PD1J/6:V'^@?#QS*>2\ZHC64A)W M\@FCL>"N$<-QH.75@76G41#Q*DC;H21T[5YX9IR=#48<6!)N/7_1BU[BN*W" M7O>;U]9="0X5/J&8)^ 08 `Z`0/+2D)Q7$U7#K[5[=\YZ.84/$E<"$S!U@0- M=-!6[7^"\,LW,V&$62D*UT81I_W:6TFRMQ]S96K0`TRL('Y"O1",GVSR\N*O MU@8A9X+Q$];E-E98E[NI7,+:"0E2N\ CK!KNUP5Q2ZVR#AUX$-$%OFW `0?( M=#H-?*MI=OIC4D3L-!7!5R#.ICMM710/-/(GTHHS'"N#>,\/6^Y9+39J>:Y; MCGO0"RGJ,Q!.O;RJ)=]F^./9D9K!ED1#2;@J!C:=!MM,SH*UZYN0VDE(`5&\ MG]ZC5W)7\9)ZUKCL^-J,[4J5&:GV;XZVZIY.*6@N#!S\U2%:`")'I7%CV=\2 MY7FFKZV2V\9=0BZ<RK_O``STWK32^HG<C2.U&7O"=CZZ_G3A7V>?FD99=<"< M56[7+:"WQF!A%T4)T!(a)^()$CIK.NV]16*X#Q,AL)OK7$'4I,A!<YX3H1H H] M-)\A\]H]XRZ(A.G012Q?.)3',4$C6,ZOWK+PI_)I9G\H\ZO6[C$A]MQ@::.M ME.WR-<&QN043T(6!_G7H]R[#B2%H;6"/XD FHJ^P;!+T'WG"[4$C52&@%'Y@ M36'I_E,VM0O&4OA*\]XP\-J44NMZ*S)@Q]:=7X!.94G4]HIY=<'V-FM5U@=P MY:W)W94K,V?+:1]:88@'<IYMN4NIU(2<Z3IK!_2MQ3CZ<G3?1 XL'$D+2"O- MH$CO!_:JZ^L/O*<4H<EHQ.\GR_&KA:VUUBJ5!RW&'V#8EZ\?7ERC8Y1U.NWK M4?Q?C5J](a)EKA/#]LE.%VRP%7"F\KC[F58GT(a)G\*XS[.V._"F7"BXO.H_%L.P MKD4P*4N08C+H)%$9(TUKBCTB"-:-)@Z4(\Q1I .]`:![&.*+7AGBQ+UZPVIN MY0&0\1*FM1J-=-M:]/I(+*2VH*:4$K2H=9G;4UX^X0X;N.)<=9P^W4EE*B.: M\KX6T]Z]8X'A=O@N#V=C:K<<;::2D..&2Y$R9('R%>C _@\>9)337H^.U G\ M11':A7H.877Y4*!WTH4!`N*)ZTT=<2")@^))&82)!"A^(%='5D;"F-RLE)RR M28! ,3K^\4\+1 \;^YW7#MSAUZ&UEU*G&@2"67 G1W;02 #_`'JP;%?<V;Y9 MPLNKMDE.53L&?"-X`ZA7RJ^^U1C$[>Z<N4/EW#+M02 GP\I>4C(?H3VTK-5$ MY92K;N?H/P/UKQY7;/1B0IZX6X"%A(!5F@)B*XI41/4175148)4#-)3F"@`H M>IKFCLCOB3SKPMU/,I:(:2@94D9@D0#ZTRI]B2G5!H//I=RI@0=J8T*@"NJ% M"" .E<T^>U+&RB 8\Z$$@F"*=87:KOL1M;-LA+EPZAI).P*B`#^--:F.#5%/ M%>"D`'_;6/\`Q$U5Z/AET1[,(5E=Q^V0K*D@!DGIKU%/V?9(TXG3B=OY69/_ M`!TCBY%U<\2VN'VC[C:/$29F!S%#K\JL]CP>E32<ZWE*&BE+6)/IIM7=0C]' MGWR^R&3[&F\@_P"E#7SL3_STH^QEN!/%#4?]A/\`SU9T\'6R=7'RGIJK_*N[ M/"=HDA1NAO'Q]/I6E"/T9Y)?96W_`&0<Q:4GBEDA```-B1_QT^P_V2K86%(X MD87J#'N)Z?\`O*L"N&K53I7[S*C_`&SM]*>V^ 6[9!2__P![_*JH),PYL5AG M!CMD`!BC"B E,\DB8G^T>]6C#K!VU2"7FE=-$D#\ZB[:R:;C(XHD=H'Z5)-Y M$" 5$^=;,/LL%N\VWJKXXZ4X]^3 T%5T/0-Z6'I$35LE43;UTVI*H&M0.)WS M386I*)($'3I2E/:&"=:BL5<24E<2H'4=*C"1#WSB+Q7B92NW/Q&,I'I5,Q=[ M"UH-EAS=RR@SS"5P3YR!5AQ&ZYAE4A(T\-4[&+] 24-M90CJ!J?6LT>G!B<Y M4B8X7Q#!< 5DPYQUAY2?O' H9B9&DI /U,:4=_Q5AUS=*]^Q*[7E7IE.6#Z@ M3^-49FZ8-VJ&Y@><U"W#R%/+4A!$JF=ZDY)(_3Z;!"'IL.'W^"%O-:/VZ5*. M8S"5$]R>I]:D!B-L9RWK)G6,PWK"0^@&<BP=M*ZFX24'50$0:PLQZ9X8N+_8 MW:P-A[FM5P65-N'PC,-NNGK%/&3:6P!1RFT;:Y08C3J>L5DG`N.X':NKP_B. MU\+B@6KA1S)1Y0:=XQ>H=Q=XV90EHJ 1E2 `.GZ5X=7GE%IUT>O\?BQ9I<<; MM>LURS+E\<MN[;JR0%K+D)23OT.M6;!6;?!V[N[O;EMQW)""A0"1'<&3/TK/ MN G1A_#"[I\J2%-^\J*2084$KG3LDFLPM.*L4QM=RJ[N2EM20I*$H$PHZ2=] MA^-?,QY\FINETF>%S>IU+P1=11LB[MNY4M2'&"X\OPF4[E0`Z=R*M/$MTSAO M!;-LRMM*[HMH2)&LJCL.RS\A7GRPQ1VUO;9Y4E+:\Q2DP"!^NQ^53'%_%*\< MN;5;:'&;>V.9"%Z)"HW)G8:_6LRU$GEBFND?1UGXK)ER8\<?^"]9HY?0TE(Y MC>5!"?BZ3'UB:MJ;QO!^"5J4\E+[C0)UB9@0/]Z?E6#\(X?>8O?VZT\U-HU" MU+6D^/*J8&HD&3K4M[3,<0+NRPQE<MVJ$J6)^(Y<J1H?4GSK.75/)D2KI'+4 MZ>.?4X]-!]+TO(NVVPD!YL%!*3*]R(FG3^,7=WRT./N.@:(0DG;YFLLX$0N_ MQQ1<"G6V$%2@08SF(WJ0XWX_<P#&SAEBPE_E(\:PF "28&QZ`5K_`&3G-PA" MV9UN6&#-Q16YHUO!<)RK3=XJ^VQ;H.9*`H9B?6:A<4Q1A_$GUI>;""J$C-/S MK$D<6XUQ!>)ME+4AB"2W;-J*C] >])_VT*,6]R-0?ZISSWTKT<N3%^TU3._X M_32RMY<K7\1Z.X(;;=NG;G.A0;&4'PG7IOYQ5.XOQM%UQ+B=RMQ*&$N<IK,E M( 2D:G0]ZRMF]Q=ELML&\;"B#EY*R"09_E\JD+!#(P/$+K&DNA!1RFDK94E2 ME2=9RC>3]!7+#JWBGR->GGU7XJLCRO)_T72SQ:R7-P[=MEI(!2- "3\JF+/% M;3%'V+5BXMPL$)^+*8)WK$$W"6V6VD0$H `3!\X^=2[6"XPA#5REG(" I)S0 M?7:N^I_(2E_$?0AH<&GQU*=29L&+OX=87WNXO67,J$*5*@K4YI_*JSQ+Q#A= MO:L7"KP0%A$(1Y*/3TK-;PW-N[RKQ/WP`G,3) F/SJ'QQQ2L+RYR$RDZ=-8[ M>9K&#52W(:K0Q6F<G*Z-,M^-<+6D$W*DB(@II;G&6$ 3SUJ/]E-8DT6BF<Y* MC!)/S'Z4I2TZ@.*B*^TLS/@)8]O9M5UQ7AS=KS6[A1/\N74UQ8XPPUT#GK6S M.GB'7UK&"^C(1G7J(WKC>7*D-A+:U '6)FKSL^?J7&,?U]-CN>+<$)/,Q%*? M%E'AH#'\(4$J&(MP3&N@K!W'%*7),T HIF%&G.SY#TZ?=GHIAZV?3F8N$.)C M=+B?UHU<L DO)'^^@?K7GE%TZ@$!1"8VZ4LW;A3 Y>TG,!^M:_T?PQ_G?V>@ MRIH`$OMQ'5Q'[UP<O+%*3-[;I_O."/SK`#=21.4CS;_8T1N.@#8GJ$;?C3G_ M`(7_`#_TW9[&<(:GFXI:I,=%34?<\78`TC6]>6?[#9(K%N<L@F4QMTGZ;TA3 MBR/C5]:R\[*M.ODU'$_:'9MI5[A;..KF0ITZ;$;:52,0XIQ:[=SKNE(`U2A. M@%0<D[FAH =OI7.623.D<48CJ]Q*\O4I3=W3KJ1K"CI/I1,W#^1#*#+8.8). MTP=?Q-(94E#;I*4DY=,WK163JF7"M(\0&G:L=_)TKKHZ/I<`A] DB<P$P*;J M1 A*5'SB*[N7UPM*P7-3H1'2D.WS[HA:AEVB*!6<0 8`1XC2W5S Y824Z&-J M1).NDT#)B?G0H]PB\NK*\0Y9/JMW-LX,1YFO37LFQ+&L2X94[CB0MM"@FWN5 ME07<)UU@]!7G[V?#"E<2X>K'F^=AX=3S&0K+G&8""?0D_*O6=L^S<6%H[;*' MNY;!:2#X0GL!T@@BN^!.[/)F:W50KH*(GI2B=(HB*])R"3).@^M"B7(&AH4* M5-]>F]1KZQ_%!$:I/7_6_P`J=W*O":B[I1V!C3>)BI\FT1/$JFE8+>HO'TML M.-9%K<2"$B.G]KSK%,=NF+R_=<M+9NWMR0$(0#$!(3.I/\L^I-:)QW@BL48- MQ8J=-PV!G8!(2X #J >M92K01!'>>IKR9GV=L40`$G0"@I"@)( I/2:&O>N: M.P1HJ,[?.B-"@%=0(:)[FN2:5/@CK0@52W"!CBK!?^VL_P#B"HFI#AUPLX]A MK@W1<M*'R6*J]'P:[<2KCX3E(a)L*.H_\`;FM!O;H6MAS%0 E!43,?(5F=O=\S MCA(7$I84!/\`UW^9J_<2D_8SPS$'DF(]:]=TK/+)&18[Q[B;U\XBR6I#2#'< M_G3=OC'B&!"G%"(Z"JK=@ER\*M3S!)\]:8A1C12OK7EY)6=E!4:$.,^(925( M61$;C]ZEK#C''%P'&%%/FN/UK+&LRM,ZY&N].+5Y:% EU8U_FK2RN^R2QHWC M"^),3="<[:LO]^8JSV6-O+$+;40!U(BL%P[%G4E*0\H)'GI5NPW%=LKAVD^* M?UKM&:9R<*-A:O H2H*VF)IREX1H9FJ!A6,*+S*2X3F(2 =C5Q2\VA_EC0'6 M#O6[,T/^9X3N8UTJ%QJY#=PD$PA8RG7K$_I4BXL);*CT$Z=JHW$&)I-\VA"@ M4J5&HU&AUJ-D2[.%[>.MH64E,Y3,*\ZI.(7KA*LT"=SFZ5(8Y=J1;K6AP$*T MTC>JQ;LWN+W7NN%MN73P3"RB`E.O4Q67+Z/IZ2HIR9U8?<#3SYR_# C6H@W" MYE .W<5?;7V;XNY:I%]B#5LGXE(;;SJ'Y4:_9[@]LD^^XX\#,:)0V(^=<I*3 M\/8]7%?)0?>%Z21\Q^U*+R@DRE,'29/[5>QP=PFE:DG&;I64C9QO] :5<<)\ M)M:(O[M2B)!SS_PUCC9/]T/LSQHI?NVFU J!4)T.U68?>7"6D2%DI2!,DZTF MZP*PMKCFV;]RXA)^%:I"O+:K';XEPZW9M/6]MR+]!$I,F50==:\NIP3E"D?0 M_'_EL6GA*_66#C.\.#\!K802EQ;:&$=X(RQ]/RK)\&ND6%Y;.W3*G+4!*71. MN77MZ#ZU=>)B[Q7;VK5O=(:0T05<T$2=:IV*8%B6&(S/HSM1`=:,I.^A'UKC MH-//!C>Y=GAP9>]R=,OJ,'P;$$(NL+Q,!AQ)460H2C7S%2>'8#(a);.5U]YMY2 M>CRY_ 0*QIH*!"D.K0DC4H5E@?ZBDN..0#SUDS$E?Y#K7'4Z"665XYN)ZYZ[ M4S6US9L_$O'V'X79FVPK*Z\=`AF,J=#WG\*J_!G$^'I>N+7B2V:+KRRXBZ(3 M"9B 2!.DFH;A[@;'<6:;=8M1:VJP8>?5`5KOL3\JL:/986FO_2&.)92=#E83 MEGU4H5WTWX^&)/Y;^3P<D,=U*F_[V3K'&6!X5=*%M>(*9!/*_B(V.@-9CBN) M*OL7O;R2KFJ "BI0) $`Z#RJX?T!X>90>;Q LZP2DLIU^1)KNWP1PMRRK[=O M%$#HM!_))-:T_P"-A@DYQ^2X]7C4M[?92<*QFYPK$F;ZVA2VCJE1)"AUT(J^ MWOM!P1U3;B+=:5*0,X*4QF_P4V5P=PPG)EQF_ )WSI'YI%!W@?AY('*XBNP5 M&!XVC^HKMGTJSQV2-/5XV[W,7_3W!\O]2J?)*?\`DHW>/\+Y"4)843F!DI&@ M_P`(ID][/+=S6PXE*CM"DI4?P74'B?!V-X>A2VW&[Q"4R>4N59>^4UX/_"X5 MWW_^FHY8R?\`R_\`I=D<6<.K<SK=:\)!E2!.W72HWC3CQQVY9:P.Y"FT)',< M60!_= '^M*S<.%&8.!(RZ%*DB9](I:WU-Z*"95$Z`DZU,?XO!"6[M_QG234F MG-VS4>&$L\58'<W^+VR7K]MV,Z7"F$C3:=M:@/:!A]IA.%-)MVUAYU83\2B. MIV)\J:X!P;Q/B3(N+"V>LK9TE25K<RA6HZ":G;KV=8E<)0K%\?2"V(E;:509 MVU6*]4M%>13BZ7T1Z^48N#GT9J"4)$HV)2=1_KJ:0IXF83K6HM>S'"RG,]Q( MK.?Y6F^O^_717LNP3ERKB"Y)G^1H#\Z]NQGEEJ8529DI6H_P@ZTUO%RN2(TB MM@;]F?#R7TI=QR]""-2D,_O1/^RWAE1AGB&\S'^9#:M/1-78SR9,L6S%P01I MO1YJU2[]D2>6HV'$#+IW"7;<H $'4JG]*I/$?"&+\/H2Y?VTVRXRW+*N8T?] MX;?.HXM&%),@"2=)JX>R=2!QYAG-0'$_>'*HD#PH*AM_=IOP;P5B'%B;I6'N ML-)MP"I3Y(!D[:3&_P"=7K@[V9XM@O$MI>/WV'*0WF2H-N'-XP4=4_VA4BFV M8E)=JS2^*.-K7",7%I[JE3KSBDM)!F0#$;'N*DCC&3!W[VZM6$)0RMW(=5'* M@JC8?RU3U,BZ]HKCBPTI;317X%S&=:(Z#^57X5,<>6]U<8!>VMNIY*5,. <M M)7KD5W/7:?.O4<$[?IY[XZQZYXDQ%.(W;33!>DH99G*E`T&A)UWJMQ%7_#O9 MMC>-8/9WEJY8LM%)!1<.J2M)F"",OE(KJ?9!Q#UO,('_`/H5_P`M>9IMGH4X MKY,[,T4&M'/L>XBB?><*(\K@_P#+2D^QGB<B>9AD1,^\Z;3V\J*+95)/PS94 MQ!I8D"1ZTN[MS;O.-*6A908*D*S)/H:YJT3([5DT`*46SJ(FN9]:5, :3Y4E M2I.P% @J`/<F@*/:A25X?PV\Q/$6+3#K5=Y=N$!+*4D@^9CIM7JC@7A^YX<P M!%I?WR[N[7E6[KX4'Q>$:=)->;O9QQ?<<)8\U>-C.S\+B0-0F1L?D*]48+B- MOB^%,7UH0674I4(),3.E=\*/'GNZ8[G2*([&C5HF:(G:>M>HXT()S#6A1J3 M\J%0T4>X.AFHJ\(*3/72I*Y,@Q&U0]\J$:J /0=SVK)T12N-^(E84$L6P/OC MB00X?X!!'A\_K67K)7.8R=_KO6J\580UC%NIM65NY;3S&W H;!*M%&LJ<\/D MK017DR>G?'X((THE"!1F@K:N:.B"Z4449I-4H<4M8 `BDH^,5U<$H/K0AQZ4 M\PA11BEF1OSD?_4*:#K3O!TYL5L@>KZ/_J%5>@U&X;*./\B0(Y2M_P#KB/TK M2;UI;U@$@9E9=4]QK^L5G6(#)Q^%2=4+!_\`CJK4+9T-H0M40E,Z]=:]<5U1 MYY?9C;W SM[Q5BV'NW"K*W4H/L/EHK2XG:-(Z*_"NJ_90T%E(XB9)_[,?^:M M1O<7PP)::O'D)Y:0A 64R `!V\JAW&\`N#/OB>\`H/\`PUSV1^0IOX*,GV5I M1JGB)F1__7/_`#4M7LL!`4GB!HZ2?]G_`/NJWJL<!_\`Y@'S3_RT:+7 T$Q> MR.Q*?VILB7?(JC'LR6D>#B!!\O=P?^*I5C@55L/'CH5IU8"1^!-3J;#!G-6K ML;:@*2/TH>Z82@P;PB!MF )^<55%(EM^B\$X;M[2X:N+C$>=D\0!`"0>YJ8: MQ!%_BPY)EIE)!5.^HJ*;PW"W@ 'G5@G4%T'\!4RPPS;6(;LX`UTC;]:I*3([ MB?B-JU0JW9,+B%*)VK-7\9#MT753RD)B3U-/<8P.^Q#BVXMKAU+%NIL.MNN@ ME"C(&73KJ3\JK7$6#XOA8Y;S*';-LC[ZV,IZ])-<Y2:-QA;%L%[&<58PNQ!S M72PT@DZ)&ZEGT -:S=W6%<!<.MILF05+2"$QXW%&<LD1KX2>WB%9Q[(6N;Q< M7G4I6;:R4ZF>BB0/I!(^9JR7BW<;]H:&'27+>T;B"!.;,?EL(^56#M6;R2_] M5X=K"RXAXH(?Q.Y596BH4EIH:Z[3,])IXYA?#6"@>_W+BG8B2L _@!VIYQMC M'V)@\V\I7E$:=2%=H[5@MY=/X@ZIVX=6HG623-)3VF(POPVH\2\(H)3S`KN% M9E?F:Z#BCA50`EJ/0C]:PB&@/ZI2O4T(0=F#\S6>;^&^,W=.+<+WJBEM;043 MH 34DQPSA5TE*F)25; I'UB#7G@%D?%;GZFK1P;B-ZSB+:,!Q M7)!RVUP3D M</\`*/6.]59+9EP^C:6.&O=\N5#3@B"%#?Z145Q5PPI.%O7F&/%%XA$^[2"V ML3J(B?QJ9P'B7[2LF7G[<L/SE=:*M6U=C3O'7"BUSI(VS3TBMOPS'=%]'G&\ M6A:N8EHI))"FB?A(4!^M:-[(.&;:]!QW$TYT)>Y=NE0D0"F5;;P=]MZS;$5! M-]B `2E)>4L)&PT)_,"MEQRX^PO9Q;,,RA9M&D^'0E?*2.G=66:Y079ZIY9- M4(Q3C3$\;Q%S#N%FDI:;5E<N22E,R1 `(\O+>G=OPOE!N.(<6>6O=0S@1Z$# M:G?!&%LX'@*%) E*?XDI,R<W::R_VA\476(X@NU8>4FW;.402)WWU\ZZ.5(X M4VS0S?<(6)"%7(48_F52OZ2<)1!=;TZ',?S56#*0E1E[.M78*TI,-1HP9_O5 MCE0XK^3T$SQ!PL8Y;C:2=)!(_6I6U1@U\V56SBU'N%$_F37F<!@'6W5'D3^] M/[&];MW JU?NK5P`QRU$9CT&I[P?0466R<9Z2^PVPF65!0/19'Y$5PO.&FKU M@H>4;?*-%M.D$&>G3\*@^">*K^&K+%4"X:<1-M>@^%T3VZ0(^=78W*7K52VS MN-HVKJNS'<7:///&ME<VN,7-E>A/O+<\MY"8#R0=S\JM'L3X;M+]=UCV)-\Q MBW/+92I 6"J-#!&\@">Q-17M7NBK'+).<@I242/Y5'6KCPM<'!_9?:+MTDE2 MVG")B2<BOS,>E<5%;CTSRR<:'N(<58OQ#CCN%\-M-LVS2N6Y=P4@D**590DC M32=9KO=.X-PRUS,<Q!=Q<JD*U$G7383T/6E>S3#DV?#%J4I^_4VE:B3.JXD_ MF?6LF]I35TOB-"GB5H=;26I/0)DC;SKHY4C@EN=&A_\`G/X?"B+>TN%P=(0N M/PKL/:AA13IAM[/;*O\`8UA)NG&TY4K0D _"4DD?417%5PXLR7$D^2!^U<N1 MFN-&_#VF84K5S#[Q*4B2>6O3_NT^PGBGA?B%:6F[@H=,@)= 3^!)/X"O.S5Z M^VH%+@$:B6TFK!@6.6F=QO'FU/,Y#D6WX2E122%:&-P/K561DXU\'H+[-PUO MQ%41!DI 4@GMI^-4+C]ZTPJU5<83<E^W6K)<VCLJ04%0DZF9F.M9=<XU>WB$ MF[QF\60A(CM$P/B'2F;K@4@AV\>R*T.<*-5Y2+'3LU_V.I+%MQ*C#P4^%*D` M$@#0&-]ITJS6_"N+/W#SUWB3C:5+5RT-N$:9EI!,DZP$GUK'<&XQ."X1B5G8 M)6I=XR6R\ 1D45I5F&OD1\Z1PJX_C?$-K:#%<105F0YSXB-3I%:C->&=C[;/ M0.!</M86M2RM:W#&=Q:B5&(@:^GXFI:[NK>V1-P00H;%`5UG6=JAL*OU-W+= M@_<JN'6$\M2E?$=8F?4&J?[9L2?M<&"&7%(4ZL()3H8*5G_A%=+KLQ&.Y]EN MN;W";L*;1>)8.Y0VM4>L!0IJ+*QD$8JZ-(\+BQ_QUYGSAL)*W7DE0!.1<4LW M3>72XO)_ZW_*N7*;X:\9Z:38V:?$<4>5`G5YPC\5U4/:MQ99,\./87@]R^J[ M6MH*<0\L0G60/%W 'S-8K[VW'_K-Z?+FS26W;9*I4JX(!!@D=_2CRVBQQ4[. M>(JS/0$I2 VW`$P/`F=SY5PD1"MHKI>.(<?66,W+A*1F,G01^E<G$B0!VKB= MSF->L11G+E.AGO1Y9WI)&E )%*3$Z_G1"@.M"FI^P_(a)W#.([]Z\Q6Y2I%HL% M-G.KI\]#(KT:A*$,M);2E*$("4I2D)"1KI BO'G"&(8IAF/VCV!\PWQ4E*&T M$_>3T,=*]>V*KIRQMEX@AMN[4V"XEM689O7H?*O1@H\6:U/L['410C\*!&E" M-*]!@2JA05\-"@*!<]?2H6]44I4H$Z#IUJ9N8(-0UZ8&\><>1K#.L3-^/\5N M6'18LH4TRI()6-G)!&GUJC'41$ 1IWK4.*[:UN<.<3?J#:&PI3+AWS!"B$CR M) K+U#+L9&FO>O)/T[P$FC4-).U S&VO8T1)C6LFQ*J32U4FA4*;C-)Z5V * MI KBB ":6DF"08(%"!*3D5$$>M/^'$!S'\-;.RKEH:?WQ3#.7/B,D=:D^$@% M<4X..]XR#_C%6/I'XS3L3D\>-$@>)M<__'4:NN-N%G"2M.I2T2/K5/Q1'_3U MKMRUG_YQJWX\D_8JCU+*QI\R/RKU72/,SSWBER[>7EP[<.+5E5 A6U,\R('C M<_Q4\Q%E3-U?M*$%#A!!(_F(J.RZ:9?J*\C;;/2O#JE;8/\`6._(TKF-]'7O M\5-\I[I_Q"CRGNGZBB;+0Y1<9#*'WP?)=/6\2\.5YZX<$?S3%10228)'U'[U MW0R )5$>1'[TW,*-DO;7]JAP.-W]^PL=09C\*U?@?'KZVM66[]]%[:W"%+M[ ML#L0"A0[^*?E6(E"0M,D!,[GI6I$-.H]FF=X*"4.//-Z1E2!O\`-4?*:W"; M$H5T:BT^U>L!*FTN)2 F%#K/[36>^T9I&#62+_!BE#:5A#[!DI*23.GK%3/ MUXNYPMEQTDJ4A"B1IKUJL>U%Y7V:&@597#!2/[U:G+HRH-.R*]E"N3CN,F3I M8DI)/FDQ5LX6ESC'%7%1/. T[#-_S&J3[+%G[:O@HB%X>2J?[R1I]:N/"3G_ M`$FQ`D(a)A;Y5H.DJ_85(RZ-K&Y.R.]K]PI++.51RGPQZ!59B$2A)2OL2#6H>U M>V4]9!U(,(@D#S"JS)EH)::43.9/0USG+LZ8L?[4#E3_`! B@;<Y=P/G3D-- M$;R>U=$H9'>:Y;CZ,=/%C)VV(2(4-1K7!HNVEPW<(^)E25@GR(J44&R#UK@I MGGGD(/B=*4)'<E0JJ79RSZ=+PVOB$^Y8TVZV2E%RLA21M)6D:>@'XU/8MX\! M),_U9B?4_M55XW=6'L.6"!F<D ]Y"A^!J<QE_E\/D$R$M$:^L_K73>SC_G73 M,)Q=E N[PHD$F-=1O6P\<_>6N&,>$H4M@E,=EM"*QR]=2IZX4DP2H?G6O<87 M(+^&A*Q*,B]>X+9_2LQDTS2Q1?A9KI(:X<2$$Z(B>I\(KSY>6V;$'R#K)_.O M0-^X58&$(.:$D?@*P:^048C=),@I,^<5)S;+'#&^QJBR5$J69KHFQ&4PHS%. M$%(`),R*6HHR#O/:N3DSZ\-+AH9+P_0>,'3:>M-'+-2,Q\*H!T),;'6I4E$Z M:>=-;@9@HI5H01IIT)_2BDSS:G28TK1I?!3:WN W/'"K5U9:/HI6_P#BZ=A5 MXX3N5W.$J<4J24Z9=JI/`H4.`;E>W/<<*9.@\1&OSJR<`W 3PXAQ*I2I"E)! M[2#K\B/QKU1R-(^8\$:,Q]IX5_2).BAD3/E,Z?C%6?A[$[=[@"S3<*46[6Y: M0$T2!E22?* *J?M`N1<8^Z"2J/F*B<)Q-=B+IM3?,M+A,.M), Z1._G/J!6 M%D:=F7A3?3/1>$--8=AK:,R2RD#(=3F2#X3(\H^M1N.8#A6-V[86X$/-%*V5 MI.J2!';\ZR&PXLQ2R046%V'K0?"T^3X!&PUVTKM_3C&DA2@P([AS\JZ+*CF] M/3M,T]YM3#!0]AUI>+2G*5%.I\Z8J9L'$I#W"]JXH;_=!7YU1&O:/C0']5F] M' )^HKHOVE8PG4V:5>JQ^QJJ43F\;+J;;"QMPG; _P#9D?O7);&#I'WG"-OI M&UNCI\ZIR?:?BI5'V>D'^\D_\-2-C[4AS G$<,<"(\:TA)RCO$54XLQM9.FR MX=N1#_"[8*U=&TI/I(,U6N(^$>&BA7(;N<'>5JE3CA6W/8R)CYUI-FYA.*6S M5S9NM95092 %?AM1<1(LT8(];OH#C3C9"BO7Z5JDR),\VXK8O6%XMA\YB-EI M^%8[BI_V7C/QE8@S&5?XI(J&Q!:%6ZD%2UJMW5-H4HR<FO\`E4_[)D)<XULT MR0`%3/R'ZUQ7IMIM&JX8^M?'.(2J4Y75`=B+AS]JA/;>X?<V1_[8#_Y:S^M/ M.'7 ]Q9>/*(.9I:C'<ONDU#^VMYM26PB3#LGTY:A^M>B3Z9SBOV,EN /NX_E MKC)BNMQ(#<[Y:X]*\J9V3!)G6A/S]:O>'>S/%+W"[>_3=V+3;Z<R0ZLC3Z4X M;]E&,.F&KW#%F8A+IG\16E%LF]&?3 !/2DYMZF^)<!<P%]IEVZMKE2TA1Y"\ MV60#K\B*A5"1($"I1;L"=9C>B.V]`:"@=MJ 2* ZT*- !4 :`U+V"XK@F&\3 M+&*M`7CN46MPHC*V9'?K7I!6J)T43"BL1"ID]*\;\*8%?\18U;6.&-N*>6H> M-()#8GXB1M7KC \/5AF#V=FJX<N5,,I0MU7\2H]*]&!L\>9)330^/04*!&@- M%7H,"5?"*%&1(UH4!G]T/#I4'?2$J(a)%1Z)&F;R_.INZ,U!8D4A*^8)1&M8:. MD3+N/_?4X@E3I"[)<%DI!"3'0^=53Q90/+>M)XNN[6VLWF[U(=6X1E;&X5!A M7TD?.LUT"=NM>27IZ(^!K65@9MQI1$3IH*!).X@10,=9.E9-H0K:D]*64G)O M\J10J -J,;45"@#&E3/"'_YKP;SO&?\`Q$U#)$T^P1\6>,6-RN(8?;=,] % MT73)5]&K8P^!QRU!T4VY!/DZH_I5W<6+BS"%F 4#6.\U2L00P[Q"J[4XE*$# M25!.A)5H#K_%1W?&5E;*+:'4>&$]3M\ZZ[RK&DCK>\+VB>(KC$WV6;RVN4D. M6Z_X5%6;,/H1UWJ/NE\/,NJ3_1NW\H$T3O'%FX"'5H4#Y'3\::.\6X6I1.5. MNFB:P:VH[>\</0(X=M@?[M&'^'^O#K'K%-3Q7A)$%(T\A2D\685'P@CTJ&DH MC(a)O\.D1_1]C_``S7%0X=48."Z[PE,?J*3_2O"H_JT_(5S<XKPTB D*UV4D'] M*AJ,HQ'C)X;:DJP,0=/$@F?^]3S%L8?QFR3AN&6?NM@<J5KG7*)T`Z3/X5"C MBS#T:I:2#Y(`_*NR>.[9E$--)TZ!,3ZT-<D?DT/ K=.'6*4*)$ :1_K2LT]I M&)-O7;;*%3DDF.\UPQ3V@7#S)0PG4]3)@?6J5>7;MTZIQQ2BI1S&>E9:,RR* MG1;/9M<H9XF9:5F!N;==N#YZ*$_X:M6"7"V,7>?,@*7$'O)G\ZRBUN7;>X;? M94I*VE!23/45:+7B)+6(+NE(+EL\K,M&ZD'J1Y5:$,M*F:OC33=ZTI)"2E20 M@R--C^]97?\`#CN'O+M[N4LE4L/ R#Y'3_458D<86K@"K=Q(21!"P1I]:#O$ MME<-AMYP0!Z_G3:F:65>T54X#B($L!IY']E5)&!XJ!/NI'F#4Z\_A;H*D7'+ M.VDC]:XCW)*2$8HI,C<*4#^=9VHZ<Y%MX!BSA"?=DRK;,J*G>'N&&[:X;O<8 MN6FTMG,EN- 0=YFF;AM2$E6+N0!IXR8^I--7E8/!-Q>/O@?PE1(-511EY[+' M?XNCB+B1CW4J]RMU9IC<A73R\4?(4\X[QU%OA9MD.#.1! \Y_:JBOBFWLV U MA;!2-M4Q%5B^O7;QY3KYE1[S%*,2SOP2ZZ%(=UF8-:3C%\+QK"'4%7WC*5>< MQK\O"/K67B(Z'UJ8L\4=]T::"AS;;X#W1U'U(^E*,0RM,V:QQ W&&!&<J4#V MTFJ1Q;@;ZKQ-];H4I!A+R4]MY'TKG9\7VGNR4* 87EA68$B?K3D<5VL$+<2 M8U'7\:UM1KE=E;3A+[B<UD\A23KD5((H'"L52H)]V*CO(.GY5-7&(85<B>:$ M*)DE*B/RBFI58)\2<36G_P!XO]ZQL1W6J:&0PC%G/_V:AYDP/RJ0M."\1N5G MWUYFV9(DY3)/I7-3EHI)2<7<*2-07%_O7)YS#B/O\7N"GH$K43^-512,3U+D M6GB'%K*TPAGA[ SG6HA*U(UR$DDG\:FO?V,#X<"'"$94%*1WU_U]!6=-8[A6 M&I<.'L+6ZK0K.YUF2?E4'C6.76*J5S%PWN$"0!^-6D8Y^J$XG>BZO''B?C5F MZ@5=4<,</-X;:W%WB#R5O-YX`T'X5FZIC<:CH:GTXP7[*Q2L*4;;P*1F/B1_ MJ*E$AFIVT6:VP7A1Q:0;Q]T*T\*3^@%<.(\&P"R#5OA:[I5^\ 4`E0'7]A72 MPQC!$LI+,I7$E)D$?.G-QB6$7[: \<KB-4.!6HW_`'JI&WEC+X,_OF+RU5DN MD7#:TZ'/)!]#37G+`_K3/D2*T]J^<2T$MWEM<(&P=1.GK-*][Y@*5LX>3W* M*J1YZ^C+BZ5 9EJ5KU42:E,!8OKO$6&[-MU9*A/AD1UFKS[R6HRV^'A0,S U M'UKJ_P`07;+65MZRMT[YD&".G>E!)?)/A3.#XTS9V+8:%P4+4A'?*9)'K^=* M]I&+BUP4I*_&XB!I'6L_5Q!;63[ERAY=[?* `<(.5'I5;Q?%+O%+@O73JEJ. MR=8`K2E71&TQJ\O,TN<QS*.M6OV4*2GC:V4OX<O3U35.5)&L@:FI7A;$?LO& MV+DG05E&35N%%-JQE]P`A*TE`,=.8L_\1_"A[1L+^T+![E!1<2,Z8ZZ&JQPY MQ);VH*+MT,7#68 $2%^*1^9J;/&+/,"5Y# [S72[*E\HSL8%?7UBS=V%NJX! M&1Q"/B0H="*5A_">,W=RAI.'W#:20%*4F !5R5B%D7W'[.X2PXX95E(U-<7, M5>;0N<;Y2=R8!^6D5C:@R=XJ?NF&,+P/"GBJ[#0:(02,O4J,'L/QI'$/$+/# MF%"U0XJYQ!0!S$DY>J3OY:U4E\2V.%\QS#E.7E\X-;AR?#Z54+R^>NWB_<** MW3N3.W:MN=>$44A+[Q6AH*^(#4]3H!^217."=*Y$STIPRI)1"C!Z&N=V4Y*$ M:&DFNCR"E0!4"3VKFK2A!- :;4*4B)\4QW%"EU]E?&CG!^.J>#:#:W&5#VX( M`Z@S]:]1X??VV)X<Q>63R'6'4)*%`DP#.E>6?9?P8OC''_=E/)9M& E;ZBH! M64G0#0ZUZEPVRML/L&+7#T!NU80&TA(@&)U/G7HP6>3/6]5Z.-])!^5 C2C, MQN?G0U^5>@YB0*%!6E"@,\N=CZ5"7QT42)TV[U-W<B8B(J"OB8@;["/0UAHZ MP,QX[PMX79OTJ6ZVN 1,E&A,>FE5("1J3![5>^,L839)-K;%M;[@^\(U`$'3 MUVJB-E)4GF3EGQ$=*\<E3/0O`E===(H03$;Q7=YI"$GE+2M!V5V\C7"=M1I4 M-("DE(U$'L:Y;FNBB5G4DFEA$)U&OZT%G&CCO3UJS4M()(]*ZIMUM&4@*.U3 M<BTQ(a)AIPCPH6?.*/DN#_`/37]*D^;=)3`&FU*#]R0-$Z5+0VL;7]U>8C<<ZX M2LN90F0"- `/TIJ;=SJRNI/G7/4)I8?N(_JTGTJVB5(BDVCJMF54?NCH("F5 MYCL!UJ4#[X&K5.L/Q2YL7R\RR%+R9!(V,@S^%$T-LB ]U="5DM+A'QG*?#K& MM+-F\"4<E>8:D>70U;5<172K6Y!0@*NDY'D9-SF2=/\`#1O8ZH7;R[>W0&UE MO+*=8!$U;B-LOHJ*;)XCPM*5*L@('\74>M#W5P#5LSIIUWB*MPQYYD%3+3*2 M+EQX)C<[#\":Y(QUU5V7UV3"%<LHRP53)!G??2G1=LOHK LG<BE!M65"LJE# M:>U$+5P"8!3!E42*M-ECCMK:VS:6VR ZIU84B0J01!^M$QC"F[1*3:M*E*]P M-9/6EQ&V7T5KW1T-I6XV$H4`4J(@:]=*Z&P?2H)6@A1$Y.HJR.XV\[:M6A9: M*$I 28[&8/E^U=OZ0NKN%O.)9)("D*(WC2#Y:T_4;9?1548<ZZI(;!7F) "= MY@FDBPN&ERE)"@!("H/I5KM\>?MH6RAA*PH_"B1K,DUPML15;.77*4AP+@DJ M;D@SN*?J7;(K*K&X4L)4A*E=?+UH##G^4ATLJ#:YRG76*LYQMYU=RV66F^:) MSA$&0*[?;=PEKEH4T6@P$!)3(!)&OX4_4FV14A8NZ@`3$P%;#UI M'"$Z25: M:&K3:WRK=E]AM;1:61]X&]1/K708PX+ZW;0E!:M^JD !1@T_4FV7T5-=D\G, M%H(R&%$G23T%)-FZD3D($G4R*MR,:<2P`^RVZ$N\R"!O_HTK$\3-\P_;`-(: M)#@)`D>0^M.B[)E0-HZ J4*5`G0$B@+5PG* M76(/7:KC]LO,,D-!CPM980B M9Z:UTM\>6IMY:\C:BE#:?NQ(@'7UI^I-DBGM8<ZXH(2%*63 2!U[4MS"WD** M' 0M(D@:D5;;;'%,E"LZ.8E>?-RQV(G\::C$G&'+EU"TNNOF2I2)@352B;VO MZ*VYA[X0HJ"H2!JH>=#[,<"02@[D3K^U6VXQQWD/E;B%*)3E0EJ)C7OY4/MV MZ<"%*4TT9SE"FY(a)[=_.K^OV8<9?14OLU0*<S;@S20>^GI75>#/-L-N.L+"5@ M$0==:L[>./CEI<=2H D3RIB:Z-X^Z"H+N22!RT_<: =ZGZD49E6;P9UPN!-N MX>7H3F\C'2D?9AR@\EQ,@1N9/4;58V<;O$AS[[(G,#G+.JOQKNG&W4D!RX<* M6R2G[GJ:OZEV2*U]E05 MN"!F\0Z1Z5T3A.8I\*I*0=!T/RJP#''E0M=Q*LA M206#L?G1V^/.LLY@[F6$Q!9V[4_4FV97U85,MH8<*O231*PMP,E[DK2@G+F. MAGRJ<3CEPDD^^D+SS/(Z0=/2N%[B:G+%ILOO/.-J\ 2W`D_Q'_76EQ&V7T0_ MN@.5"49]=H@_.EG#E9P@6RSFG:1TJ3:O$V]S[PE]U5PE,26<V_2*=N8U<A2? M]N<)!C*;> `0=1YTN)-DB&M\&?>0I3-LZM"$A1"5G3R]:0QAREO<MMMQ3B9" MT"?#H34O;XI<("4-WRTI0J=6HS:$:_6D6]_[LIXLWCHY@(<66_%)[43B-LB- M59/%M15;.@!(DD2!_E2T\/7EPTAQFS)#GP*)B1Y@U)/8T\FTRING5D (2$MQ M*>ZOP^M(7B]RXTLKO5I6ZD A+9$`?PCR.GGIO2XC;/Z(1_"W&RH*8<'\)R@F M#_KK2/LIU:D-H0\7%F$C+N>U6%>.7CCZ'/>52D#*GE>$`=*2O';M`<6E;KCI MV3D`2GS%2XEV2*]>8/<VKQ;<;<22)&D_C2_L.]*,W*61ES&.U6%S'KDI80VL M-EI!!)1)43WF@C'[S/+KQRQ_"C\/2EP''/Z*U[B^K*%)6<PT"DF3\Z0]8+:$ M%*D(a)?$9.4GI&E6=?$%R&T<MQ14@0G,WMY^O[T@<0WN50*6E D$)"(V,P)[Q1 MN/V50G]%8]R<.VL]9,3UHEV*Q( $^9JP8GBU_B"D!UIII"%*6&P!N>NE,PI^ M).0?*L[HE6.;(=5HZD?"#\Z0NW="3]VJ/+6IQ2G\L-E&?S3I4?=W-\RHI>); M\PG0_.B:?@<7'TCBA8&J5?2@E"^B5?2GH?>*`I2E'UBD^^+2==15)9Q5S,D+ M09'4UR5K3PWH4"%-DUP?4A1!;VC4&A!O2DF)TUZ>5%1H$[4-$KPYC-[@6*,W MV'.%#S9$"3"_(@$37KCAC%'<:P.RQ"YM7;9YUI)4EQ,2=9CRKSM[$[# +WBQ M*.(74I*0E5NAQ4)<7.H.A^7SKT^3X$ @)(2,J0= GI [5Z,"9X\S3D).H^=$ M=*/>B(TU%>@Y!*VH42J%"F>W0,'M4'?*T(DI\TZ'Y5.W8'>/G4#B$0=<P&J@ M.U89V@9WQE@8N.9?62"'VT9[AL'3+MF_*J,#U&GF*NG&V,K0XK#K5:T)@<TQ M`5Y52^@,5XY/L[H!,'4>M!101(!%$3ZT9U,#KTJ6:'5HW'C4G78#I70-<Q[0 MZ;F@VP^Z$I R@#>I!FWY:,NA/4]:Q*2-0A;L(I\*1IIVH%,FNV28TVH9*Y'I M1PR^M&!Y5W"#0Y9H5(X99Z493 KMRS1EM7:I0.&7304"DD$1TZ5W""-Q1Y)% M*+V<2G,"8@GM2LG::Z!&D4K(J),1Z4HO9QRD#8;1J!0`,0/"/*N^0@$T>4P( M%+-(X98`RB#.IWGZT"C^R-?(4XR&/\J/(3M4L#?)```"?,"EI; &FW8`:5W# M2MR!2P(a)]A]*A51QR2DS.WE2BWX>P*8IP$&(C>C#9Z@]MZAND<2C0:4DMC0D3 MH!]*<Y#VVI60P/VH*0U+((.8`R(UHRV"#($=A3G(J/\`*C"#&H'RJ]E5#4M" M08.G32DED$$%.^FHIYE)V%'RR!TIV6D,N7!)(a)?(4.5/0>L4]#9(T% MK(@I$ M>E.Q^HSY/@UUFB#4"(TI]RR-,HH%LQM3L?J,N68$2(ZP*'*@$0()F*>AHZ:# MZ4%-*[#Y"G9.AF6I&LQ0Y9B)41UD[T\Y2H^&@6E=A]*4R4AD6ID2K41OM04V MHSXE"1&]/2RJ/\J')5&H_"E,M1&:FRH'7>@IN9G2>U/ TH; ?2ARE'=(^E*8 MJ(SY>I(4J3VH\BX,+7';2G89/\OT%'R5=HIV*0SY:LD2J"-3.M%RR9E2P>\T M]Y2NM%RE2=!M2F*B-"W.Y4:+EF1JK3IWIYRU`["@6U=A162D,^6?/ZT,F\R1 M$;T[+9&XHLA.PI3%#3E^I\IHE-R-9^M.RVJ-011*;41IK4IA)#,M;Z R>M(4 MV4]H\J>+0>VE<U(FBM!I#,@C;\:$:;_*NY;.M(Y9B8JV<Z.4`" `!02D:^6N M]="E4'2B*3'454!;*,Y@C<:U;\)L+:[L2S>,(=;C0*,0>]5BS0<P]*NN!@I: M$$@Q7;$NSAGET5W%?9V^$N.X*ZFX3OR%@@@>1^E4;$L.N;%Y3=W;NV[@CPK& M_H:]`VIG<3\SI^-/[BPM,4M_=\1M&KEH]%#78ZS7I<+/%NKT\RH:)41J`.^E M(C0CI-:]Q1[)\S"[GAEY14=3:/$`GR0>OH:RN^L'[&X<8O&G&'VU%*VG$D*3 M6'%HTI*0T'6E-R"8U\OQI02(U `'?2C.41!3VT-8LWX/,%L[W$,18ML+;<7= MK6.4$;I,Z&:]=<)VN)67#UDQC%T+B\0T@.F-08T!/4UYM]EO%S?"7$/O-Q:, MOV[R4MK6?B0D$:BO4.'8A:XG8,W=D^AYEQ"5(4DR8BO1@]/'GMNF=XH*$#2C M%$O:O2<A&]"C,BA0J,[NF42?`DZ=9J$OM!$#T[58+L")U[5!X@C336N<F=H% M(XHPQO$6QF(1<)@I=C56AT-4QS GD 9WD#SFM'Q!"@-!)VFH%ZS6XN"D`=Z\ M<_3UP294/LH@QSDDU)X=@B4J#BI4>D[?E5DM,+C^%)/G4U;X=H! B*PDV5N* M*\WAJBD2!'85T.$JWRBKC;X?`'A&U.CAXR[;5M82<U%#.%J&Z=*+[.C^'6KV M;#75(B*Y&PU^&G$.:RE)PTG=-*^S(Z"KF+#^S0^SY_A%.(JS44O[,GM2CAAC M5(JY>X '1(KI]GZ:I%.(<[*2,,UV%+^S(F!5R%@.B12O<9_A%.(O,4P8;Y47 MV7-77W'3X1]*--@/Y1]*<0YBF?9IRD%(I0PV(\(VJY^X`CX11FP``.44X4.9 ME-^S"1\-&,,T^'6KE[CI\,>E*%B-HZ=J<069E-&&G^6E?9GE5R38Z?"*5[@, MOPBG$.=E.^S!$Y0:'V;IH@5<O<?#\-#W'2"-Q3B+SLIQPPC^$012OLPP"4U< M4V(`@)H>XF=!]:<1.9E.^S9_A-&G#3&@U\ZN`L]]!2DV/E18AS,IWV:J#*12 MAAICX15P-CH9&E 68_EJ\8YV5'[,,;#Y4#AICX15Q]R&D 42K(1L#3C)S,IY MPPQ,"C^S.F7<5;_<A'PQ2O<^L4XQS,I_V8?Y#0^S3_*:N LQ!D"B59@QI%., M<S*@<-('PT$X:=RD15P39CIKZT%60[2/.JL:',RH_9NF@'UHAAJB/A%7#W,` M:)3]* LQ&J13C0YF5#[,UU CRHOLWLGZU<%6:=PD31^Z"/A'TJ<1>9E/^S=- MM?(T7V:>Q^9JX>Y#>*(V8 VIQ$YF5#[-(W31?9L_PU<?<QT$^M%[GY)IQ#F9 M3CA9_EI)PWH$ZU<E6>G3Y&B%D.@_$4XAS,IIPT]4BDJPS31(^M7,V7=/UHE6 M0(^$4X@LS*7]FGL*YN89($]ZNON('041LA&@%3B',RD'#.H`_*DJPL]JNYLA MU I"K),?"*<15G92%86=HKFK"R 8$U>56(/\(I"K"!\(IQ%YF416&JCX8FN2 M\.5%7U5A.Z:Y*PX'^&G$%G:*;;V*DD&-JLN'(*$IGM3].&B(":<IL2E(@:BM M1A1SGDW'2U5M4Q:[;_4`_G44TRI!VC2I*TD@#YUV1YY$Q;JC:.G\([S^E-^( M^&<*XGL^1BMN<W\+S2?O$>8/SZS7>VC3N:D6B>R?.0#/UK:5G*Z\,M5["V5+ M6IG'W4()\*7+7,8\S(%$?8.L`E/$B1ZV7_W5L302(A*1/84Z3 3\*=?*G%$+ M+(QFT]A##3K9O.(N8U/B0BUR%0[3)_*M;PO#[7"K!JSL&N3;M)2@)D:P-]J> M1VTZ::4"(2!TK4<:CX9E)R?80HE;48WH*%;,B%:BA1JT%"@LHMPR5)\JC+FR M*@20(JS.-@)U$]!3=UC34#6L-'1,J+V'IG1,&*:G#I.U7!RVD" )KF+/785Q M<.SHIM%<9PX`:)%2+%B!H$QI4PW:P(@4Y1;QTZ=*J@D1S9&-6L=*Z*M014HE MD#I1J:GH*W2,[B(5;:4@V_E4SR?2D*9@:CZ5*+;(CW?6(,[T!;GL*EN5Y$4? M($3XC2AN(KW49>E*%N.TU*\D0-*,,3TI0W$2+<=J,VHZ"I7D1T^M'RO)-*-* M1%>[>5'[K VJ4Y6AT%'RO+SI1=Q%^["*/W?3I4GRM-J5R1V%*,N1%<C2(%+% MOY"I+E0)@4H-#>!-*&YD7[M VH_=QM^52A:D;"@&?*I0W,C1; ]#\S1^[>0J M2Y4=*/E"-C5HJD1HMM-A\J'NW<5)!J= /K1AK+N!2AN(WW8'I%#W?M4F&P>@ MH<D'H:4-Q'&VTUBB]V C2:DBU V-#EZ4HFXC^2#N(HC;B-I%20:TVFAR?(TH MJD1O(&7:C+&FPJ1Y6D0:(M:;5-I-Q'*MQ @:T?N^@E(J1Y6@Z4.7%5(;B-Y, M#84/=QEJ2+8.D30#<?PTH;B.4P,NVM ,"-OK4B6I$P:'*_LDTH79'%@$=*,V MX J0Y0_EH^7IHFK1=U$8&/*CY ["I$M0"8H!L=NE*&\CBQ(V%%[OW J2Y0BA MRA&PHD-Q&FW$["B+`Z "I(M#M04UIM2B.1&<B?.BY C8U)AO*=J'*I039&<@ M=J)3`CX:DRUITHBT0*4-Q%^[@#;ZTGW?78?2I;E2-11%F-0*4-S(HL&/A%)- MMF'PQ4J6I&P%%RO,4H;F0ZK4QM0-II4OR?G1\GP[4H.9%(LXKJ+2I-+6FU=0 MR,NQJ43<1"K/3OTHTV9&VGI4OR1&U*#7I5HFX8--+09J09*NH%+#9C85U2V1 M$BM)&6=F^GI3Q(D"FS:?RIPDZ"M&*%&@1H*&]!72J!- [T#1;T 2M:% T*$( M13<@[4A3)@=:>%(UI)%2C2Z&):\J`:D[4]4!%$ *RT:L;!J4[?2EAJ-8-.DI M\.D4K)(U-$B6-LFE$4>5.LD42DZ5:%C4HTVI)08VIU H90-J46QJEN>]*Y>A MWIP$Q2BD12B6-E(B(G:CR:=:[Y0>]'ETI0L;!OU-*Y8C:G&41I1@3O4HJD-N M7%*Y>F@KOE%*RB*47<-2WIM1Y--J<99TFCR1UJT2QODZ11I;UVKN4P*.!$U* M*F<"CR% (\J<!$TK)E$THC8UR>5*R>$Z5WRCK1Y1$:TH6-BG8Q0*?(TX*1 W MH$4H6<.7ZT,D=*<D:4 D'O5H6-RWY&CY>G6NZAI0`G2I1+.!1 V-`HTV-=RF MCB12BC;)Y&(a)41T-.`FC*9I0&^70Z4"C:!3C+I0(UH!N&_6@4:;&G`H$4`VR2 M(@T?+KOEUI4"E!,;%$#:ADG_`#IR0"*++KI^-6A8V*#%$40-C3K+WCY464'3 M6H!MDTV-&$>5.,HCK191U$T".!1VHBC0[TX"`3 `%'D@;T%C;ES&AH<N.YIR M$T,M5!,;%L1M1%OR-.BG2B(`&LTH6-N7IL:(M]A3K*(GI0RCN:4+&A0(B*+E M`=!3M0`3I0*9`JT+&I;TT H<O2*=9.@B@4]XJ42S@E$=J5D\Z[ "8BC@32B' M(MP-YI24>0KJ1IL*,"E"Q 1IV]*4$>9I8%*C2M(!)$5T2--Z2!.]+2.U0@8W ;H*HCIK0WJ@%$1 HSI222=* "MJ%$2:%"6?_9 ` end

1 0

[logo] Abstract
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Slow boost.org!
by David Abrahams 02 Dec '04

02 Dec '04

Has anyone else noticed the website being exceedingly slow? Maybe it's time, after all, to move its hosting to osl.iu.edu. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 5

[logo] Boost/++ stripes
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

[gui] (Was GUI validation (was GUI Library Proposal for a Proposal))
by Andy Little 02 Dec '04

02 Dec '04

"Eugene Lazutkin" <eugene(a)yymap.com> wrote > Just to revive discussion about GUI allow me to offer my 2c worth. (Sorry > for big post). > > Let's split GUI into two parts: G (2D graphics) and UI (user interface). > :-) > G can be used without UI: printing, generation of metafiles (e.g., > Postscript, SVG) or pixmaps/bitmaps. UI can be used without G, if only > stock > components are used: simple dialog boxes. The idea of separating GUI into various conceptual areas seems good to me, However I would have thought that the graphics primitives part must be designed first. Graphically a window should be part of a graphical system that deals with graphical transforms, which also opens the way for non window elements to be manipulated generically... From the point of view of instantiating a graphical entity it should be possible to know where and how big it is required and in relation to what, IOW a coordinate system. > Now we want to make all these components as light-weight as possible for > performance reasons. Ideally they should be mapped 1-to-1 to facilities of > underlying platform, while preserving platform independence. I don't think > it is productive to walk original Java way and implement all widgets in > terms of graphics primitives, Drawing the various parts of a window, eg its border is fundamentally a graphics operation too. Should it not be possible to implement a gui on a simple operating system such as DOS or other simple embedded os that has no concept of high level graphics operations? There needs to be some underlying abstraction which does not rely on an operating system for its existence. > First order of business is 2D geometry. Following stuff is required: > > 1) Point. Simple 2D entity with X and Y components. In real life at least > two versions are required: integral (screen coordinates are integral) and > floating point (for precise calculations). I agree that this humble 2D entity or family is the first graphics primitive that needs some resolution. Because they are used in so many ways a general purpose xy_pair type is the option I have currently been using. ( Being the 2D equivalent of an int or a float) Operations addition, subtraction, multiplication and division by a numeric. Perhaps this whole point/size issue shows a lack of clarity regarding the overall coordinate-system. A 'point' describes a relationship between one entity IN another, suggesting a graph edge relation. A 'size' is a property OF an entity only. The observation that the difference between a 'Point' and a 'Size' could be used to discriminate functions is valid, but when used in a context ( ie by finding the best model of the system)there is less need for pivotting (overload resolution) on particular types. As another example... if screen units were one type and window units were some other type eg millimeters or whatever, then conversion between these types could be achieved automatically rather than requiring a LPtoDp function etc. However this again may not be necessary if the framework fits correctly eg using a transform matrix as a edge property of a graph of the relationship between graphical entities. > Additional consideration: point should play well with native > platform-dependent coordinate. I dont view things quite this way. This is surely a classic case where the concept (the What) should be considered before any particular implementation . My criticism of current libraries in this discussion is that they have basically started with a particular implementation and tried to abstract from that. IOW each implementation should be a 'workaround' for the ideal approach which provides the standard from which to work. > Additional consideration: region should play well with native > platform-dependent regions. Because region is relatively complex object, > which is used mostly in specific context, it may make sense to implement > it > as a wrapper around native region. I also think it would be necessary to work out the mechanics of regions first, else one gets into implementation problems again. If the goal is platform independence then as well as reuse, it would need to be possible to build the mechanics from scratch. > 5) Transformation matrix. In 2D case it can be implemented as 3x3 matrix > or > (to conserve cycles and spaces) as 2x2 matrix + offset vector (6 values > total). Usually it doesn't make any sense to use integer matrix. > Algorithms > to be implemented: addition, multiplication. It is beneficial to have > construction from offset vector, rotation angle, mapping from rectangle to > rectangle (with and without preserving aspect ratio) and so on. More > complex > algorithms are practical as well like "zoom around given point". This relates to the overall coordinate system. The overall graph of spatial relationships between windows also can benefit by using transform matrix 'edges'. This also provides a clearer framework. IOW when 'moving' or 'sizing' a graphics entity (eg window) there is a more obvious answer to the question " in relation to what?" Objects representing transforms seem to be a good way to go. > Well, what are your thoughts? Discussions of UI are recurrent event in > Boost. I saw several proposals for 2D geometry in this mail list. Authors > of > several GUI toolkits are frequent visitors here. Are we ripe already? Thanks... There is a lot more interesting stuff in your post and I like the overall tone.Would it be an idea to use the boost wiki to further the discussion? regards Andy Little

1 0

RE: [boost] Re: Logo design
by Stefan Seefeld 02 Dec '04

02 Dec '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> writes: > > > David Abrahams wrote: > > > >> http://www.luannocracy.com/logo.ppt > > > > I don't have PowerPoint. Is there a free reader availible? > > Alternately, would it be possible to rewrite this document > as a PDF or > > something? > > I tried, but it doesn't render quite the same (the vapor trails in > slides 2,3,4 and 6 are off). Anyway, here's what you get: > > http://www.luannocracy.com/logo.pdf FWIW, a wonderful free tool to draw vector graphics is inkscape (http://inkscape.org/) It can save as (scalable) vector graphic or export to raster formats. You may give it a try. Regards, Stefan

2 1

[logo] boost/c++
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- 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] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 02 Dec '04

02 Dec '04

Caleb Epstein wrote: > You can make a thread non-joinable, in which case it will > automatically clean up after itself, by deleting the heap-allocated > thread objects you create. The thread will continue to run, but it > will become "detached" and you won't face this resource issue on > thread exit. I would have never thought of that, sounds dangerous! I tried it and it seems to work though. Is that pretty safe? Specifically, I'm spawning my threads like this: boost::thread *ptr = thrds.create_thread(boost::bind (threadfunc, totalthreads, xx+1)); delete ptr; (where thrds is a thread group) My sample prog has made over 300,000 threads so far with this method, so it seems pretty stable. Tim

3 2

Suggested extension to the preprocessor library
by Ryan Saunders 02 Dec '04

02 Dec '04

Hi, I've been using the preprocessor library quite extensively in my code, and have a suggested addition to it. I use the BOOST_PP_ENUM_XXX macros for rapidly creating lists of identical template parameters. For example, instead of template <typename T0, typename T1, typename T2, typename T3> I can just use template <ENUM_PARAMS(3, typename T)> I notice that there's also a "binary" version that takes two parts and suffixes the count onto each part. The problem I'm faced with is that I'm trying to construct parameter lists to other templates, but the actual parameters are embedded typedefs in the enumerated parameters. I know that was dense -- here's an example: typedef typename meta_func< typename T0::inner_type, typename T1::inner_type, typename T2::inner_type>::type; I don't see a way to do this with any of the ENUM_XXX macros. Maybe something like ENUM_SPLIT_PARAMS(COUNT, PREF, SUFF) that would generate PREF ## n ## SUFF? Thanks, Ryan

3 2

Re: [boost] Re: Re: [multi_index] announce: serialization support
by JOAQUIN LOPEZ MU?Z 01 Dec '04

01 Dec '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Diciembre 1, 2004 10:15 pm Asunto: [boost] Re: Re: [multi_index] announce: serialization support [snip] > If you guarentee that the container itself is always serialized > before your > indices, then de-serialization of the indices would automatically > be reduced > to providing the original (tracked) pointer. In such a case, I > would think > the whole isse would never appear and that the implementation > would be very > straight forward. > I think this is not correct (but I'd like to be proven wrong, that'd mean I could simplify my code.) Consider this: struct foo { std::list<std::string> cont; std::string* pos; // pos points to an element of cont private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar&cont; // before pos, as you suggest ar&pos; } }; My thesis is that loading a foo will get it wrong --pos won't be pointing to an element of cont, but rather to some random address in stack memory. I'll check it out on my compiler tomorrow, but I was already through this when designing multi_index serialization. See my point now? Am I missing something? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] announce: serialization support
by Joaquín Mª López Muñoz 01 Dec '04

01 Dec '04

Hi, I've just uploaded an upgrade of Boost.MultiIndex that provides serialization support at: http://groups.yahoo.com/group/boost/files/multi_index_120104.zip Docs are not yet fully upgraded, but there's some material on serialization support on the advanced topics page, plus a test case. I'd be grateful if those interested in Boost.MultiIndex can give this a try, and report about problems, missing features, improvements, etc. The implementation is a little complex, so some source code reviewing would be appreciated. If no major objections are risen, I'll commit this to the CVS in a few days. Oh, and kudos to Robert for bringing in such a powerful library as Boost.Serialization! Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 7

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 01 Dec '04

01 Dec '04

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Lunes, Noviembre 29, 2004 0:28 am Asunto: [boost] Re: Logos - Last Minute Change of Heart > > "Peter Petrov" <ppetrov(a)ppetrov.com> wrote in message > news:loom.20041129T000540-994@post.gmane.org... > > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > > > > Why don't you try removing the distant parts of the circles > > > > surrounding the + > > > > signs (so that they look more like C's, rather than O's). > > > > ... I played a little with your image and removed them. > > See the result, I think it looks better: > > > > http://www.ppetrov.com/temp/png00027pp.png > > I agree that this is better. How about trying just a single "C", > about twice as > thick as the current ones? > Like the attached example? If any of this gains your heart, please feel free to upload it on the Wiki. Gotta go to bed, very late in the night here in Spain. G'nite folks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

13 32

MPL Book: Preprocessor Appendix
by Jody Hagins 01 Dec '04

01 Dec '04

FWIW, I have already preordered the book. However, I just read "Appendix A" (a.k.a Intro to Boost.Preprocessor) and if the book comes anywhere close to explaining MPL like the appendix explained PP, then I am ready to spend Christmas vacation outside on the porch reading the book (yes, I live in the south, where, for the most part, shorts and Christmas coexist quite nicely). Nice job! I had previously tried to read the PP docs, but first impressions found the initial hump just way too time consuming to even give it much effort. However, the intro is a wonderful start for anyone (though I still wish there was more). I feel like I have had a peak at the man behind the curtain, and it's not so much voodoo (though I am sure the implementation is quite formidable). Anyway, thanks for the very well written doc, and here's hoping that the book makes it to press on the new date (Dec 17, 2004).

2 1

iterator facade derived question
by Israel Fdez. Cabrera 01 Dec '04

01 Dec '04

Hi all, I had a boost::iterator_facade derived iterator implemented as follow: class ole_directory_iterator : public boost::iterator_facade< POLE::ole_directory_iterator, POLE::path, boost::forward_traversal_tag> { public://Interface enum { Ok = 0, NotOk }; bool good() { return (this->m_result == Ok); } //Constructors ole_directory_iterator() : m_storage(0) { this->m_dirlist.clear(); this->m_current = -1; this->m_result = Ok; } ole_directory_iterator(const std::string& a_filename); //Destructor ~ole_directory_iterator() { m_dirlist.clear(); } private://Implementation friend class boost::iterator_core_access; void Init(); void increment() { if ((this->m_current + 1) >= this->m_dirlist.size()) { this->m_current = -1; return; } ++this->m_current; } bool equal(const ole_directory_iterator& a_iter) const { if ((a_iter.m_current == -1) && (this->m_current == a_iter.m_current) && (a_iter.m_storage == 0)) { return true; } return ((this->m_current == a_iter.m_current) && (this->m_storage == a_iter.m_storage)); } POLE::path& dereference() const { if (this->m_current != -1) { POLE::path& _path = (POLE::path&)this->m_dirlist[this->m_current]; return _path; } return POLE::path(0, ""); } private://Data Members short m_result; std::vector<POLE::path> m_dirlist; long m_current; Storage* m_storage; };//ole_directory_iterator when I write the following code: POLE::ole_directory_iterator _it(argv[1]); POLE::ole_directory_iterator _endIt(); for (; _it != _endIt; ++_it) { POLE::path _path = *_it; } I get the following error with MSVC 7.1: c:\...\pole++.cpp(20): error C2784: 'detail::enable_if_interoperable<Derived1,Derived2,mpl::apply2<boost::detail::always_bool2,Derived1,Derived2>::type>::type boost::operator !=(const boost::iterator_facade<Derived1,V1,TC1,R1,D1> &,const boost::iterator_facade<Derived2,V2,TC2,R2,D2> &)' : could not deduce template argument for 'const boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Difference> &' from 'POLE::ole_directory_iterator' c:\Boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(837) : see declaration of 'boost::operator`!='' I'm modifying some one else library, but I get the last version from the author and added the modifications to the new sources, this code works with the last library sources but not with the new one. I check the sources more than once and there are no differences. I'll be glad if some one give me a hint. best regards and thanks in advance Israel

2 1

Logo voting procedures
by Jonathan Turkanis 01 Dec '04

01 Dec '04

Hi All, I think the logo discussions are going very well. I've made several submissions, and received some positive feedback, but personally I don't care if one my submissions, or a variation, is selected. I'd just like to get a nice big collection of ideas so that we have a good selection to choose from. I think choice of a logo should be based largely on aesthetics, and is therefore a good candidate for a community-wide vote. The 'meaning' of a logo should be obvious -- or it's not a good logo. Also, I think it should be pretty clear which 'meanings' are reasonable to associate with Boost. My guess is that a simple voting system in which each person votes for just one submission will either result in a clear winner or narrow the field enough that we can avoid the potential problems being anticipated. However, in case my optimism turns out to be unwarranted, I have prepared two additional submissions. Best Regards, Jonathan begin 666 logo10.gif M1TE&.#EA,P'&`.8``````/___Z&AH5MRM%>.VBD,SS41^81N_[FL_R(.H1D+ M>CXG\P\)2D8\T4U$]3X^/^WM[MW=WL'!PD]8QFQN@$Y?YJ6LVJ"GR59JN0X0 M&4=(3"4O5G1[E%UTNF%NEH*+J5!UXC)$=%MSM5EOK5=KHE-EE8B7O&Z&NTM7 M<R(F+TU@ATE07E2#W&!]JU&*W%6,W%>-VTEVMCUBF%.-W5B2Y%>1X52,VE>/ MW52*UE>/VU>-V%:+U%6(T$1MIU2%R5!_P%)[M5%VJEN"N6Z:UHZNVL[/T'EY M=Y"/CK6TM*>GIV-C8____P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````"'Y! $``$L` M+ `````S`<8```?_@ &"@X2%AH>(B8J+C(V.CY"1DI.4E9:7F)F:FYR=GI^@ MH:*CI*6FIZBIJJNLK:ZOL+&RL[2UMK>XN;J[IP"^O\"\PL/"P,8`J\?!Q,S- ML\J_R=#(SM76JM/4J=G7W=ZBW-C3W^3EF>';X^;K[(_HJ._M\O.#\:;V]/GF M^*3\^O_7_(%3!["@-X&A$!I<J$OA)X<,(]*"V(FBQ(NN+&[2B+$C/((?H7D< M68OC.9 D4[8RB8FERI<G18J3";-F+Y3W<-K<^5"GI&Q @PK5QE/ET*-(?1E* MRC1H49A-H]*L)[5JM*=&K5I=JK4JUJQ=HW(-V_1K2K)B"Z$M:_86A")(_XY( MZ+<VZ=BZ0]O&>HM$P!$E&AX\T("$+MZ\:@\CUHOJK02_@ 5+'MS#!XHCHQ0O MIJH9*.-1$")(2/(W\(,4@E<H,6(D\ H@-6K84($Y86?/B6_[_%R);VG!J!^H M-G+DB( D202X]E&#P(W8,HQ$`*7;)6=EO%/Q%6 D<G -JXD+.)[\N-_ *'8T MK^$#=HT@*PK#LEZ)?O9%VW^?'JQDM?'QR)4WWH!&"%9"#3<0P-X*#Y1P`PV6 M)3'?;@--=1\FOD6V'WC^_8?<@"""F)P2@@510PX*!J$!"B5HH((-[*%@! 09 M46B;A1="XEMWI@TV7''&!2A@B$22QN */R1XP_\++:K000<DK*@##;/-N)*- MU&&9HR [:B@8>*QY6-Z01)9YW!'H,:>@#BAH4$('`PP@P@@:($E##3(H400K M]DW2ITUOD>8E?QT.2*:9B!IZA& J[)!(a)#3_4.0*<<0[0P0@K:! $#33 )U\Z M.);RYT@[,B@9AZP9^F&BK)I98(,WH$A#I"B,($*EE3Z)P@,DS##K"A*"BMU, MPWY6ZF3"A2?FH:TV"Z `)#X`! W.O;>"D[?B6JD((JCP@ HUT(##933>%*IA MQ3X5VFCZ?:DL@ $Z*Z^91@H'FW,$J. BI=KBRFV3S\VF1+FB:NG)J.WLV".A MQ 5)WKP0(TI:FNOMT";_"?SVJVT'+:+ 0VP]Z)G3N9D9#-!V/$[67\/PKAKQ MRV4FT=JWZBGXPPHK6*KQSI9&:6<-,<17,,D5IAN1PI,-)QYYS,+L=(BO.@B# M@D"LV$&V/&M\::8F+B@`NL=(0W3"<!W1W61@+BWDTVPG.N)@T^;PG(K89IWU MU;N"6X,+,A+<T]A9`NY-ACVB^A^\;2?.:KT:_+!>OAI(a)C+7=.XO00=ZQS:"" MR($;/;+GYD"K@6DK%X>XXJBW.O$#'C_*`PHK8$SY[):6\*V",X2\Y]^@@VV, M/!&0^"[3J1??K,R,ZK >K3K3/CO'=3)'0]"?<H*P.R83@\3H0;IL_/>LODK" M_PU3O[>O\^A#&7UL/JQ0F_79;Q3_+A LJ@3X^!\/+=S-/:CBF^@+X*TRY1X< MT,9O+9E?3'I7C2*0R CYBZ#$CL"@QCU.!;'+6 !I-T!>T6 &FI.._ 3'F/H) MYPA-DR#^5N>Q]5AF!9/:H QUU:#,]6 %N]O2*8+W`"-X3X421-[M'@6$%:#@ M23),HN6\E9[8W*QZ.A1%$@:#0B!:\3CBFT&".K6OR251@!P3SL=NT+ZO13$4 M$2C0_5)XQ=2]30/W>DX),OC%.L9)?2M@3@W&=00$GC$3V]- %=L81#0)1TU[ MQ& ,[6C'2XW.1"!4@97^F D3WH^0*F0A(MN'`CDQ\O^3'331<W1'R4LX4 ,^ MQ&007Z4"Y\#H9BKPY"<_B;<:S@!H0BOE))(`'O.H<H7[:Q -'@4?`,[RF$L< MXH+>I\M&I+&'OU0AB>!XHAO<8(ZR.Z8VX\1$]>P-!0-K)B-XZ3XV1I-MJ\OC M>FZ@@DYJ<)NTM)TZ7W"#/.50G(5X)@3->4ZGI;-F,3JB%^$Y2_51<Y0KF L^ M"5$$[O&SGS 3H@JL:;,5&).@!-W:`T1)@R(&:Z$"@.9#(?JR:&VJ?$! 038Q MBM%+[>I SVD?,TL9/%22]'MO-)$.K%D"E0[44D\*JE"'>C5N&?6HW&+IK?)6 M+;Z%LY3;6^--BU>O/%*K!CK_:*<L_34"%7CUJRHH@5C'*E82C."L:(W3" :P M5CDAE:AP)6KE.L#$C\$`3YR+H@E3.54W&A(%.' A"NK6+Q&0X$N#02RR%ONE MT3D69Y#%&0HF2]G!@O6K9+V;/!%Y0X5N*7@K\&5?4<=*Y5'-HN_,U6%5X(,? M_ `(L 5"$&8;!!*08*R7;6=EC1A9QP;&- M#5L[N%B4+$N!79KS0]O@ZVL2] M;:/-H9I*4[NMPY9@F,^)37:S&QM.>3=SF;.!> D@7ASL``?FW0$/UNN#UKHV MMD%(J08H!R4"KH<'[KL/!(S@ON:B[HW3VNDU:T7=Z@J3``A.L(+):X,<H&C! M$(:P_S4G;$T83#@VW6W1\P; (%'>8 ;@]"-6)- ?T?KW:>E4TPVR&LN?;LRZ MU(JPC&=,XQHCF ;ZHAT-59"#&O@J3]-I"YH&>6)TS@RP%1/KU68WIP/;^,E0 MEC&.Y^N\;K&..3F@06>_DD:I%MG(!D*0<WX0U@(7]K FBK*:USQE`=K.N) * M;5$@`"WF?CFBP4RSS52P4B9;-[IK#G2-VQQ @]ZK!J^;)$R"IP0BW_EE;W0< M@F\`A!+8JM"')0&@!<UI"!,:TX$)0H)F(+![D@0)JS'QHR&6SH]-.@@EV*KS MPMB#37?ZUL?-\0SIM(('VV &<_2L1_;;Z)&NVDR+8AV,\/]5VR^&4<^XQO6G M-]@!G"W86E"4B ,A>&RW"<E[0H2I<W906Q<_SW:BCG:TIRU (]I P2_0\@.$ M'9$D-/K8WR83D%C3G?YDJC\EH@&*;K"#LYK[W-!5M[1U/4.<)0C!B,Y3$D1\ MLNZH^ISY!E%Q^-UO?T.6LEXMZPAV9=5)\V"M!_=SPA7>:7:GS]JQ(< -^XB1 M(K#&V&[\]H" 9+:.*R&RE0VK6,^:JZ%:[G)(:DX.=G#,9]N:Y6IV.?IVY;$8 MR"C(%T&UHZFZ-HWWG#4>__ADA6Y;HA\]J);3L;Y@<X,?--UV]X*ZH*7.P15 M4#7T9@B=?8AS>L7+Z_SN3]A!3G;_LY_=J$5E),=68"(S%QK=3Y?[D^G.9+L' MP-1'*XZQN[[SC7=<-48$N<C;>O:K)9ZEN*IO"8" S,/&7?)19_@&,6!YCQ3! M847ZNU\\;P0*")[P82T[!NXHUY1G#?%#I=Q1AXHI)Q6T1:^'/90I3U]4>D0" M6S?.OGM/`0J E:PCP,#PB9IV;1G?7]R"JUIM6P*O#C:N2V;K6=D/ULF>'^'1 ME[Z-J4^YVDL$`GVQ>QS0?1[@51Y0`F:%5FUE>D?'2,N7?&QU6V+E?C(a)S.HCE M&A+H?I0569)%>+#C?/%$3?H79?QG-QI `1@!`2:0@&<U?$!E.??'0:6'1/(W M`K=%@9GR_UN^U8$AAX"8LB*$5U:S!00_P ,[<(3.\2 T4'!O)RV1-X(15H(\ M@P'6EX(GX(*@A'Q"I58VV'[M!%F^52<\6'@+&%=&1 !R<R=W`EX(\G 0A@,D M\':-XX902&-2R#/^=Q%%T%8\\X!PE2UHE8&Z!89 9UD(F(#$%U<O*%398D0S M`&'O]F0[$(<%Y2U)4H?[)WL;E(<780+B!X.5,G^VQ7X3^%6PPX%B9X@^>%;P M!X&@6(,V2(H(:"E&1(=KQ@.65HD/<(F8:(>:&$!5V!$0\ $MT'ZD:%NU)8%B M-5N"&'P)"'^W(GXCT /*6'^3%6LB4(#@]',5&(;"\22UV&D\$/]+NLB+O2AE MO^@\5&@$)$$CK;%>Z_5KSW%+W85HMY)4L5B*&CAV:W4"Q<$!W-=]`JD$W?=S M&) $%Y"0"KF0"FD!%+ "5V-$4\-IX]AT^N(#MGB."G:'.\.)'8$F+C!C[P8C M0& K(N 7'#" `KF2`LDK(R `$F !,CF3-#F3'Q [`E"3.CF3#VDY[L9I-U"1 MNHB1&HF.5)9$*X""*8$F.!"),_8>:]4"%["3.QDY/? !5*F3'Z !,L !65F3 M/5EM*)"14$9&Y$A+%TF61<F1&A.,([$HCE)C[T$"&. !4_F5,GD!;D("7HF7 M,OD!#=*7?AF6X2AH9AF#=D-7#T"41>G_:>E(.^NH$HN"`VJ98#6 @!QSEWBI MEP@HF'BYE9+DES))`1K@DR@PD8$6E)U4B1K `Y5YCFS9+V[I$4SYFFC(9QR3 M!*+)F21 `:)I`:#IFZ))FK2(`DZY9F2TFFCY`*[9F(YYE#)T@I+Y`)1I8[BI M`KKIE[PIG'X9G+])G"(@D4#Y.A;9FK:)B;&I+;/YD0\0ES2651A3`CFIG7O) MG9_Y+?;YE<0IEN<I8ZIID<S9GU"8GI42F4O9GN=YG?.YF?6YDYIIDRZB!#3Y MH& Y7^%YFN.IG(JG+^[IG E&H)6RGA@QF;;))I.B`B:PFWLIH:*YE>#TG?,E MEL>I9LE9GLT9_V4Z$ ,9D $;$ (^^J,_V@,X$'O0N4'2>: W.F,6@S$H@)4. M.J$N4@(LVIW?,J5X"9Z%F9KDR9H=*HD]D $`L*-B.J89( ,^0*1U)*(7L2A) M*F,6,RE-NIO?,D>_"9B;0Z%4N9_B:9A;2DMMTJ8V9@,A`*;9$ )G2H*/.3L& M2A(A!:@0]J:7XZ0,&E9*@*<["9HK8*DZ20$/("<XHP,9VG1MTJ4VM@,;<!H9 MD (;H*HIP*HI( ,\@*9?I*82T:BVN:27XYE9J9<LDJDM^BT:H*E@^0"3@C,S M&F6JR8>-U";5"64Z<#,D%@*D9@,N\&O5.JVRFD2T&A%(L)@O0&-!"?]#N:JB M816L+>HBYJJ3%,JIQ;H"H,JG&KJL&D"J-,8#,G $VQ,"#Z<#[_:N@0:BM_(` M,]41W<J8_HE?<*JK5'D!WX(IEDJA=IJN5TJLU>:NG)8#?6I'EC.J`DH`/[ ! M2& $&] #+ >B`X !`JL2!?N:X9JPY$HGPDJ3H*D!V3FQMO*I&:JL=70Y\RJ@ M]OH`$: !&Q"K"@>P`Y"R*5&PWSIC+4M7^;FP*T(G-?N5$3NU6<FN%7NL9?DZ M.NMLL#.D4-8#*3 >K[H#)9NH=M-D`XL1*PNN".NT+TNSYZHO"ZJ?%(NS\-JU M2<2S8&MC'ZL$09L"/="QF5BD57:T:YMUN\C_LF_[HC.IJ0RK`G12MX];DQ&; MHH-YMQ9KF):AMS,$.V;[GCP0`QM LP)0IOZJ;M0W`C+@56:E+528N!+1K>88 M860DKIL3MY1+E7;Z`+N[D^P:GIN;FIU;4*-*8S@0`S+0JN/!HS^0NNN6J"JP M`0S `*DJN=N"N"J[N. :*2<JL;L:M1J N?>I+Y)JM^VJM4^6K,:[`EJK`S*P M`:5K=R';JC'0MT6KB5T5`BE0O0J@`-6;`2% B6J[O;4K8=Y+5^ +M2JE`>>; ME1'[P'FJN="+K,7KIRL0N@NF`X.:`HW6':H:`P\&=81&`BH0`M3+`/^[PO^[ MHR$`)P$KN]RZBT\X_VD)K"\QFY>2\@`2?*G?PL/#2<'C"4.(R3-(5\$$P,$\ M:H$]^@/2QS</X*,IK,(LS,(,```A4*""M+WYMV!MA[L/D,,6P+"U`L14JB\* M"[S$*KQ(O+X(6\0[<\01E@,AH `)P*,R\ ,.)G<_( ,R@,(9X+__FP!5O,+6 MFP&K&<,J(0%.V+T:\+U6.\8UJ9<PI %IK)4_?,G#FKXYV[Y:RP,;D `&H !- MV6!0EZ,;$,B"7,A6?,@,H (N6, IP<A=K&!M]\B*&<GJ6B<B8,ES^P":3)-8 MB[=:2L08C,0]L $%4 !#.\(LYP.IS,I57+VN' (R8'[:FQ)%T,A,F\ M\O^[ MD\PZ`^#+5&H[P<R30LRGQJQXL%/!." #"F `"0"KDF<#7\H`A#S-`;RC#-"C MP5=8(X"T)+'-M6R953,IM(a)/.4)HSP*RNF-PBPBFL$L !:TS,R,FU<*PUUB9A M&Q#/"A #&@QUI$O-`4S-J:JJ,C!T6(C-`CT2C QM$68^WZO0C\O+#_"TE^HF M)ZBN"3D>'W"3FJN^-M:RLW2A$0;*R[P!.N#,+,<#/>#'?KRJEI4!HP/+)MF' M`2W##+'-, UA,AU&-*W#*R "#9V7%X <)O#3*>E[#0(>:NU[/V>!:-.N;3S4 M;TQ+./.("J8#R;S,(<#4+%=>U4H#+9)4'GPM3);_U2K!U37L'#V R[:#N0F9 M'&JMDB0"D:/C>SG(6*,3.Z;26!_7@Z];L75=8RV;T?U2L9 8`@E0`/-\7D<8 MV[(]V[1=VT?(`^V5VSY@0)%C6QD`&"'@N?Z2S23QTHW]U?($&'*-+&)8`N'Y M6V,H<G<T`&/UNHDH5Z0]Q)?F@'N:8*::``FP`2@`U>1=WN9]WN<-I#_:JO*; MRB22`F>)U2UM>RLG8\C=V:$W6$/'A_B(<JV(=O_-@-DBO$)MV@A;U#^I8#Z MSP!,Q=+\X!#^X. ]X7?\`-2;`I0HWUJ]$%RMU_8=)9.2+0'^)#!H5+BB(a)*.H MC%YHBKMUBA4H'*7MMNO<_TAGJ& V( /XO,P&L.,\WN,^[N/+'.1"/N1$;@`% M8.0%P,_@O0'"+2>*/<OU'=./;5:C2%8K/EB5Y>+=Z%N,U>6)-1CX72<?&.-, M>]?</98)=@-BV]J$3.%N_N9N7L=RK@!SSMH^F@`_BN?R*^>KR@!'WL_"K<C: M_ "U!JY!`.9AF.B/A8I9;ED]2%M#&%M$"(_K=5XXP /H90-+J]VH;7Y[6@.' ME0))'0+?T@-/?>HR@.JJGNJLCNJLGNH_T%X_``+M-8ZQPWXD4,=&S@#!73E/ M/M ;Q;(^,%NN]5ZN983FA5[GI0.9;@/\*EX@=$O>Q2G:16$8%G,41KAN#$,( MCO\"CTA&&A "#"#/(5 !D[5T.;#4ZI[N[+[N2RU>\$Y/O_8"T [OXH5C*R!^ M)SL`)-#1\KP!V O0\]T1C&W:VC5I$^9@<C-A'GIKX4H"G>XOM=ACWJ+K"B # M%3 !&N ##K;4[?[Q'D_F48A!&3,GK#W*&Y#A7#7P&!&T!]+P,)_F9JZQM9@@ M../O"C !&:\I6)7$[M[N"";RD(CO[U0"XVX`_;PSOSX2$4#HC1WSF'C:>#V6 M-X ##.+G!1 ".J_Q+S^"1*\Q*!#/!?#*`K_A!N'R3P_U4/CP$;\M1H0@.[ " M_4ON%5 !AU7H7D_R.W/R"?"JYK?T'M'TFJ;V#<_VH/3_]@J"`BD0SX0\`1K/ MS?KW]1HS`J&,\BHORR31]'A/^(UI^(J'^)>9`:)<``"<&D)_:Y*O,?W^YTQ^ MXBQ_$4W?]9Q?E$$9.6T?)Q>J=#W@Y^ MS];;2G68^AJC`F+/Z]L"^!V!]K/? M^?@%\8</+@B&XZ.<`<4_LL&O]SPS`KI>`/"-^\A/"!" `!% <>P0^VF__'+G M^>HX`0W0_@OP_@O0_G4/`KK.ZP_@Y_+\JO@K><(/" ."@P,D(0D&"1LE`R(C M#T<!D@$0" @'!PZ:FIF8EI.@H:*CI*6FIZB@$!HE- 2OL+&RL[2UMK>XN;JP M-SP:)"*$PL(3#0T+R ;*R\L+_PT*"04;,"\Q&X@%#"$QN]VQ-"HK'</#)-<& M"AO ))"4EID+S/+*"PZ>$*GY^OO\JRJNW@(*'$B0%X\5),:1&X2A6+QYR@I( M7)9 @<0$$T"\^"'#8H%T/7 4O 5.W$)"&,Q)U%;HP8=+#N1)+!!M9@%Y]A#@ MX\>S9T\-_T8*'4JTUZ^3`QHVD$E3@5,%#!@XC2:5YDT'%5BPD+'A9@(&,GX0 ME552(5)!'0UD0V%N*;.F4*/*E>KQ)KT#.GWJW4L*@I*@8P,+SM5K10FSPC"X M7?:1008`&2)G2/$@Q>/($BTN<Z#QQ[EL(7Z(#%SV+*%#B1@D>*BL8F3*&I08 M42);2?_E#%(1,3NPDZ_OO4 !#AY._)71A.0FL$X-^8%L`4BB2YB>Y(@2!BL5 M,%M0P0:.$-H_IN@AN+1I0>800;4+=;(2`=.+1"@BG[X$)$F,:,"MG9X#!+\% MR),_PA5GX%B%`2.,",=0Q !D[R$A@7WT40B!$18E,%D&NBGC@%8]=)5:"*,- M9=YYA:"6FV-*'(%$A1% $",E$T8P7Q$2"*!$"E)MEI> 0*(2W(%$%N6+@H0T MJ)8"$"91GP07F,#!!R:<8 (%'Q"A1#0)'"' "KC99<"'+LB VD<;<&-B.(B9 M-D$"-3D&28T03->;C!-*`H&,\R&A1)AW]1;DH*HH@4*!12;_&M -.QAFEF(. M`@!)?5&>,$ +*I @B @K_--5`2A(4*<1/';XH0TQ'%+ `B#Y(-2)9S44ST>) M9& $/GL&$($$H42 1 2JS#<?J:K=1>BQH !5@Z+,!I3##JPH!&EKD2DAP:X? MM!",()B6L"U0,6"70 E#6! C$@]PN!D+-NC E5?:Q*!#0;">Q"!%&6B7@ :B M3N(KL/[^*LJ$,@J0;H<`(DNH7RHLV^S#A!UT6".+)0#9$39>$$'(Q R@@<< M"P)46(a)KTD$,.0UQ;A!(`=%C!"P38X!DV#&S0`P\$U;N0<JTQ0-E-"ABA2I[^ M)B$H!/118J,$!].3L,)!&NHPQ%33_$HM /PG @`*6!<A E"B$""!QZ7X(&F M`P#UZ38ZG&PE?2SKQMTK-O@`7L\A[#"0SL-@\-!7&20AP0I "ZTGCJ 4D40H M=?:V]'YR/PUU@'_-4/7ELS3JK=_4=CV?"0J-34+'Z%% >J<9J$7B*T((,001 M\_TI]PLP$# ##UQADXZ:WO"-TF*."1!["!)M@$3 O2FN"HY'UPFY,KQ-+J#4 MF%=/MZ/ V_KYM@-\''+I:&L0`@/HA$" #CZTX ,.Y>[Z`'8>PDQWJIJE(T- MO(a)^BM6-&S/?!`QA2RP-XI2LD).]X_NK7\B"0!!XM0W+2VXL14# UZU5-!X;1 M&I.40)\/#/_C8Z,3! A%M@'ME"P'/&B!$/1F@W(QT('*`$$L;( [XB5B`Z'I M1OZ2\C<`\"L")F '$HZ@GA4`JTY%P-5T)H%$42!-/D?(EX<@&,&>3-!R%KP< M!DO@E@)P+0E /!OI!B$Z$8*L8P]8FVA:IX-YQ2P'HB*5;CXT0U1])EXEF@4. M?A"#&/P`!1J000D8D9QE3,9HH!/BA8!&@3TQKX $U)4"]22L&$E `P"PRP&J MR)<K9E&+*YA 1)AT!!R-XXS"0*7W-/6^1(3 !JW36RQ01I\5D,\`"P"!#63Q M`AO<#1T,Z(&K7K$#'_0Q!EQ)@3*7F8(-C#%)K0% _R0@`K$]X'C_$2"<`1@0 M"0@8L(!%D(2P0D$?@,DH"8#Z#R?U,L$*?I)9,+#!"MQBL0%^S8QG(T091V V M33FP9#XXP3!A@3XA""^*NJE +7;PKA'AS 8RL$QD`- <#<1F1REXIB!XEHT4 MO.@#FA*B)"2P`=4=[UK@E,0C#R<?)L:N9;C<Y#JM& (LOO-A.@C!,OA7A M8 MBHSYQ*<@^CF"%"#"9K&,A0^$H,(AX$@#M\QE+7"0*MUMP$R1P6$(0B#1UTQT M`SA4`2&[*,U=G0!D);CF))* B'WA*)S_HA' *$$?0=%5``"XI0/L.M-4&&$% M-[@IQ%A S\F\R 3<0P\J"Y%/T<D`.P4(_T$05@@+'C!5A3S8@06*$$6[*-06 M] -:5OOH`Q_P4084Y1H*P,I,9980&@\2G@FZ-S8-"* W1$R$$EZ$- /628$W MXNN>F ;3!5"QKZ>8X"X%VRP>Z!0=/MQ5F_!)NK&-`(0H(%\"4$!9`NS@LD+ M&0%R`#LDI* _#E@N+6IP`S-])2HA\,$,;#!?'VP`,EP;70E4L%6P@E4ND(D- M"E 0`A4`LI3FY #0E&"T(AP/1T<L9U]L9 0`]$>FR,V'H0++7&:Q``4-R$8& M,'8!$H10&*L<P=@X=K82HL,#KBHF4X4PT/&6:V7P6X#\:I$#`EC#PF@*2=U" M0%&N9F #A!#!./]&,(&52&H%E7&M961S!,'M"@4K44*?D!;AEC).1A!N( ,6 M@)<,ZT.Y'89GIV1@V")P`*UH0[$82<"!L:G@'!L0@@Z^VP+US2('-=BL$7(L M0US8-U] NZK=*)H"'J @,G$>Q @:I*$C0, $^PW!!BRSS <XQSKA28'@?I7$ M)S8/1]&1D/L`\ $S[^.OZDTSD3#(WPQ<LP@M(('9./#F2!?BS2H&V0K65LP^ M"^$6L$,G(N:&BQ@`( 0-[6@*(!,#<%@&!1A L5M\)JH3B"#;UC2@KW24+G4I M8$[7:B(3[X.?="NM" \`0"1<G0]8RSI1M+ZO!NBS9.^!#&0F;L0J/?#_`0UD MB+LG4)\;9:$#'OC !#@RJC*Z<PO<`4 &. @1G!X#&1G8`!P;R$ (/C@KQR1! M`!Q0@5A+@((4".]&G+5-"E:B`2>-$\SL)IB@;,0R)="[WBNX-[X[-6TM7Z % M'C/QO_]MXA63RH0E`((/VHB^'[2NST'P0 N"T((7/0"]N' N`,@S@U0]B**3 M8:UD_,MVISC&UJZM63IJMM4!#UC3+L[&I.QSGQK-2!04SL *^/IS41QA!;$6 M.G%H;1DC]'2ZZ!F;V3PP>0I8IGA]!@(0MI[K('#]\YH_P80,?I6PAR #:MH( MQR$##=B&R2I<@E/LX321F]A>+3:YB#*8Y/+X_\B'\*"P410U,-?"D^+P+E#\ M@1BO/<2:1M<@HP`FP_,`KO?Y^JVC\0[:1O7-?GWBR;>%Q66@-^>N'K)+0G3N M:Y+[]B? &,9XO^RG\A6*5EGG>\K5*&1D!%L7W_B&IP&)IWR"P7S],UL><UTJ M9F*#5'GQ%@T*L (M``0_L /;URXQLW V-B%?=Q4#* L]('+K<WJ0\1ITMP$/ MHE7]]5]0P36R06 K$ ($E@)&( !'< 2S(7,3E5J0$!U)D&KQ82/Y1PE[$@$L M0WP`6 I_I8$$*!@X0'3-=UVZ-GG1YP$4@%:3]R>.D0):=WU P -,R OE<DE@ M=PLSX /*A$R/,1XX@/\#/, #.$ #CY8!HX,!=M@]G*,A#V CD:8"-"@`LZ$! MRN0<LF$$E3$G=?5$$H(?2="(TE%.?[*'27A\B->$BP>%_9,$%* "_]: )G9= MM+5T._(`$DAC0F!]QB9>8D@?I&<`%&>&;*9,D!$2=&,#'V<92"9"DE9R'I4$ MJP56DN%IL5%E]5$?-@@?\C$=<Y5_?((C?6>$&>!SDS@*1Z !X6>)!4AT`&!T MN<8QHW-BBG4V*^8!*$ !W-4Z/E!,FN=YQD9CK^!4$G!>'O*!YV-:/^ 9:%=3 MLX!:*= (DI9I%:$`C^%IF_8`&K "2J !1O B-B).,6(C[59.\U$C^Y=_/+?_ MC=-(C0*(C8.1;QFP;Q(`>>$HCJ+S;RB@/NC8-C)V69\G!"?@*^KBBO1H-UH5 M94<F%J_P`SUP>K9F)BO83#PB%9&Q`K,Q8""C`C47++]G'R]2'_@PD5XV"NXS M8AD9@++$D6/QA+5V34!$#M<%<!W3`F=#>91WDCY@64G58P2 `TMUBBU@`A& M4+CT6;3P`Y9A40@IB " 0V82<HP&E,P$5EN5&2,&`4>7:R*05@BD-#,B+/'! M*W6E-/$A7$4(a)`,JT.%4)"@*P`7F$E4*!02A0`I.!,: C#.-87?DTEBS'5#P` M`S,&A@R'/A/2?S<A5;10-YMF4;K95:GU&JXE@S(P_T:3%@\6PT$2\%,=H)CB ME#0T@B?R<3RF-(a)G.F$3!TG\/$$Z9.0D"H %7Z9F?V2E%I3T^!50<4 (CL"W[ M)(XJH 0IM$(OT)93-POP^#ZUR0*V0%4RT /ZF9_Z&0,]( ,`V@,_, ,&)I(< MY1B')0C)>4U(a)-E?S$0`.=BX1]G_.."-@MA]*`'R3F 0:T)G>21"@V0'W=9U% M8"G^!HXC- !G]#$H\%WNV' I*0NP<P06-H^VT$9N"(<Y:HO%5%HX, /@@ (B M.0`/P22.=P'CD)@/X"34N9SX<!][\B++^7](HXSG\A@"D)V@P*$[P&$?6A#R MI (=,(<D1I;@* BJM*+DN/]]*J0W>_::L.!4*Y-)$Q<0ZF6+ZA6D0TI/DC(A MLZ6D8"0HS FE`6 G*M6DP;<K]&&=D:2E2? `.."E7TH0*R"DYN!#./(!*E8. MW[-B0Z4$>L-4.-E&;2E>L&.9455H1*&G"R$"!SIB$6 !'= !2&DTP>=EANHK M.Q&=HI",TV9I6KI6D"JIDRH0`S8./"D`16 !2&>:9[,M)6 Z:*H"KH(#?::* MZ'.M<AHW$V=3:R*D2,&G7&D"(X"4C?I$DR"EE" PA_-_AU-A*="HCCJLQ4H0 M,'"LB3EM`P1$B.$]V_(Q'# (T8J3Z7-L!&59)W !<8D9$Z>6JUJ@]B)*RO @ MCB?_`>5YG;?:&TZB)]'A.%'ID)8I31HZC8_:I?5*$,>:%"I 48Y7HI(V-AX# M,INR7T#P"CK 5-TY`T,`E\0U1_9)&A![$IRS-2X7`1>05MA)5\NXL2K%KH>Z MC+N"29(8K,(:J2<K$#:0LH5P7QD@/,>)IM]3.H14""K0`C9;L#(J'RQS2S)9 M'D&[$ VQ4WT:`1P:2?-Q)V!4-$E[J)1DA%RSF%0;`.C"`\1ZM82AM86@KP;D M4RDZ"#)+1F6[7'RFBD0@'_V7`79Q*FX+KD@Q+=D``"L`1=A9)\475VLU2>_& M)U%D*X$+"DQ#N(;K#??*N6CQ&!I@0!*0+7)&-O_8`@OG_P.3-5Z5&Y?3)C>Z M-!BL>A;*X0PD:"UWJRN("J%.6Z@H=:L45G0C6Y67!+NQNPM92[N"\&@^1&I5 MHD\E$&G\Y &QT' M\#KS<033M@$3X #<08\CD;S*.P&"T+R_@B=V=1_%YTT! M#&;PNXU[V[JO6[C=:PN(NRDD^ #*:K0GT '!@"F^!C*SM+._(@']QS4#Z@+' M.QS@(*8H(FE^N7?12[UVQ:Y%Z"M_LHWN&K@)O,"Z< ,H8!(+0H*VHC)1T@%O MYH^#T (EL ,G\SKEA 28Y,'S=2 C/*0G,0(Z['@V$B,[H:ZNFT13S%G3%HTQ M+,,/X ,*3,.ST,"$X(<4!<'RL?\K25 E$ZQD`W "'/ Z%G MNU+ (O<#UV@@ M35S"'J/#`/0K4^PKZ6:1$EF9^\$U&-.ZH\ T8 PQ-_#(D!S)DCS)E'P#[#7) M-9#)F0S)+]#),S!?+N "QSJKI#RKWU8"))@"*^ B68PC<SP=?N?"EL$U,N # MFGS+N)S+NKS+N-S$I?S+P/S+*N <TZ9,[Y%N5,R,#YD?>KG#V1NLC$P#MUS) M86RS;=B&5->&%KC-.]"&;_C-X/R&I37.Y'R/YGS.QY3.?:2?/1 $,:!Y%)A] M)S $KW/##7C/#:AR1M8<+?*($SDA2 "(MG$95^7.GG?0")W0"KW0#'W00#!@ M^!S1$MW_@"@P0$A *I"1`@=9@XW8B#88B.G"-2L@/(I<"DQC=R@=@RH=`BJ] M`B[]TC"]`@<ITS ]TS,=TSB=TRY-&SQ-&Q1@!!R @T+M)0)0U$7]@Q(BD;FR M$T=@D!I@D%#]U+H)U3LX&:18&S1=&;U)&9[6U5[]U6 =UF(]UF1=UEU-0!)0 MC;.<T<S$<5:]D,_<NA%@!'1=UX5X@WB=UW@M`"?7UWS-UXZXB'TG(;$<R,G, MC$,8UWK!)X;=V($,B$\M4:FUU:18@[!\V9B=V9J]V9S=V9ZMV3M7'0EYB)T6 M&S78Q26=VE4)9@&=D#(M&[REVOG0C($LV[9]V[B=V[J]V[S="MN^_=O '=QZ $$0(a)`.P`` ` end begin 666 logo9.gif M1TE&.#EA# &*`.8``````/___U=-Y0$``?KY^P(!!@D&'A402D4T[3TOU3,G ML4LY_BD@CA\8:P4$$.CF^PX+,D8^N4U%S%M1YF%7YVA?Z'%HZ7IRZU50FH1] M[).,[J*=\;2O\\._]M_=^N_N_9./V=/1^//S_??W_OS\_P,#`<G)G.CHM?[^ MQ_W]U0H*"?__Z X.#61D75)23:*BF8R,A"8F)!04$___]$%!/G=W<C,S,1P< M&]+2T</#PK,``'4``$,``"0```\```<```,``/[^_OW]_?3T].SL[.#@X+&Q ML08&!@0$! ,#`P$!`?___P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````"'Y! $``$L` M+ `````,`8H```?_@ &"@X2%AH>(B8J+C(V.CY"1DI.4E9:7F)F:FYR=GI^@ MH:*CI*6FIX@<%1RHK:ZOL+&)&P("&;*XN;J[E[2U&KS!PL/!OK6LQ,G*RZ$D MQK4AS-+3U)$?&K79% _5W=[?'A?9V18DW^?HR1T4X]D:0>GQ\K$BV.W9&_/Z M^Z0A%O?CHO$;2# 3"7$`:TWP4+"APT@'$]:R,.*AQ8N(2&20: NCQX\1)>;[ M2/+A"(0).\ KR7+@B'\))PAL27/>2XG;:NJ,)P(FP OF=@KU)J*"1 U!=P4A MP;3IT*>#/K!+.+)5$!$>0G3@L$&#A@P7PHJ]D"&#A@T<.H1XD!3JQP<3_R1V M,#7"PU8-%RK$Y<B1@@4-'$*(<(O1`\<0*S]]",$A@X6]?",#K* A1%O"`T-( M7.A)1(@-&:9*'LWW@F7,!#4GK# X4Y ''33H)4U[M(8/J/EUD'@A,242'AJ+ MICVA>&V^%1CFGL?A:*41GR] /I[\05:M'/ ./TYAYG)TS:E>;D2 PV.)%C:@ MY%U14&(2L#-,IVT!]ZXA1' 8,5*C!0T:+OQW@PP$RM"";X\00 010S@4A#T` M(0-)$,^T,T$&'8@0A ?;W7-+(O!XH,%\MLFBH!'^#7@$```,,$ !/_S@PXPT MOM@"`9#@4(,-,K!@@Q$.;932)$;=4\$&'B05A/]/"0'3B#_'">"=*46\T */ M+!; H@\]\+##ESJ$*6:8/+18PR-&W, B`#X`P *0ARC8X#<A`32E(]M=P,$' M3!$2Q'H`5<6("$+2EL%XHN2@9HLR=@GFF&/NP ,/7;8)@ Q#('A(#BJPZ:4. M._S P@LX#E*$"SS&`,,W1264DR1"4E 9HH(4FI"$C8Q@JV2<G5*#IY]"^N4. M8N[0`Q! `) LBP82H0@1+\!@`P`_$%LLBS:XT (,1MA0@!(_N @#K<D8YJI] MD8B@%KJ)['K/7)!\`&ADN(Y"0@L`]&"LC)/R,*.^H/+PPYI(J' #MT80H2DA M.<0PP)H^A+F##SSHT,/_F@^O6?'$`*Q*#0F[)52.* _RI5(D(9#(D9.ED `# MM<1*RF*7$E\,Q `VU `##D4XZX@+2@S );4;`U%MF0#$0(,,+ )A[0XMPI!# M$=*4G-"'HD"8T)V-:!T94*<000.;UH):\YH_DK#P(IP.4#&H,8;)HLP`O$!" M$6-'+.;%+ZI PPL*)R/54>1JXO4]RD7"(6D5L#M*$#C$8+27DO8P\)H`T% ) MO@"4?3'%+$[*HA%"!/%K#V-># "E+(Z;3'A-DG+X.!-P,XF[.-E^"@Y7KDAM MIRQJ.\ 1.$Q"PM@_%&OIS,>R2 ,,+<30^9@#ZUUF##Z'LAA77FG007N)],21 M_Z"?4-B7[I&$+-FKJ) P! XOO&!$$2\K80.G`)PI"0DOP,PZYLK"G(O6-":D M`<%+/$A6#D#Q@0YDH$CMN$!K#A$$V-V*%!5J1^,H`9?1;! 501""$)HB! (, M86Q*,,+8L&>\%F0,@# $X \HYZ]E-8U%.5A;)3RP`0A>$!&+XPB\1)'!<5A@ M@A!A$D>."$(1.O&)..B4"UX&`"/H4!$NDU[FHD6#10%0!3O"7+)4``,KM>!* M-<A>)D2DLGN0;Q :B0R&/" "`JBM$R2PX#TH0@FK?>V*G7BB($5(`!<,0 4O M8 $`7& ):.7 CB0@0!1A2 ,A# $&-. 1$F*0@SX)HO]PDOC !MH8*$04,285 ML !9S+(!M*2E`QX`Y"PX`C9*G/(>+"/%('=I!#.YP$U4VP0.D@" `RB@`2UJ M@0@C.80BX( (3_1$!WPHF7H)0H]1<B,EL#F.6DZ"FQ$"I29VN<LA3,L&5'2= M)G# H@8L0 $/:P$)!!F$$#I1EH^H1Y02-PCU95-DV^0(UB;AS\.4@ISD[%_^ MU,1"31!!>NY,@):4B5 G:N(!\Y(,:PH!SG\*H (90,PW!6J)@J[&<9^HZ" 5 MI*;_`* `-WB!)D@`T04DX&$P4*D(,;$A:I)&4,[PZ#@H< ' A `W^#Q$1P60 M2TF8%"!-+9].!4F 7QV!:<[_HY40`I ?'.0@?F -*UA5H(2(NN@%4TTJ(C8D M&@J810/GX8M(`S""V9&&J$;EDR:6N@&U&N*I[WK<5 =)10`8X ``()XE]1._ M&K@@!C:X@0I8H(("6/:RF-42BQ2P``088 !VTZE?#?$`"&K =DNQBVP2XDWH M= `T/I4(93K ED_PU1)+K<4%P >*P0H2!BN"``,0L( &."!;DGVIE@9@``@T MH $*4 `#&-" `TSWNL\]``0(a)D(#.0J!N\]3I<U"B`=Y^\BJQH>80X<@4SW!% MB=DXTE&7,MI'+-6:D,BM`-:;4GKJU&7,)>X"!IR !$B7`0=60($-'%W.#OC! M$!XP_P($C `(@':P?30&^Q+1P-#80IP!`&P'[CB*^UK"KMG8;7T?84\1^J:B M),@!"PS0W0A/6+K5W:X!'% `!U@WPC8ML( C;.$:#+:^05#-+R#Q``[P4Q'< M[!4IELK?2. N("M^1#0-`>-I,0#""#@`CU_47 @<H $(;G".MPL!![BYN9Q- M``0XBTP:A%>E]3W).*J\"!!?$R!\+ 65*S$XD639$2U>6(MWV0(E0&#(R"PF M@K&K73?'$( #.(!-B[F `\!T"&F5A 4WW(DB#K3$!C6>D@&2`?-V(M$@(J?+ M6%3C!7S7L 8P`&8OS6L(=!:ZQ743#C <+Q]N%!2SBVHHEO_ZY$<$563HP\00 MC+# 06PY$>0T)P`>_>!(PU &,8B!MF! ;B-X-0?HCI;T? UA!K (K5.-A!XM M4*I/X.Z-R]Y,LQWQ@=A^=-^2* +5A&!(&4SM!>(N0ND6L6@G]A(`#AYP`UYX M(a)RGF8$%#\.0A2$ $IA5@TL\U`(M\Y()A5Q02-^FFGR41!-SA%Q0=);5]707P M'-5 !C90.%95((,C% "TYKAXK 59A'4;N,;N;IW/ZMF((!26UR,W^2Z+L)\< M;'41J];MRB-!@(SR&>:R16FNX/O1N5:"!+]BD=)\!T ;O* &1[A!#>;$Y2>2 MX)<&4,!W#4!<!:PIAY$H@A>A#@#_)1B9Z,/.P9I@X,PIJG$0A_-F)\1W#ZZ! M761(1#0W+5#S2.! D2P:(.%=0*L6\^^EU=72Q]_Y]T@((>V63B:Y9\\Y%PC2 MG(B$`3%;)(-.#> &<!I$J]H1:$_T^QX4Z'PG.LI$Q9$H`]&>A#-+."W"`Q & M^=%4BP7/7%T[@$5?3L#WJWAU1W3\I7IW'A%&L!2F#(&AH'9BVE]T:254>Q!9 MK\6Q/='!=E! [)<':*ZV"'K6#N6%"8J2!/Z!!-8G0#<P(,53=P27! 6@:P:@ M!.#762*7/Y$``UKB3K=V`S%0<=#S'S& !$GP`D5@=44`/%"G`O<G"$4D<YI@ M+L17;U/&_QZ14"$3T%>8,&LO\D(-B#%*X (XZ![\@X$]9EQKHFD)('(#T (L MA(a)-JPFT;B#$#!%.*9 />@DE#^",PT" MMS6@D'\"< &HT%&2QPAZ1 %?-PD/ M-8101P-'* A&( ,#X `#T "WQB)\AP#CISF.P'T%X&#>%D,U4 .[)X<`1 -$ M<'P1`@I/I6SY=C5JU0'3<0'*%PE!0 -"R(AHDP/[P3 LP%S.A5B9,RT%T%T6 M!@`V4(>'(#88^&4#EG0`4'$O\$O!PQ^*"(J8`P-FN&2V!56G8#Y7\P@%I0&9 M9PD-4@.?Z(N8<P.!,P32XP`&%FDR@ ,T,(O%I24W$$R*0' LXO]KTV5K&0,# M2Z%0:W(#8P.-+-("@'6&`X@)W(1OH7!+IX8((O ,$\ !AV8(.& #-,!VO$8@ M<BB%0_!+`\!925<`,O5+!>!.2?>-C !["0"("*9920,#8>2.WY9#MR0`FS@) M&=2/Q7A+2#$"'["2+/D!#V ='; >%6!YE%!(#7@P)Z"+UD=&`0`##_-E?E=X M4A@`::=ID4:1BM V`_!E!Z $"8"*`@2*)<"%EW8$^P$"'/%RES [;_@)*#8! M%F !%3"69%D!%& <XZ",@?0"6,5K+& "*? "1U "[$AX-A `=P@`[J0`XV<# M<^*,G#:1X!B+6J1I#+"40>F1*M "<(G_`P0)0QA 2_-H";A#DUXI5-G0@VI1 M6P[5EI?F`BAP`C* @49P0AAX:0?#- <P81MX`Q$8``K%=X*);2Y 3-8H4:NY M@5B".4HPFE#G`B: `BD0FC)0`O47F8?QCX8PAA8RDIN 8O_D%T;%F9) !#"@ MDY=6`B^0`IQ3`_!P0M9'8[;&(D@0?$'P<++)(M*8"$;P,$MI:P80;(LT;3#$ M(a)%4)`RB0GR80G.T80RR G!*1CY=0@$,%@*!P99BI#1>P`;2E5J9#?[RF!#=P M`B9@G#0P`RLA-E"WBO+)@83P<*LHF(HV+9D6;-&E=D1 `)S3@$> GZ$Y-J#9 MGS#T`F1'.\[I_PB4-PX5,)GVEJ"CX59.)DM#`'J$UP(I,#8J@ ,S0 A$8 // MB'X+8(MT6 B?1VNS>0@OX")\EP!Z^81)4SP:VH!DI)\W4 (M< (H8 /&"4-* M``,`>A3*20B0:$1;APD(.@%E.99GB9D7DB&*H**/"4,E8 (G8)RV!Y">N29[ MJ5DR4 0(4(a)18)5WJ.9B#8 2^HP" N)K?!8.#0 0M8)\%&9PH8 )'0 .BB@(R M*D"6%1DRL0G]UTUQRF(950L;H)(M:1U:H1X=0A\G@PA#D';9&0,H`#0L\)I^ MLJ**:E,;J )65 A!0 1JLI03^7@!4*5ZV6E&^6Z$0 *3Q&M'\ +Y^?\")0": M^9F?J0I #B 9AU*#K-8^LRH`6JDVK\$![RH9M[%63R>H9UJ<+8"AF]*6`\!M M4.D"3%<(0M".TS6IOA$$"AF?#&"8+%(#)!8`!'"N:]*;+EJA+; "'#N<:<IK MOS<:6HDR[7H*)%"C\.H()! ""!H9%O `"$(`!)"O,&0"XJH$)J (@&E8Q'6( M+$"I@U!]"7N+E&H$IZE(a)AIDLC%0(%;M[SP.J':.?9DH`Y1<$)Q"HSI,#6*E1 MT4=04!6KCI!R`-&5?L(4TY1-+TL()[2;J)F3)1 #*4 N.; B'*H`&CDJ=%<( MA@0`0XN4@E!T[=1I"O9]CDB8VNI%*@"7)J#_`J2WL$:PII24`\$8*'6J5,1X M"L,WMJ'4LK0T03@`M9?6`BB@)BZPI(E0`R6P>EZ*-CK;(FBFGME3L>,8I0JF M)4F*"#*63,?#(B5 `Z')(]3:DU"G!#B LI5'CY=K"G-ZO"P7DBLS".H(=?M9 M`FVZ-D$PMWLX8%#)(F2D@H?P*P5@70H;`+/V4@8V7!OX`FNSMYD3`)RC!*)K M`YQZ"-@)0P4``_J58K ("45DCPRTJ]!0"?FKN=7J`D0:0S* `J@[J&NC;=PV M<9^)I0_37+!KA_8Y7,-U:_)T&470`@:\)C% `.IX1@:W,-#ZI"R2!$7P```< MB2=62J? PA)QHY9[_QQ,9 [U"T"@"30W$+>(\"O6^$X:B6F"6 B*]T4TH#.@ MIVD3AHHVX&HG- "GR;W.9)\M,#7E9\13#$ ^XCK.JZ-=^P@N5[E]),,)$<8J M^\7WT(^0\P+5%T/:B0(Q,*ZF:PB6RK?*ZI;ZH[8YW"*B%\11JIXXH"E$X (N M^'=%X#L4E1' "D.,%!3+RQ>4V AU,@XCZPD>T$8TB'*<^Q-H1W@J< (GT"D> M8PB*H@2:UFD@*U.%D)#K6 -AQ3DERGJC$XM#0 !:A#FDHD4'@FT6JW:O64&T M89F*(+9[A@J9?"Z84%K'X0$N!'4V@ +B.J@+1P@XP#3B:8N7%@-&9BJZ>/\$ M:10`[<<4G,-W"R!R*3@>!RMNSW@@-H"!\I0(Y\=KZRD(.?HU/!H^L35BIV"# M1K*,7EL;&Y #;QQ#HHNZ1W "ER&[$/=.*(PY2!!,+[ HP(>7_U$$:N,^U2>I M^0.+6?JD`Z YG/.*B>"3T)RW\>C"D6#&[4"VG)!DZ '0^]/)[7 +#Q=#;3JL M2E "QBH(5)3*J'@$H M +Y #.IF-[JNPZ(:7?J@E#54(:'?(`!3"5'0#>4L( MN$QX>_Q)-%T+FZP(_AP0Q3BYQ6<)&T)*D_$`1QQ#1Q"<<QP#)Y 802!X`!#$ M@)A,!0U#+ "J#BG.W>(""Q0$\IL#CKDF\[MQT?O_12O(O3T-O5!7<4 [N<G[ M",%(S)T0CV5MUM!Y#Q%0`[]\*:(\FLJ$U;J(8 B0F#F K(17Q'/]FBX$`P3@ M1:6,"#2[)DDP-2M2GHC0QXR=")O=#F;7"$^U$& KW#JH"9)]#Q#,:]%L`CN] ML83@@<7TA APF*[XR3%T6&BF60DS;'CC(VYGG40`J>\HMQ,-=8!CGW9CR@_- M`H\$1"U\#[N57P`A9:0`,KQ!QNTR&A-PB&SJNR]CIG5,`M5WD9SE=R&-< !D M`-!%8=]WVUUTWK_(% KUU,XJEW"<Q!&;R%%C"'='>(TZ2Z1QR8501+63AOG- M"0,L`!* `5@KE"@0X/U:_ZD8Z$X0AEA!R"(.T. 25F!VNTB%]8DLI(OJFPBJ MO28E`,O!TX+OZ*PYL((a)Q%(4Z%,E+)-/+.8-H_ GXV DL'1D:D*B88Z2H"P#0 M'0!","U;&EW=5=T'T%QH)F#'! $]5M?O:-)H0P/$9-5T30.9D@CFM,7<2Z&= M$@/=&L^$P-N&#;0<11O\W#638:!:'J">T-41X +C)Z@U,*R%!P,K8(<8>%CC M)YX2]F#'I&M/V@(WG3E%4'WR1$7!EP@N`+EH@P)%8)PQI<AM400'#$,U8'4$ M:+PUC6BXLZ,FBY*>H,8"P&/2J^G:N:0'&WH`1(L#5NJ7!F[OJ(YTR#F-&H=+ MB_\(1)"(8)ZX)P`#:L("V]@BW4Z^B<V;Q9K%B9#2_I?E@T"@=(H**/8.EST: M5PC'X/I+2;ZDNAY#-IX`#-"'41Z&TV*0F3,""F65>'-(@XP(507EF.,"W(DY M/Y=,@S#7NPY 2."7E-S5^]4(]TP.^DT)]X[)\9T-#2#51!WC\-SI+[#%`8NI M"B!F#:@J1K"(5EWH;%G>\IS+`)3 I$J74XT#2?',4,<"P7L(R3T.&R!.A7:# MQ8B@_DMH_F8A-##$F!/']3/C'7R:PD5=^YY8A&?5SVR5VJ9V#[.833\(VHB( M*( O/\(L2>RH< _F`/2MD/#;NM4(KZJC5NX)?R(2GE#_R1R!`;P6Q[\BX'Z] M)KF6\6LB`_UQ]B.0=C>BVMS<V(:P@JH]E:-JG#4PL_-#OTM?U(JS\OHW^((0 MC/MWWRA+XK?#J@Q0IMD)KM,,W<_*VV[GJ$=^L0<S3#BDCC+@`J4ISHM `'G- M(C@[]R6 !$B/"$+PN(MOI'7\"&K\U?UT4IB;]1QP\KXM&:6(WJ%/YBG@'M 2 M/022,X 3% X3NLZBBS5@K3FW<OCCR*/:*72X-LH/" ""@X0`+RA"`8J+C(V+ M'Q4"DI.4DA,>08Z-'963%!^9FJ*CI(L/%)V3'*6LFD$:J9T'2H6$)8<F)4HM M*XTD1$5%!$'$BD4RM8)'14%&_X(N!#;/1(FMBB_(M3 I+R6&)*,O`\F#2BHU MU=:+'+&5(:P<$ZD4#^KVH@_RL1WWK:_ME##8R%;K5@H32$JX2*$NQQ%R!6 4 MH0'@2(X:`)1 2]>PH D4+0#(*#**R URA8ST4R3"`D!)[TJQFU=O9;\@'O2E MXF>35(:7DC(T(W<+Q0D9)6R@4/<"I:!L-9P!L$&DWQ 8& O=.(%"6@M2,,8Y M54%#"!$CH=0%F0FP0UI-)-A6NM2S7XBV=4?]!+HJ!\H:*%#$2(IBAK6FR7KP M&)0$1@P`-TCV$R>6D-(3+$KD`*=IR(W*M53 ,#$DP! <*T^]C$EJ0RRZ>=7= M;<<Z]O\B$A> 3@@!XV0RC8%=E)!QHA<K$B&3[="Q0]" `H)>K"3A`K0@)8!- M`(@QY"VCK"AOH&"8%Q9 3*5<QZIM>Q0)3K3;,Q(1Z66&(BI0EHC!M882@]9( MDY@.S"TV"&HW3530"RE@U()WB@B10Q)._?>"87G!%PL%'I1"@GFIL">?)G)U MTN&(`:CV4@=")$?41TV5T$(*$#IR##E ^$ @<SX(4H--)"!&B H?421=9P(Z MI11'-M'73@4?> AB)SRA*$J)E$SP`&?RS080E$'@8(2+VA@5`W#&D3*A4SXL MIT,/@_RX4EA:&772"S72Z10+)F 8VY256,"E7NVL8J4HZJ7_HJ656':RP2($ M&$%+02T$M]]XK(!7BPTN4*@8(5_=0\ +U15"`PJY#'!D(T4\YE0+)I!G6Z.2 M:% C(T'D%LNCASI"0J*=?&(EH)U J0@)CA$50V PE%!"K*4005 A$0610Y(` M#&!#:??@4(!U,AX$0 &K0DJ1?DH5)I\'[?!*"@&ZIJ)!KYH0.XFQ(X[@$D"& M!D $"RB9\]%1)0"6IB-A/D1.9$$0X<)3-4AVCQ$*VS*C"=^6JXBFR2A4W(B0 MK,>*ONU<0*\C>Z52@0@H>AG+!2-\)]*DA2AQ" HU$+;4*# X!4 .BA"0`PPX MW,K*$%(5`E@*G^')" P5HW3$"4(8_WU3O)144!,I+3T9Y<F+I-R)!3&/"&PG MN^&:PPLX`%P08*@Z^Y&?C41#<S) !Q#$H"L5P7%&,(SW0@SEOA U2C#,4(Q\ M]F;02LCQ@:TWUH&6W5[7[<+5=L<N!(8"#0IAJLF:R0S0P@M5Q6;MM(/(.!X) ML"^"C5,EW, "+U9/=[8D_9*B8BR]TTO"OJE<P'=>M ;%I"(YL%[.5LQ6-+<C M0OP]2 P$C-ASQY7*&(a)`.+GSK% TG<)6[3;O3TTH^`%UP?FPDQY+!\3UAGHH% M7SN"P^&%W/RY$NFB6P"*X+9DR"!O[7$(.;JWB!SXQF?04]RAL#2O5K +()=X M7UT@5SS+Q?]F=_="CRA<$ -LM:YS@<F%ZU!P,.N!BGXK$<)I_E8[:!6!3#ZS MP0D$."(LB4@4+ML5#'TU1-^A8D/YRU [*! "JP7C8<D@DN?\LQT8G" %*U@! M9O:D$OD$X8:UH,4N:E! V@&@8 >STMF$8HT@*NI$I?# !3201&ODA%^V"<$1 M@_7#1@3!A1E!86 &IX0C!"XP."2$Z1#4GB#EQV>0!( *7@"#%Z1Q6.Z0#5 $ MD $/(BP$]7&7)C'(@>SUI /U*58?'0$#%3AO$(<,S E@8$5FJ< ;Y$!@>X1P MKDCZC#CC61XC1K !#:R2%6*;GP8O"!0->'(1Q-2)**VA(8!88 /_6U-'-&-A M`3@>IPA$L,'=KG,.SYD3!2]X)$I:P*WV$,%5OJ0=M$IAG@EHP)O6X"!L[+A) M25R /2+H`-8R4,=6) ]M&NA 034A`@X0KQ,$O<<7X5D(9[F *YXS@0OX5XL' MC8(a)`.+A6/,/C/5=44P`4V #+U%'-#6A0$;_3S04VP($-9""5*-W ,UL!PI=0 M( ,<",$#1@`[$HS@`Q[H@ 9PZJ@BCJ(%XZRH#%Q 2= Y"R4T: $-B.#4E1CA M@2/=3PUBL-78C2)^E:A ![H:`!*D[ (K5<<']MA/;AZ3GG6=AP4NP%<+T#46 M:NW)5VE T9HY2Q>0_,K>5">$QC;VG2,E_P028E68JI7"C93(@ A'P18.O90E M3,WK)%3:$[2*]K2U6J@]BC $(46V$ .@@1<=V]@A%#:>2D@<"<X7A)Y.PIX* M/=X(Y!(\:YCVM!:HDDU.BMJZ)K>1+XCJ2%W0`A9H+"^TE:$+:("$U[(`+=;( M53\I,$<-;."\&GCH--6!F^8*@(YY\4!HW?LE#NS4)D%(Y'2)<!H4!2&[!""@ M+\]1(a)Q;HDA5.HN\DYM<3L3GWKJYX@ <F'((-_%7!@.6 :NM2!!=X^+4`J,%N MK?3?[.+'EXEK+%M-<6'4=K(N&M!)/S<`BL\&`#XRQG#[.B""%=^#! 0`<@NL M$S ?T2N[X*-0D?\%`0,?,R*FS8UH70XZMB;:Q%XZ'ML&/&!6L&W/9TEPP45> MT$X2.S8`B.%HMD['`A<PTAY!@/)IG9D7$F!643J%<98!"]00Q&S$DAM@<F+P MRJD$&1PVEJAC14#+'$ 1`"R IW1R8,J5)!BU$]!IHAW!P9)!F!4;T <%*G"! M#/2U`A2@0(Y?0P$+9$ #006%DU%$JB+@``;0.<(+LN("0$N.M@0(\A!H,(X7 M=/AT0YAUO:+\:75@V1)YAE\(.B#4$8P@$[ [JH0]$()I=^#;X/YV"#SP@?L& MFHC_;2L,; "#$52O!44[M]ZRVUA2U6#3I7C ? &2@;6BR ,M%L %\"E@.6*D MQ>#XEK<B2GQH%2N;L=G=;<+CZ.!YS'2S(WI/CI-;:85[_% &K]KB/JXW8HA\ MXL>IL 9,7>H,G#>H6RIYKX(0(a)I6[W,^^)KG.=\YSD(L"Y?V '=![3O2B&_WH %>0D$`#L` ` end

6 10

Front page... with new logo.
by Rene Rivera 01 Dec '04

01 Dec '04

http://redshift-software.com/~grafik/boost/index.htm Boost C++ Libraries Hopefully all the bugs are worked out at this point :-) About the logo... In keeping with the style it's simple; it's only based on text outlines. Components are: * Solid "Boost" with surrounding template "<>" in outline form. * The slight perspective shadow of that, with the "{C++}" as part of the shadow. The hope is to invoke STL, templates, libraries, and C++. The "<Boost>" part can be any color, and should be adjusted to fit the background it's over and the context. The shadow part should be kept in a dark color (it's black right now). And it should be easy enough to make a vector version.. Just need to crank up an SVG editor :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

10 14

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 01 Dec '04

01 Dec '04

Thanks again Caleb. A question for the designers of Boost::thread: Would it be possible for the thread library to have functionality added so that the thread itself can call a function like 'join' that releases all its resources? This would simplify my program a lot, and I suspect other applications as well. Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: Monday, November 29, 2004 3:43 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? On Mon, 29 Nov 2004 15:24:07 -0500, Tim Laplaca <tlaplaca(a)voiceglo.com> wrote: > Can you post your code to the list? Gladly. See attached. Basically I just abandoned the thread_group and am calling thread::join after the sleep call. -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

What is a secret of mpl::set?
by Alexander Nasonov 01 Dec '04

01 Dec '04

I have implemented typeof+mpl::set based "unique" algorithm for overloads library. MPL associative containers are impressive, I must say. On an overload set containing 200 functions with unique signatures at positions 1, 2, 10, 39 and 200 new version compiles in 12 seconds on my notebook while for old version it's 47 seconds. What is a secret of mpl::set? I expected it's typeof-based like "at" for vectors, but it seems it's not. If it doesn't use typeof, may be I could try to put mpl::set idea into my algorithm? -- Alexander Nasonov

2 5

filter_iterator requires copy-constructible predicate?
by troy d. straszheim 01 Dec '04

01 Dec '04

Hi boost, The filter_iterator as implemented disallows creating iterators via reference-to-base, as it requires its Predicate objects to be copy-constructible. This is a problem for a class that is passed a ref to a predicate from elsewhere. It's a very easy fix, though, I'm wondering what the rationale originally was for the restriction. If it isn't significant, I'd propose the change below, as (at least from my narrow perspective) it is a big plus to be able to do this. 56c56 < filter_iterator(Predicate& f, Iterator x, Iterator end = Iterator()) --- > filter_iterator(Predicate f, Iterator x, Iterator end = Iterator()) 82c82 < const Predicate& predicate() const { return m_predicate; } --- > Predicate predicate() const { return m_predicate; } 106c106 < Predicate& m_predicate; --- > Predicate m_predicate; 112c112 < make_filter_iterator(Predicate& f, Iterator x, Iterator end = Iterator()) --- > make_filter_iterator(Predicate f, Iterator x, Iterator end = Iterator()) Thanks for your time, -t

2 2

Re: GUI Library Proposal for a Proposal
by George van den Driessche 30 Nov '04

30 Nov '04

> Message: 16 > Date: Tue, 9 Nov 2004 09:38:35 -0500 > From: Caleb Epstein <caleb.epstein(a)gmail.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <989aceac041109063895d91c0(a)mail.gmail.com> > Content-Type: text/plain; charset="us-ascii" > > On Mon, 8 Nov 2004 19:18:13 -0500, Edward Diener > <eddielee(a)tropicsoft.com> wrote: > > > The one area where C++ is weaker than other languages for design time UI, > > and component, development is in its lack of a general run-time reflection > > mechanism. That is the only area which I see that is holding it back. > > I've been toying with using the properties library Reece Dunn recently > submitted (in the boost-sandbox CVS) for this purpose. I've got > something very sketchy, but it relies on a visitor pattern to "pass" > type information to client code in a manner similar to Boost.Variant. > > I'd prefer a way of storing the type information for each reflectable > class statically, and in a generic way, e.g. something like > std::map<std::string, property>. This would enable the reflection > code could be decoupled from the reflected classes entirely and just > operate on this property meta-data. It would also allow client code > to lookup individual properties (e.g. by name) instead of having to > visit all of them. > > I'm stumped by how to store this information in any sort of container > though, since the properties are of different types. Any thoughts, or > is this madness? The properties are of different types, but the type information for properties will always be of the same type :) So you can generate a property set for your class, that includes the dictionary that maps names to property_type_info structures. Each property_type_info would be automatically generated from the static type of the property. The thing that's bugging me is that all the reflection mechanism is covered by Boost.Python because it relies on the same principles. I *think* the boost-langbinding list seems to know this, since you also need the reflection capabilities in order to support languages that aren't Python. But that list doesn't seem to have much traffic so I haven't much to go on. In order to avoid too many reinvented wheels, I'd like to see Boost.Python split neatly into two stages: (a) Reflect C++ types into C++ objects. Each type for which you provide a reflection map will correspond to exactly one property_set object, which would contain a set of property_type_info objects. (b) Expose the types to Python using the objects created by (a). Once you've made that split, then you can add: (c) Expose the types to Lua using the objects created by (a). (d) Expose the types to <language-of-your-choice> using the objects created by (a). (e) Serialise the types, using results of (a). (f) Bind types to GUI objects, using results of (a). (g) ... you get the point. George

14 42

Using program_options with other options methods
by Allen Bierbaum 30 Nov '04

30 Nov '04

I have recently started using the program_options library, and I find it very useful. Unfortunately I can't seem to figure out how to allow it to work with other option parsers/handlers at the same time. For example, right now I am writing an application that uses a library that has its own set of common options that are process internally. So I end up needing to write code similar to the following: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("my_opt", po::value<int>(), "set my option") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); custom_lib::options opts; opts.process(ac, av); Then when I run this application: ./app --my_opt=10 --liboption=custom The problem is that I get an exception from program_options: error: unknown option --liboption Is there any way to tell the program options parser to ignore options that it does not recognize? If there is no option like this, how can program_options be used with other option parsers? -Allen

5 16

[smart_cast] template functions declared static?
by Caleb Epstein 30 Nov '04

30 Nov '04

The header boost/smart_cast.hpp declares the template functions smart_cast and smart_cast_reference as static. The SunPRO compiler issues a warning for this: "/home/nbde52d/src/boost_1_32_0/boost/smart_cast.hpp", line 264: Warning (Anachronism): "static" is not allowed and is being ignored. "/home/nbde52d/src/boost_1_32_0/boost/smart_cast.hpp", line 292: Warning (Anachronism): "static" is not allowed and is being ignored. Does "static" make any sense here? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[css] Wiki-style front page
by Reece Dunn 30 Nov '04

30 Nov '04

Hi All, I have made a few modifications to my Wiki-inspired front page design. It is available here: http://uk.geocities.com/msclrhd/boost/boost2.html Differences include: * background colour fix; * heading alignment and padding fixes; * positioning fix for the main content. The page also contains the Google search along the top of the screen with www.boost.org (now Boost) and lists.boost.org (now Mailing Lists) as a drop-down list instead of radio buttons. In addition to this, it uses several different styles: Simple -- Basic styling, minimal colour, simple menu. Wiki v1 -- "Traditional" Wiki style Wiki v2 -- Alternate menu/link hover scheme Wiki v3 -- Alternate menu/link hover scheme Wiki v4 -- Alternate menu/link hover scheme At the moment it doesn't render correctly in IE because I have different named styles and IE is broken in this respect. Firefox works and allows you to switch between the styles. I am not sure about other browsers. However, I will focus on compatibility once a style has been chosen. Which elements work in each style? Which don't? Regards, Reece

6 8

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 30 Nov '04

30 Nov '04

I went ahead and submitted a bug report in the Sourceforge bug tracker for this issue: [ 1075456 ] Boost::thread under Linux crashes after 200 to 400 threads I made it a high priority, since it's a program crash. I attached my program to reproduce the problem, so hopefully the person who fixes this will be able to reproduce the crash pretty easily. -- Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tim Laplaca Sent: Monday, November 29, 2004 9:29 AM To: boost(a)lists.boost.org Subject: RE: [boost] Thread: Why is my prog aborting after 283 or so threads? Thanks for the link. I'm not sure it applies though; the prog isn't spawning the threads simultaneously, so it shouldn't be taking many resources. I've found that even if I only have one thread spawned at one time (where the previous thread has died out before the new one is spawned) it still aborts at the same place. Over the holiday I pared my program down to just the thread spawning, and on my Mandrake setup at home it dies at the nice even (computer) number of 256 threads. The same pared-down prog dies on my work Fedora Core 3 machine at 405. Under Windows, it doesn't ever seem to die. I'm getting pretty convinced this is a bug in the boost library that manifests itself only under Linux, and not my code. Perhaps resources are not being properly released when the threads are dying out. Since the prog is pretty small, I'll include it here. It spawns a thread every second, and each thread only last one second. #include <iostream> #include <string> #include <stdlib.h> // for multithreading #include <boost/thread/mutex.hpp> #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/bind.hpp> int totalthreads = 0; boost::mutex io_mutex; // iostreams boost::mutex numthreads_mutex; // for changing value of numthreads boost::mutex threadid_mutex; // for manipulating thread_id using namespace std; void threadfunc() { // wait some secs boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread Exiting. " << std::endl; } } main() { boost::thread_group thrds; boost::xtime xt; int maxthreads=99999; // ******************************** // Main thread-spawning loop for (int i=0; i<=maxthreads; i++) { totalthreads++; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << "MAIN: Thread:" << totalthreads << " being spawned... " << std::endl; } thrds.create_thread( &threadfunc); // wait some seconds boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); } // end thread-spawning for loop thrds.join_all(); std::cout << "Done." << std::endl; } Here's the Makefile I build it with: lib = /usr/local/lib/libboost_thread-gcc-mt-1_32.so threadtest : threadtest.o g++ $(lib) $(lib2) -o threadtest threadtest.o -ldl -lc -lpthread threadtest.o : threadtest.cpp g++ -Wall threadtest.cpp -I/usr/local/include/boost-1_32 -pthread -c -w -O -o threadtest.o -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Friday, November 26, 2004 2:07 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? Tim Laplaca wrote: > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after > spawning 283 or so threads, it stops running and 'Aborted' is printed. Take a look at: http://www.kegel.com/c10k.html#threaded and check your sizes. -- Alexander Nasonov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 6

OT: C++ MT book release delay?
by Christopher D. Russell 30 Nov '04

30 Nov '04

I thought I was going to be able to zip out to Borders today and buy the new Abrahams/Gurtovoy book. But now A-W's website says it's not going to be released until 12-17. Bummer. Cutting it a little close for stocking stuffers aren't they? ;)

1 0

additional test for is_abstract type trait
by Christoph Ludwig 30 Nov '04

30 Nov '04

As I mentioned in previous posts the following code program #include <boost/type_traits/is_abstract.hpp> #include <iostream> template<typename T> struct A { virtual void f() = 0; } int main() { if(boost::is_abstract<A<int> >::value) { std::cout << "A<int> is abstract"; else { std::cout << "A<int> is not abstract"; } } erroneously outputs "A<int> is not abstract" if compiled with gcc 3.4. However, the regression tests report that gcc 3.4 passes the is_abstract test. The reason is that above error is triggered only if A<int> is not instantiated by the compiler; but is_abstract_test.cpp does not test class template specializations at all. This compiler bug cost me quite some time when my application showed strange errors within the boost serialization library. Therefore, I'd like to ensure that boost developers are aware of this issue so similar problems can be avoided in the future. I thus propose to add the attached test file to the type_trait regression tests. The file is based on the existing is_abstract_test.cpp. My contribution is merely that I turned all structs into templates and that I added some extra tests w.r.t. explicit spezialization. I therefore left the copyright statement as I found it in is_abstract_test.cpp. If you add the file to the CVS, I leave it to you whether you add my name there; I don't care much either way. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

5 14

once again: boost.bind namespace conflicts and how to solve them
by Stefan Slapeta 30 Nov '04

30 Nov '04

I wonder if it makes sense to write an additional header for boost.bind (and maybe boost.function) that provides the library interfaces meeting the 'modern' boost requirements, i.e.: a) this header should be placed in the bind subdirectory, e.g. boost/bind/bind.hpp b) this header should introduce a separate namespace 'bind' or 'function' to avoid the well-known namespace clashes with boost::lambda that are _really_ annoying. c) this header should not declare the placeholders in an anomymous namespace. (I don't know what was the intention behind that but it makes it impossible to write 'using boost::_1') Comments? Stefan

5 20

boost-1.32 appears at redhat/rawhide
by Neal D. Becker 30 Nov '04

30 Nov '04

I noticed that boost-1.32 appeared at http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ I also notice that it includes 2 patches, and only builds a single version of libs. I don't know if that's because it used: -sBUILD=release or because of this patch: Index: tools/build/v1/boost-base.jam =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/boost-base.jam,v retrieving revision 1.129 diff -c -p -r1.129 boost-base.jam *** tools/build/v1/boost-base.jam 28 Jan 2004 22:50:17 -0000 1.129 --- tools/build/v1/boost-base.jam 1 Apr 2004 22:48:45 -0000 *************** rule common-variant-tag ( toolset varian *** 2621,2630 **** local version-tag = [ MATCH "^([^.]+).([^.]+)" : $(version-number[1]) ] ; version-tag = $(version-tag:J="_") ; ! tags += $(toolset-tag:J=) ; ! tags += $(thread-tag:J=) ; ! tags += $(runtime-tag:J=) ; ! tags += $(version-tag) ; if $(tags) { --- 2621,2630 ---- local version-tag = [ MATCH "^([^.]+).([^.]+)" : $(version-number[1]) ] ; version-tag = $(version-tag:J="_") ; ! # tags += $(toolset-tag:J=) ; ! # tags += $(thread-tag:J=) ; ! # tags += $(runtime-tag:J=) ; ! # tags += $(version-tag) ; if $(tags) { I'm wondering what this does. I'm not too concerned about just release, without debug, but what about threading single/multi? Did I get only single or only mt? Should I care?

1 0

BOOST_NO_TWO_PHASE_LOOKUP ?
by Robert Ramey 30 Nov '04

30 Nov '04

I don't find anything like BOOST_NO_TWO_PHASE_LOOKUP in config.hpp Is there something like this there that I've missed? If not could it be added? I think this might be useful to me. Robert Ramey

4 5

Boost logo
by Michel André 30 Nov '04

30 Nov '04

What about something really simple. All courier and text and add some color scheme to make the logo distinct. /Michel

3 3

Re: [boost] Re: Re: additional test for is_abstract type trait
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

Hi Pavel ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Lunes, Noviembre 29, 2004 11:39 pm Asunto: [boost] Re: Re: additional test for is_abstract type trait > > "Joaquín Mª López Muñoz" wrote: > > > John, now that you're at is_abstract, I wonder whether you could > > consider adding some workaround in is_abstract.hpp making > > boost::is_abstract return unconditionally false for those compilers > > known not to work for it. > > You can read about the origin of this request at: > > > > http://aspn.activestate.com/ASPN/Mail/Message/boost/2209389 > > > Wouldn't it be better to have macro like > BOOST_NO_XYZ defined for failing compilers instead? > Oh, yes, this is probably more sensible. No matter the final implementation, though, what we need is some direct support from is_abstract.hpp to help the programmer avoid the crashing compilers. Otherwise, the guarding macros, i.e. the actual knowledge about what compilers do support boost::is_abstract, will be duplicated and scattered across the Boost/user source code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 29 Nov '04

29 Nov '04

Thanks again. I remade my prog to keep track of the threads and join them, and all seems good (at least up to 10000 threads, I'll test beyond that tonight). -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: Monday, November 29, 2004 3:43 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? On Mon, 29 Nov 2004 15:24:07 -0500, Tim Laplaca <tlaplaca(a)voiceglo.com> wrote: > Can you post your code to the list? Gladly. See attached. Basically I just abandoned the thread_group and am calling thread::join after the sleep call. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 29 Nov '04

29 Nov '04

Thank you much for figuring this out. Can you post your code to the list? Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: Monday, November 29, 2004 2:30 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? On Mon, 29 Nov 2004 13:57:00 -0500, Tim Laplaca <tlaplaca(a)voiceglo.com> wrote: > I went ahead and submitted a bug report in the Sourceforge bug tracker > for this issue: > > [ 1075456 ] Boost::thread under Linux crashes after 200 to 400 threads > > I made it a high priority, since it's a program crash. I attached my > program to reproduce the problem, so hopefully the person who fixes this > will be able to reproduce the crash pretty easily. > > -- Tim I've compiled the test program and can confirm the behavior on Red Hat Advanced Server 3.0 and Debian GNU/Linux running stock kernel 2.6.7, though I got up over 1100 threads on each of these before the program died. The problem isn't one of threads so much as one of memory however. The program just runs out of memory because you are not join'ing the exited threads. According to the manual page for pthread_join on my Linux box: When a joinable thread terminates, its memory resources (thread descriptor and stack) are not deallocated until another thread performs pthread_join on it. Therefore, pthread_join must be called once for each joinable thread created to avoid memory leaks. Indeed, changing the code to use individual threads instead of a thread group and joining each after the sleep call fixes the leak and the crash. I've successfully spawned tens of thousands of threads on Linux with this change in place. -- Caleb Epstein caleb dot epstein at gmail dot com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[Boost-bugs] [ boost-Bugs-1075456 ] Boost::thread under Linux crashes after 200 to 400 threads
by SourceForge.net 29 Nov '04

29 Nov '04

Bugs item #1075456, was opened at 2004-11-29 13:49 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=1075456&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Laplaca (tlaplaca) Assigned to: Nobody/Anonymous (nobody) Summary: Boost::thread under Linux crashes after 200 to 400 threads Initial Comment: Reproduced on both version 1_31 and 1_32 of Boost. Reproduced on Mandrake Linux 10.0 and Fedora Core 2. NOT reproducable on Windows XP (Vis C++ 7.1). Programs generating threads with boost.thread abort after a few hundred threads. I do not mean concurrent threads; this has been reproduced with a program that never has more than one or two threads active at any one time. Attached to this bug report is very short program I wrote to demonstrate this problem. The program generates a thread every second, and each thread only lasts a second. There is never more than 1 or 2 threads active at any time. On Mandrake 10.0 the program aborts/crashes after 256 threads. On Fedora Core 2 it aborts after about 400 threads. The same program built with Vis C++ 7.1 on Win XP never seems to crash; it generated tens of thousands of threads before I manually ended it. Also attached is the Makefile to build the program with g++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1075456&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Logos - Last Minute Change of Heart
by Jonathan Turkanis 29 Nov '04

29 Nov '04

Dear All, Just as I was ready to add "logo" and "rocket" to my list of message filters, I had a change of heart. Here are several sample logos I designed yesterday. Best Regards, Jonathan begin 666 logo1_1.gif M1TE&.#EA3 %D`,0``````/___ZT,#+(<'+@L++T]/<--3<A=7<YM;=-]?=F. MCMZ>GN2NKNF^ON_.SO3?W_KO[^[N[MW=W<S,S+N[NZJJJIF9F8B(B'=W=V9F M9E55541$1#,S,R(B(A$1$?___R'Y! $``!\`+ ````!,`60```7_8"".9&F> M:*JN;.N^<"S/=&W?>*[O?.__P*!P2"P:C\BD<LEL.I_0J'1*K5JOV*QVR^UZ MO^"P>$PNF\]H(F#-;KO?\+A\3J_;[_B\?L_O^_^ @7@Q@H6&AXB)BHN,C7V$ MCI&2DY25EI=OD)B;G)V>GY6:H*-S::94;:*DJVZGKE"I,*RSK:^V2[$OM+L` MM[Y(N2Z\M+_%:FRJPZ#&S$#!+<JLS=,\SRS1J]3:.-8KV*3;X33=*HL<&QCI MZAD;&]]PXO&RR/.%&A<3+1(5&.[O\@"OT=,5J(.%"#4F8,#V`H&!AQ C2HR8 M0,$"!P'#D$L!R& ."@Q=)!! LJ3)DRA)_PXXL !"1BX;4?S!L -DM!<,4NK< MJ1*!RY=88I[HPR%?S9 N>"I-.4 !T"M"3?#1@)"'364P"BS=:O+ SZ=2HI;8 MD^''U6$P$'!=*Z# 5[!/Q)+04]8LTA8*V*Y%`#>*W!%Y- 0YRPM&7KU<&?2- M.U#8'0Y5[=Y\T0`Q5P*+=;PEN":9'*,O%&IHMR$#!@J121#>!:.RT@(-&BQ( M0&"MXLPV$#28\5?$'9HO+'28HZ%"B=7$*"\U4&+!@*T)<-=0NUM&[P!V.KR( MX*\.!PHCD,]JO=R$@^=*F4N7H59 =5&>WX!O$8&#'JH!Q$M3GO[$@JWKQ="> M>[PU!@T=&[A0'_\?'E"@'QND1<A'A*3E05Y_)P`8H L#$FB=@0+-88$+&OR1 M01WSA<='BB(\F E_/*EG@@%+;=A"AQ["5T\<VK50020CDF !'T&.,.0(a),.XD M8PDT*F6C"A T:=)[.\;'!G L#.<(EB(LM >7`7AYQX4QHB"E3DO&\, ""AP0 MD44/\+!FFV\N$"<.#BB00$0'6(31"A!HA1*5G/6R(QR@J7#DEB6(F0>8CM9! MII(H+!5=#! H(.A.!"BP&:::*M7IIRUD6AM/`^B&0J!LA6AHH6]X0*(DD/)1 M*Y(NN%:F"?\I=9L+F:*W55.D`JJ L$L1"P,#R&)8`JNM>@.BM'$(QD+_!)/< MJH>V=DR*I@D0G,HI# Z(RQ8!?[I0KF7HBJ17F@% &VTYT](;!Y@H_$AKH[;R MBVL+NE)*P@.;[K3 "[U:)L `OZZ0L&4,LX#C5FG*.R]']6(<!XLI1%H(.VYP M"P`');8!<ALBDRR'MRG)F&>S+2.L\$D-H_#PS#4W9]F2%E\L4\8_QR%!"R4C M4D,M!<*3I$X#/+266R[<//,`Z?HW\TE4KPHSQ2/T[/-00(,=APO='7+T=7.- MO?35)$'=@@,\F;N5V^;%K1?=)!R&JM,FJ>?UUU*%'3@<LK9@7R)G"Z[QB[FR M?9)3P,IM$@$0/*#W5I _*WE)E%O.5N8D;&[2_Z4B,- D<W\#/I;B:<.1X(&( MCX,V8&HW[CA)"-R)%T\'B^! P:A^>CE*O0?P.U<#; 9WW"<T4 "\9Z9$J&.= M'=K&ZZZ:+3OK8C,.\.TF><H"!%NK]"SP.X$>;_D+G\^5^E*?!*\($) ^0O2# M)OTJ]6]@OX('BDA<]?2'M.^!CW-5.\'P3L(7]RT%,WGC20-)D+J30' $"T1) ML4Z OY-,#W;[`Z$;_*>"LAFB10YRT-!((($4.@@AM7 A!58X@A:Z$(:U,^ ! M55*\$[!/`#T<P7FV4K4?!M%W/RQ)U3+XN!=T<$KZLQ()4V#"0F@)9?YJ`P#; M<,4K99$-6U2:[7:H1/\4Y(0G"<0@YD9PQIVD401,;*(:EW)$,RGE@ZZ2H@M. MM"\2>,P.(J,#RPZ8O!-,["0I(-]2#C""0YHDD4D4`"-'$##>M>"))<$CM4*8 MO0*JX(^*""0@ORBIM:%$/0Y8``(B69()D@!]DU-!'$LB(UAR3I;E(0$K@<@" M3))$D_;BY":]IP(7&4*4=4!F#EE0R9A1<"1<T=T(G'6"!V@H`-0T@35K1 )' MIL25'+QC%*W7AD2E`%M]' $HZ:!,,>I08#J#3@F:*;\5V/*1`:!GW^S)S:[M M4@#@9)(X/S1 _KVA2"LX'*/\V"^&_HN9N32!-V-)`GW2<@70Y(D(+$J2^9'_ M(*,[X15;`GJ_@>H(5B%SP04D81P2Z$L/+1W!2[MERGI6,YH1W%4*9DD2.&;3 M!#P5@"%':D>>`'-Q5AJ9@L+H!Z8BJ@03X(,YH_K0%7"THRD0G0=SNI,!6)6; M//6J"JXJU*&N17TB\&6.JD3.-M!P!>N\@VDF,T9XSFB-<]3H6%_C4R?ME2<% M2,%$49)&M1XU:,(,)APNL%0_E"6NHQBD3<.Y%- %%9A75<]E_VI7$X#TIX8= M)TK=P($7S#0/=8'L,FJZ3Q1H-7Q<31]G=7*IH**UHDJQG]6XDL#0$C2QBXN# M.3^Y!\9VB:[O_-9-\;K1!^+2DOET[DZ54L<2#-%2_P(UJF@-"H>ZN$"U;.@` MB\#K"<FV%JA<Z>'R3"I1I=QIO=I%P6"EF8+KZC2M["U44MDP7!54H(N$PT!J MPH1<B/[4>&LA%-=<"U@2+/@$KPVL"]JHUY+&]Z3<=9T,+%!%#V@`H0Y%"VLO M.L]_FN `6_G@-F4[`A0O1<5*N:U@^XE?GNAV!/1=74%%* ?CRF "*1RP"<C; M"?.2V'>#/<DD21 _E!2R!)_5().']:DHG^0M#GBC$&D<`+4^N6MZ"N9^P=A? M'A"9$T8F2:<48(#7ZN2(BEP*WN*L$W#2&;!ON3-*P-F B*5 5"5(<E-BPX $ M/"=GK0,N8NG0`2&;N<!?)?\C1=L[MZ_,<@`Y3G+;+(TJ^KHF`:1:L4Z6W%>] MB!6I;8T#9()PYDT81M(F0?3ZD.<I^*;DMGKN:JUC; )=-46:SN,U"2B\ETV. MF;2.SD&K,?%J6 /TN<C[H4<#$%23#$#:S4,)`1[B9I+05]1KJ2[M=MQ)[R3[ M!LN^! RL?#L)JT#3E7XW^/!&R:N1M-M2%G.JY] @'Z3;$C!0J\)\TH)[/FV# M(S X5^A=;X5].;9;(35BCWVO<\>@`E5,C@O^2>L70,#%"F/X"3Y^-9$W%V): M#M?G\KCO.GA P#6(P 4`+.*WD3%W,F"WI1#N686!>K9KR5H*R&J2' ].T=WK M@P?_,E!F%$3 `D7[APNJ/3?QT: !`C<);&: =;9L/=)L,8#1F\-*=^M[M$K7 MP&DXEA\*7* ?[R"F"A3.*0/TJ0$\IPS(=W* PUIU[Z/V>[S:A&\#B%N;@_VZ ML5L>=TF<H0$*< A$*B)XRD2>(@JH/+@@3Z<ZC1U0;(H(`A3 @+R/&^E';SRS MGT2-ZZB^R*R?ANM?[^K8-V/VM%>W[9F!^]R'8O?&Z+WO)P'\X'//-\/_??%] M(?SD.V+YOVB^\QD!?>8?'SO3=WSU;2']['O_^^ G]S##3_[R^Y[BYD^_^K/! F^/6[__UHWK[\YT__^MO__OC/O_[WS__^^___`!B `A@``B$``#L` ` end begin 666 logo4_0.gif M1TE&.#EAT0!B`,0``````/___ZT,#+(<'+@L++T]/<--3<A=7<YM;=-]?=F. MCMZ>GN2NKNF^ON_.SO3?W_KO[^[N[MW=W<S,S+N[NZJJJIF9F8B(B'=W=V9F M9E55541$1#,S,R(B(A$1$?___R'Y! $``!\`+ ````#1`&(```7_8"".9&F> M:*JN;.N^<"S/=&W?>*[O?.__P*!P2"P:C\BD<LEL.I_0J'1*K5JOV*QVR]U* M+N"PV-(MFU<4@'K-WIS?<%&:37?'[]TY?6W'^[%Z>P!]?X4H&W041(%[A(:/ M(XALBD-?81EUD)J1B4F,CIN%DFN41Y^AFJ-JI4:GJ(^J`*Q%KJ^BG4BU)!,4 M%!-!$KV^0L&]OT 1PL<CR<+#+[&SBYDB$Q@<>QP8RS85UX(=&A81.=[8>^'C M.!,7L6KA%[S4*KR]YVL7SOKZW#:G%.X:27,1X8('08(R2*!1\"!".@II`'Q( MQR$?%@$I"@(EL0X&C70PD(-A$.2>"S)*_YID@S+&QY4;,<)\R'$&HYEK.(QD M$2&C29T$?8($Z@(3SGDIA*ZL*>/F40!$542X]Q3JSA13J^:\FJ*"UHLKE)ID M&L-IHPT;.CSDP((J.K1I*;)=X99.![AJU[;(*X@#7(LQPWY50Q:&60`>MI7X MPI>EBI>-*G"-4,'H'@R/$6Z07(*RY9 K)J"+=X("AL:$66#X2\<OW->P-V#. M87;#0A01/J^Y;4)"WWZ]`_)>_'N%!.$J+M3A>L("4IF3/ G2T$(W@ PHK&,O MNF>[">TOP*=0'IV%+NBDI%=DCD+#'N:^GZ-?`[]1#'?L19!?0\:\?!71J.>8 M"_&QT1\)SM$Q7/\+$@`&P($C),C&@BPT2 >$)3#B04LJG"=8>::\!X-NWHU MX@PGEI!B#"N:$(&#B&5P006]]!!@+JW%X%4;)L12P0P[@D6"CT#^-\)^(,&% MP044NG!CB&Q0!T,$>Y@@X@Q5EG"E#%GB5M=2P,TGBX!J</A"ER.@&8.:`;!Y M)ATK9%45AF(.) 0C9KK IIMZPJFEGU@"JH(%J,%$)X"X0+F&E"^(QL9<)#C8 M) N.KN&!"9+.4*D:E[I06:$:>9#?"4^V8E<,2 + *"<&SB!A:B7$<B@+KPZ" M@B5A')B,!1>L!M>7`.2)*(BF)KH7'<)"!NM]H)6@K*TRQ#*;"1ZB4$'_+(4- M:2PM]KF0*@# !;G&CS"(JP:Y))@+`+J>[L$N"=6F@!HTV_)T@U.SEK"I&I"6 MX* '8:(PP;\H_!OP"0-7E$*\APCZ(3XO4*!!B38A)&R&,,[ZK0=V8GP2"AMW M#"^,%\MA),(*N_!LMHPMVY%F`Q74%U8PJMJQ!-8AEM^+T]V<LZ@+5Y3!N\TY MN.H*WY;\A7L.MW!87S/V<D$&-8.K@KIK=""C,.8\1'2Z#VF=3R]=(_3U"(?) M%C79%VA0<[XF[$O8V!1,#:H:DP8]F"!PBU!K510WM_=U: P.50S PB1R:8:S M$3(a)*?^/TN.!?30[OX "7-5C)>B/40=4/]9WA_]VAB@XOZ11Y8/K3*V4NP[,P M:; XXS1%P/10!V.ETDH1Q=#03+W[]Y4&H[+P+44=,/FR9G+<OI'I6%G@/#@8 MY-U"!-)KU$'UAM7Q1>*<9I"["Q-,GXUB1DC JP9P76"!]4V!`9<&[H\??SMH MT6^!_0C#-FTR\FM?/GI F;8I*1_%LX4"%\C !CKP@1",H 0G2,$*6O""&,R@ M!C?(P0YZ\(,@#"$-%"" $II0`%IH@ I7V( '1*$!)S1A`S9!PABB, LV%( " M7IC#&6JBAC'T`016B(,<[A *,+2A#R%1PP*PT =)O*$-C!B%(:Y0AC0LH0&$ M$$4>&*"$1Z0"%G^H1?\NFM"+8+3"&)E8QB!T<0=?U*$:2[C$1]1PBRUH``+B M* `#(& !:Q1!`Q2 `!,JX)"(/&0=3:#'`I20``A@0 #B&$84), `!EB #"Z9 MR1@$TA!W9 $$#I##&"X2B*5,XPE&6<H"$$"5*:"D#&0)@T\6(I0KX&,J!7#* M71IRE8[TI1Q50$L8%-,%MOP#+E/@`!,20 $,4"$A!_#)!1@@F'W$I#8QJ4D3 M\'$`"5"A-6-8R1,<TP7G9$$R_;!,%-20`"A(YAM;`,@2(@`"):@G+%&03A;T M4P7KQ$,[3_!.?)I GF=$9QM-`,1R>G.?"AWF"P)ZAX&:X $F', !%*G"`*S_ MT* EF*<Z2RC)5?Z2! M(I )>V4>5+C(`*4TD2PW@TA50- X6-4$"=CD`!8 T MI EE@4@?*E$1Z'*7#CUJ*AU:@IO"(:<,I68J"_#3$0PU!5<EP3F56LJD"A.B M!Z5C%ONX`@>H\ $,4 `F67K"!)P@JR? : D=D *6EI.3VI0J`;;9R1+@%9-Z MY6LW4^#4-T!U!/U\0"$%`$]&!I4%4G5K7$\:2[#ZT[(`%2L9R4I,S&8UBBYD M) +JN%A>F@`"V&2J5C';V:*VH+!G.*Q1M<B JC(@F 4PJ3U)X("5DI0$#Y"J M#D':`&P*8+0-J"IB65M9UX[4M)O%8W.=F=<3#K8$G-\$+#GS&4/MEO*ELW7N M9<6;6>BRD;/3W24"L.I+`EQ7!/K\*G@GR5Q^UC>LYK5C"9U(1*)>,X<%*"DS MV>K,T:9 L38D``...M]_ME:U)+"B"F%K!E0^=@0QG>$0$<F T+:@MX?LL O0 M>L@%T-4*43SA? 6:0Q&R5XEC#:*+W]K#&=OXQCC.L8YWS.,>^_C'0 ZRD(=, )Y"(;&0@A```[ ` end begin 666 logo2_1.gif M1TE&.#EA/0&^`.8``````/___ZT,#*\9&;$:&K,H*+@W-[9 0+M%1;])2;E/ M3\!55;M:6L%E9;YP<,1X>,J!(a)=&&ALN-C=.9F;Z+B\.8F-2GI\F>GMZSL]V\ MO,JLK.#'Q\RWM^C3T\_ P.?;V_#EY=[4U.SBXM'0T,_.SO[^_OW]_?KZ^OGY M^?;V]O7U]?/S\_#P\._O[^SL[.OKZ^CHZ.?GY^7EY>/CX^'AX=[>WMS<W-K: MVMC8V-;6UM75U=/3T\S,S,C(R,+"PK2TM*:FII:6EH2$A'AX>&EI:5A86$9& M1CDY.2@H*!L;&PT-#?___P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````"'Y! $``$L` M+ `````]`;X```?_@ &"@X2%AH>(B8J+C(V.CY"1DI.4E9:7F)F:FYR=GI^@ MH:*CI*6FIZBIJJNLK:ZOL+&RL[2UMK>XN;J[O+V^O\#!PL/$Q<;'R,G*R\S- MSL_0T=+3U-76U]C9VMO<W=[?X.'BX^3EYN?HZ>KKD27N[_ E[//0\?;N)OGW M]O3]OO?Y`@H<2%#@/7$9<4K>**APX<0(YXH&"^AQ5,+!3Y$P9%CBH\@0XKL MB +B0'@74W:"I]%A1Y J8LKX07.(S9LW:?Z(J2(DQX<&WZD<2NE=RQ,>/\;\ M(83(D20`HDJ=2G7J$2-#@.B(^?%GPX HB8I5Q#*?2Q1*=00I@J2JV[=P_Y,8 M";*U:\FO^MR-W3NHK(F&'F,"(0(5KN'#;I,0\<'5*UB]?(>6=9EB:1$EB#-K MIJJ8<5>$H1&MFCT+U*T*F0(*;RYM6LD05;TO/M8WFAZI0&G+>*ZMV\`2H;( MF U:]&UTI?^BK?SCR._GO8//(#XQ-&11^VQ/RGZ<4VZDE7<XAT[>M73J>;5[ M\ANV7?+VW2WA,XUZ!N_R^,T+D9V"MO5/R9VD7B,!!A5?);FAMH(0F.7G8&M) M_+!"?R6EYUT)`9V@TPN//3+?7QMV>*![9H&G@G@/INA:$=/UA]=UE\SGD%0_ MO#@@(C(V1*.-(WJ(H7*5+=B@BE$I<0021R8YI/^*2@`AFW\P(OCC:31"2>"4 M'%7Y8H]7FE7?> Y>14000?!@YIEHGAE$4T\]:$2+%?X7HY>5T>AB7HQ@66=4 M/]PI)Y>'&*7;"C\L^9R16?5P)@DC,+K#HY ^.L*D)%1JI@]"%,$:=$GX,"%M MQDF"3T-!TOCI1%$:,NH)I?)YZI^ $I)CD$*4IX010BPZP@XZZ) ##L#>(.RP MPP*;0PXZ[##I"&8.MNEO^_7$HZAZKL""J2K$F6I?U5[K:K;5;=NCC*BQ<-]S M1^3*Z*XZ!&N##37$2\.\-,Q@+[TTQ%N##<+B@*RRS )AA*$KLD <GI (RJH* M++1 (PNO6G>CPI4U_'#_Q.+&1VYE-+3UFQ)$_, #N[_>`.^\,\@@0PPLP^#R MRR^SK/*]\?*+0[*-^C#$LZTA0</!L)+U(7@KM.""5$"T8' *-@)$9]%'1Y7T MTDT#NO$*'7^\V,@[Y&!R#?6F' ,,+[S@PMDMI*WVVD:[4+;+,<@P0[XV)TL" M#ZO]AL0.&-]82( FLN VTBY [&)UZ?U()\.#2UWXJ8B'>MS5/O"LV=8CM'L# MV&*3C38+H*\@.D^DQR2ZM0T;_0(,<<^][\W,XFTY8DIXZF?&WP7>PNI(F[WT M78@?5>[N,/1>.'61^[T7Y01G=H3()+1[\LJ>*SUZ3R"1I/UR2JD@.NBJM[[O M_PTY[& F$<T?5GO?@2JN6Y!&PR #TC&\8+U=$H$'OPORTV^_X8<+E_*(PKSH M"&%2TJM!RJH',:Y0"'CYB\A+@@2^U<7 =>0S7W.B8SMM#4AA03"""(UPA!*: M4"I(,N$(13@$X*$@A",TX0FCDL(2KA K'AS-U4:0/L,<P0>\P@&\9C V%U@/ M>UX!34&6N)'E>*]A;HM;OFY@-P:99P08^QN6:@4=(SPP!5Q\CA%R&)EJU<!C MK1G"KKRFP"(>D4(.$5!V,M*2I#PQBG.SP<UVX ,P:<9GKX+1J- 2QM]X$2:% M],T1;C= TF"(:%F#$!!(L(/-T4 &,##BT(a)(8E(H(C?^.]%&0X%YPP1IDD 1# M<,T16A!(O6R,*4(0`DYN(I4BS%*6L8P-]@@52UG.,I51L25.<"F$(#!R>8]$ M2]&,\!H?C("-1/S?A Y7FXQ=*3F 45#\9#!%'9 `"#UT2Q&HEKAJ$<]E<AL? MTBQ)/;,9438\:=CJT#D#=4J-G6,S&RO!A3 "3JEB1'"-$2@IQ$MFLH'43-QV M/"D(OYRF8KLK909_@,;,!,%@'KP:%$F93E-*)0CR:N?C2F>M\'7T!A\-:3Z/ M2$;)8(EA0!!HYC87S7URLI-S/$C[V),ACUB+?]S4(Q\KJCX?8%2 >KJC!;FY M+Z1Q+I^:Y(]22NHVUC'5!D[_K1=4E08T:_9CD SS03BK8H29U@"3CX-C\"26 MTWTLL9SSF9*)BD;*>N)@J)M!`BOO]!U15O6"^7+J`O6)T) \<92L<YU@,4E8 M_FA++(-,0=&(>A@C^,H&!CT>'-_*V<YZMD,#&93@8%#/&^!5,T-H@;32XR51 MQ(a)^P2#.H-!U+DJE",;$TB"UCWWA,EYI%LBT(Z&:,T#7,RL!^_(FC6>@300EN M[[G:`TI>0ELNH)I2!SZ@+%Q(<-3IELB)4$LLTM#*6P@^U'2OG<%X,_E&QTC. MD<I100M^T!KBY@"S]=NK?_X22I'X5R0\J4SI!NQ _*VUIQ"5WW4+I9E5MM)] MY_TI_^N01C:;)C%#V:0@_V) 8>3.9K]>G4=D5U"#V;GE",6E07XQQM\/8" # M&(BQC%$'NAK;6,8XQD $=LSC'5L``QV &#P3.C2D>&]W,KAN$#8#A.ZR%</: MY%_ON)I0ALPU?E/^77%"S X9`5>XF4&"#W2 WQ<8+DX:B8 `ULSF-KOYS7". M<YL3$($-6%B)YGQ!DJD(YL,DP0430BHVA_<"I-T/S6Q5') 8MCM#GSEX[X6O MD5G@@\TTB<PJ-G/$0N,E-<OYTZ .-0(P0&5M<1I(15.P:?UHF(OR$S*34:;@ M: 1H?L(UUI*=-9]JC>9(2UJ9+F"U882@@QMD6K_A.C5')O^0@&8CP "ACK:T M!;" #SQ:'Z<F6@M(6P,<,!@Q25!MA:+DY2.?[6Q:EMA.?VON<Z?;UQ?YIWQC MJAGB;NZXR$YT/F0=16Y*H #3/@`"!CYP`DQ;``7(P/'B%(!LHX!QW,8!,!$3 M&Z;I0U7)K%CJ&MC2]BT:?"P5(%\B*S@3<Z8'.#@K#/(-ZQ_Q6WZE)<$`Y&R M"G#@4;XZELYS<($'*"#:!-@`KU&%H9>.MK1 ()/2R02$IC?]!R0(],6U2)\@ MG>Y@7EV5@J[.UT:2YK=%6[)F@I #!:X\BPUU.43K>ET&R+D!BJ*DKX!EK%XI MRP,.F/FG#1"#H3_Y+Q7C7SWK!JG_9'E-Q6>W>&@"12<!(U'DB]"3XS_33\@F MDV$O,/E4BG!?%2\<\@&XVC9I8(,</$#.#HA[UX;%KQL`RVX\\ "T/PV!&.RU M.J%?5>#E1S=B?2VS3O8;N;CG7J^GO;79`Y7Q$?+/%;A [+3KP>;J%WSU"$J; M;,?!!5"OJ&=N#FSZ&A_L>-"#`WRZ`#-8^:OE$5E&<W1N^+*7&UN)([F>9LN. MR-']DS?RR[/@!<+V%D.@`V>%7$Q#=%J45'05`S1P`]L79ZG'`\4&-BI3@7(S M13G +!P`<'(V`3(`:/V!)[JG5'##,F/C.1SW%>*"37BV?&D'89#F@E_U2,!5 M:9F1!&26_WX@.&["-WQ'IF<U\(!PEGHCD'(K4S9F\S92)%0\0 &?Q@`TH'X\ MV%#?14&I@S9I@U _,77UIVBUX1Y>:"%E!"0L``/G<AA"8(1F9FL#U%? Q8 : M@'H2: ,Z:#TE%3YVQ2P<"&<'8 ,?*'4MAR5.Y#VG,V1$YG4YM5#<44:7UP(W M,%91D03WE7ZW5WD81RZ8-P,W(&<40 (IUW<&@ST"5E) B ,CX "?=@,SL(8H M\">Y4UL^<6'YX"/P\4E.4XM%L8C;T'S/IQE"8&R@V'5YPGY@YP(R8 -R5@$C MH(IK"$<O\8-)E@,5\&EE)X65]R&FD4WF%8.XF(MMI5-@^(WPL?\/,<(/K>!_ M,,!,M%-VJRAN")A_@^1\,5 #R;@#?KB#P:,;\O4",V #'O!I!-AW*U AH9> M85@BTE5-\#:,]M!9X,B0?D$1XCB1%+F0H3 JP(52F4$$P+B#EAAY+B=?,$"/ M<58!]OB'BG=JJ-8"\Y@#GW:2(/B.LA*&^0,\!.%*7/:"!8*0"=DA"XF35J9$ M"GF0GU64Y90*:O=_T'<8/D"'K"B3/F("#U>&-%"/-6![Z\<21K8[FBAG!S " M]SB04 E*IP%=))&0#-6%V-A$9HF6N.A*PM.60GD4@.%<SP412;1E.:D)_O<" MZG@81U!V`AF"BT<M4BF255F2`2EN1UG_C,<H9PP`EG\XA3K94Q/4/0/F$WK9 MAH-VF8Y7.IJ9/()49$D!$P$6BQ)1FO^UFJR)FF)8"AA9-#$`B0`@!'0HA5 9 ME2? ,#"0F'!6`8N9+;.H';%IC/\89P\@F3$I)YWY$2!@`1'0; 8W9W0V`1TP M.I^!5.N&?"GPG-&9`-/)9LT6`=:)G8?8D%67`CJV``G@9@:0``]0G@Y$$CW6 M8S^68_B98]!9GSO&2#(X)X"W`B]@@XC!`V=5.'R5BX!'E<D8G*UH`@5Y?%LI M`Q809P,`1%?)2CP8:V@!`A$P>])F`!%PG=/$$5]8F<K1H1]Z<")*HG;ADPC6 M`0\0GJ!6``^P_P&&J ('MZ,(QSZP&5__UV=P<03&EGBYJ9LIP*"*F:'"":'$ M28/.)P.G-X0\()B,^7>ZT0$-X&8$D `-``%@"@'/%F<-$&2.)6ANJ*5<ZJ5A M*J8@ZF9EJH4'IC^>QF8$@ !MN@!ORF8%@ %"M@)[RJ.?E@#7%C2@T(CIF!E# MX(=/69@+M:"]V:!,^J 1FGL!:HR!*@`#P &>&(4L0)@)4AD1$)X$\ `9`#.L M(S,A, $+`&<1<&C)5G2+,ZIV:JJH:H(RL*JM^F:O^FB(`QX@\*8-D $F6*PQ M$ (2L*ML1FIJTYX", $88*PR(P,0X&80H$ J8X(;8 $6L*L+D%8/NO^74G*I MLYD9/W"5R^FHALDJ2OJ;#CJ<98$6_U>A</8`/0"34F<==-(!;PH!'[ RTAHW M<C,W&["E[OD!^]1K,=JO_QJP`GLO!?MF!H"P9UH2'0JB!I !%IBM&SL#&Z"L MGN,V"$!M<K.Q,T,#4\IF#W R*=.Q:P8!!DB9V/%;@M,#F:$$.!"%[FBH2-JN M;P:<DTITN5$9VS:R;Z8`BF*EMI8AE;$!X9FQ%NBP)[LO%D"C"*=PR=423?NT M&EN!4GN!5&NU"5=K71$D&!L"]M*R`#NM%T@#(UL`)^@R(PL!::NV*I,O]*JR M0L0Y%9BVT 8!![5^I-"7] :83ME=_XEQD.K_FS\;D"[ ANX#;-5ZM#[ `_:X MBI_ZH$RK`D[+9@: MFH;MV^3JF#KCWM*`!^@61NQM9X+NE[[,J,K,ZYCNER: MNOM$B'4:="@C-G%+NO<B`0* `&L;`R,K`6F;K0\;A-8Z@9=D@?8RMX%K<>): M%/&U;1-G&$1PH/F:N%3'KI%:DCN@O2GY7=[C`L#[9@S0?3EK>_G*;AT0G@40 M`BB3K2%[;FZS.J5+`GNX9A.K6<_XOGPJO_5"O^YDOV^3O_LK`!/[/Z#3`6WV M`/+2.65S-D@H/W)3H0N O,0K`!;PNC%33T*X9B9)4]1C53(PLA80O4>Z'LHA MFV<(%T'@>8#(O3.Y_[CUR*B?XD+#,[EM-@`/X ,]0 )E=UR9^ZL/)P)O:@$1 MS%B:9&-I0\%+> -QZ&8.$+U*@<1MIL1\RT!.W#8<17I2_&8.4#\4S,,"X $J M15A*HS9+5:$0H,$CJ['YY$[X2P-Y*\(3R%@5' .H: &^([C8`:4N, ,!6!4_ M0(FO5HXV7)++V([39%A%@P&!R@`:T'V3:(!&+%DI*P`-`"_86F$--&"DR'O= MMLEK=JJ/\SV;W,GQ,EA'),KR1,HX8,H"@ '4$P,@6@!?DS+Z!$^$"#5EX\8M M([<",,=-3#PU<,<"`)QEMC9N4ZT8\#^ ?)&"+ .:%Q6'F\CR08,^ZV85T/^I M?<=*I],P&Q !"2P`"E !Y#<RG9=X:,8J*^# ;48")I-97(5$I6EN"E9Z"7P` M.@@^\LQF]&Q<[!6*=L$]^IQD_.QF!Z! ]M)F!["W_URB,$%5&9 `$D V2(B$ MGR,;HL.5REP!D[AR?_K$GX-U-)PP^Y:D>G:#!?BIX:+(WLNX;J8`#G !W'J? M$0`!#>"L;C8`#, !NM)Y`KFTDV:P:\8`$KUBR--$NY=D.&#&:\8!3/P"2"T` M2DU33!U 3@UQ4"W5`L !\'+'$7UO,6NQ$6;2]HN%H2.*C!,#RGP!:FC0AY6% M6<NSW@&D_.@\-C"8*YPPW/R]@EK3$' WB\(KQD;_Q.T;H &]9AI04/CV)'.Y M.,Y'6C:@`PG<`)<T-AO@9H]M7!ZV7]05)()WV9D-+"%<`,5V2<T(&OKX1&ML M8USW1?(8UY\(@I#,=1LZ"NA8N(9A!.@ZPS*=I((]V#U\`#9-`1Y 4&;G=UXB M7V8\`+]"AT7=:W2T,(+#@#APU0A'PM$M/43DW(GF/H&GW=Q=`+P2PF%MUDZF M$8-X==?3&'>!&BP9U\"(;*I)>7B=UUL)`[X-%T2(a)L]J\S8MLW.?7`!K0W)+- MM$7SI(a)K0+B^]6N,]&17#CS8PQ6WF`9[LX!!.Q!(^1^SV?_V(X6S&J22.U7,- M+FOU/I,W$OX!S]MFVSH;_VALN86+E](JW=___18!CIOJJJ S+6<%< `.X `/ M<.1(K@`'8'[19(a)`2D%_(,Y4?X&8/L-K!&*[D-K3RV&UZQV804&PC0.56CJ!8 M_D%:[@+SB -=OF8/8"9O=@&W2;;;6);)=Y9*U-_V+>"(9A)L-;@MS)([[A9$ MD'Z(BPD8V<UM1@% /#)SYWK(DBP>0 $-<,[NJ7!G%A@MH,Q?7J25Z&O7MX_] MR.1LY@#IO;R</L/*\^E<:0.BOF81N*<#<*WXMDD/U)8V21!X[F87P.E+*Y'3 M2[TP'@.!7A6#WJ@XSBT%_F:*WGV:TR__TBAF4@&M#F<2H&D5[0)2?0'LR(H? M.?^3U5P#W,T`C&+*S(RY36I-@B)9Q@CN;I:^/4#+P6NK444Z_B6+U;1O(IGG M/LX>['?L2"J/PTX5Q9ZY7#BN01YGBL[H0O0N[](O.',W/4 !:_YFU7Z[=(6* M;:;M!2C<(/GG#&C*!V FW*WQQ\7Q0N/Q*,O0/= #/D#I;#9P._UC0=;6^&S= M\9KONL[KX9I[#QG(Y!KP4Q$$1 RJAA[8-)WHBK(#>XLO=$-X=W,!$^]F?OPX MHV6T;$;RRQEB\_%PVS8#TPC1BC+M%T" */G7-7R87?_U;'8`*]\#:C]M!4!G M%G#/?C+>^![C.:_GM_;K! [/: [T4B$<9D;TPXWH;$;_`2.3<IL]-M,ZNU2D M+% O9P00`NR%9%:_9G(=W-*[?+')C\K,]N6GZ[=M\B</SYZO\F?R`%$O;000 M`2)PIHV)]C"@[U=:J:Q0G,*^D4,?TX5?W-YLN65F1":]5'ET5R/@A'+V`'HL M/Y>_S)^XLUQ6G#/P^4 \[17P_--<^NH^_:A_)APP[2Q*L?XI#W<_^WEOC4[Z M"K(a)/^%%!!+M?\$!.W$?/9M^LAG;X/5>8?3M `C\'" *"@X($(3(Q,#$S"(0" M#S@U,2TK*"<F)24!FYR=G)DF)RDK+C(6C@P^/@>.#CF2E):8FIZU`:"BI*:H M/"0[OR,D' X*!H['R 8?E"FR_YF9`28F*"HM,*>$%S<T,"TJ*-*WMN/DY>:; MN*,N,4 `[N_P[T0Q+RPIEYCGY^DL,#3(@BJ,N#&CVPH5*1(J5+%B10L7,&34 MN+%#`T!!$&K,D"&#!BM"KF!]NP1M7[03U%K$P#;(@8\>'UN^FC1RECY-H5*N M;,5CAPX<.'+H&!&,!P\.%20X<,#@0(&+`AR\\'8O'#1I*:\YTL;-&S@3XO2) M'=LI'2EV\=*Z(R*C7C-IM,C6XN?O8H4=-MJR0&CIA%\4@%,P;/%"(HX1Q@`J ML$%C!HT:#QP=>"7#Q8JJ)<WA1'EV@B,*+QU(UE&C\F62<<MM1M'Y\P@=-VS8 MF!CTU_\.HB-N$R5!HD*#`<A"3*WY+-JT:EJS;>OVS:K<Y_M*A%*'5FT\(WK? MYH->5KJH?O\`WBUM^1X^:=+^CB(LPX8.T0`+X)C].#*A`J1-8TY-;O59^X-H MT(,/\ V"'WFGV6123O\YPL$.D33F6 VT!:7#A3[I-@(/'BAPC 0QE(<:3L=9 MPY(@7#'W55C<M=C==&?58%T\1\S@UE?\04=7>,A40!I-LLP"2GHHK.?/#19= MM,,-%-IPP3$<Y.46:C>=I%.!`A30PY850"FE/50NB%(U,6!9P&N,(:)(##), M6(-L-]P`E%"_&.4A2#;NY<PF6"%WH@`I>N6<BX2B`Z-*-,S_"$\2>1)7Z(YV M_>C5B,_@4J0N->@`U07SO4G",0\0=*."FGE'72.#-+#E@*"*:@\XF:EFZEFH M"M(`A*7!X,*N+KR@"$<S./;8FW+JL ,)'@`WR $TA)B@)M*5F-P@@38'5HZ% M/N<=:X@FH>@[!>E)TJ.F@A=I#2H.>LLS.:D`'@Y/B9<#DS;@D-BR.'1E;:SC MF%7*5D89=:\@!^2;+JG]S?HO(1KHP%B(E+"P`@L/]>KKFFT^5N\./#! R &E MO?#L+7V:N-5R@EZ;+:';(E?#$=^Z\X.*X[)<;EWBD78PB^CP4Y@-,1WC8VSU M`CB(![ \BZTG9KW@V2 &&,4;#U@*_X+T)$I'!Z/3A!B JXV4J""VV U-W,+9 M%D?T& X[0/"Q#8W".F16?U:[XM(KB]6R-3,4$3,`0="\G8N0YHQNRCSWW*Y* M-03MR-"SW>#!,0U(>1F.>*^+50K]-$ (!;[8Q@'EEFO'+]/1%MDY(1(L&3(S MS12Y$-D34_S"(C7@\&2J!!T\MY\GZWMWWBVVW,\,1/Q-A*Y9$WXSCT+KC'B. MOS/N.,.NOYF#QX0,,(+P8?:[]P<$+/O+3[5Q/XCWX",\U_CE$^S3PQA$T$'L M?N4/6&""N0O1##78'49ZIR>XI YXRA&>NH(a)G%^.]8 ;MB-D1G+4?FTW'7(;; M&;9 D16/7/^D)TS2V.1009Y7&7"#T<I%"]P6(!W,2S;U&AT)*V-"(=EB2"ID MH2 :QB09P" "`L `_LZ#'OT)A@7KH($.!<"#WJ6L>M-"$<JLE3@&ZFUS+'B@ M#_X&@.S@(W,W>=ZY-'A#Z5 #//$Z1M0<UIBU><X1%B@(,[Y8G)Y9REWD&\0# M?A)"C>'@C82(HT&J(J2X5*I=+,BC(!Z0@_G0P(= Q !?_(*>2A+)2#,`I )R M`+=Z[.N )DL@&:W80(5)1 E_^X$G]^2\"^*L1]*C(@J/@T%D*( 'K]A(1VY M@C0*8@"'6"7F*L6N::QG`8-@`%!FH\N.V( 'OA0`,/7RC6$2,W7_QTSF,C5" MCT@>I!F4/&$1!6,-&2A+`!KHH<CV`\HH`LI@TR-E*6&TCAH8X6]#$!P8M?:= M5T;O<+(LH[0P<!$*C" 2B& 3#9"DQA XJR;H.60H1.$N( I"`7%B9B)\M<LD M=<VAEH'H"5-(41985 `8C8U&?/@"(%J@(9,D8B55^ (=-L"1%)3;WF*PQ'<V M:U(JDR=9MN60&-!@"']#`@7#IR,Q9C">J"L9#(S6O1X,I%DOX&CN>BH``X3 M(#&U9$Z.^#0!-" $L^'F"USPD(A,A*M>!2LX93I6=Y7UK+)9*0S6"L0&G$UB M^!,K2M:3`:AUJBU 91=%54)5"$0B1,39_Z=0R[(X&,S@!US$@0O !)=6]A-Z MCXOE\)A&)#(A$QD-X('#VL+6_[F'JP28(a)*X`.U? H*1(*A !@"I''T1,16)( MM.QKCQ';V5ZFMI8(3&YWF]?&L'17+(0`6R7&E^3^Y5(MP$#\## "^CP4<^E1 MAPQZZH#'BLB&D[T)(A]H`U3&+ BKK!EW"@=+@([V1;EPP08NH@$>F)<%MC.J M>R1PSD$(a)``.;/0A"%)(0ADP@7@20P&.<:]RQ(5' .B#P,0Z<8+$QN,$K>' A M)%P#&CPR$;MZ"" Y'+8%,UAL(CBI5RGTR*E<SH";TX7Z%DF9S9KN=.F=2WB1 M*)%[2A!KSI"L^/]<"5I"^$@D]U6<,;,(R%98551A<\CM%JH##EROJQ#(`"4. M4C8,/""-"]A L(+EPP2_.(M&O4&7OVR ,(^9(0TQ,YK5O.;GGNTA"7!$G3$@ M,3(W1 06:$#\!)"1$C^R&^*:16FS&()H3N9+D56R4/T5@QH(@8L].._@M&5& M!-872 LD47[WBXP"<$"U"$((0[+H3!SH``+1[%H"=AW-!5B 31SQ+5NK.U@M MU_K6N8;:KA/0ZU\'6TW3;0C%(+!H1Q1@V0FHM@`0D($U;V2V?,&Q"3X0@7*? MN=4.@ `$[$?(.@:Y/Y6E`0^X2(3XNF\L'$Q!*)'A`$E]DIB3?D&M'G?_97W% M;CV%H4&]+G0!!B1;C1#8`,9BL-$6[ 6<EZQ&PA>N@X8_7- 1GWC%[SR8VTW M`1^_SP,VT*9@T\/-= R%"0H+E6,(,<F:EJ<#9V #(W]+"5BK8%.E]2>0[ #* ME,+AI5Q094(\H >PUD]?L'L[`-I 3D#1@ 0>T `$>-WKZL; !V! =HHG8J]L M_6:0+JEEW%T=*#C0.M>_#G8(B)WL:SK[6L/V9HAD+ 064#?=$= `"%A XA1W M^5XM?KD1I0<$&,! !BR;.V/EYB<UR( %," "C-_[W92E9Z<__3?XODJ^\]1) MT5N"%_W0E>TK! @#H+XD&MB[KFWMR)M@F%;G_R94$7C'>U:C/4EQ#[8:?M<8 M[VFL2XH#/_A[W3MU8X?;MF?,Q+XW.YNTK_>T%U](Z:%IK87RPL;8V/- !KWB M5&A4'KCW6TG09\ZEK/J+.*#UY5G[1'%+L:8GTP<\<% _E2!%Q'^]PB9NXFC9 MYWQDEU7#=S8-,5?BM"U'=( 90R$*V'P,&'T/.&8)T1?'%V# PF8<P7W!-WS> MAW[%5&R$L0@:HU(GEG8JJ'[P-B99- ,WX#>EEW^=-4]CX@(S( 'V-Q"-0GW[ M(Q@3@P$#XW0`. *4<7LDA80/X2O 1H(EJ'<H^%=[\7W7A L4Y1"]\BMMTDR_ MQX$I9G%;*($99SL8D_]0&VB&T79<00)P8S4Q%B@L%+96@#6'\T=*V$1D-1!! M,1-_D99^";,U,U UGT,"!K-9'M8_TH8!IW4,`T !4$<"3WAQCI="U3>%>&=V MS^> ; 6!,*6&[K8NG"B%G@A]<#B*8Z9VX313EP*&%N. MKA6KDA=7(B*T#)1 M"6$V8<B TK=@E 0M-+AD*N0/-@`S^)1_3*49QJ$Z+Q "VD8(#5 !45(0<<@" M'6 !YP80!\ !4.>$<#-(="11QU<[O'*+O/)GNOB!:W>*=D0DU><0:,,KKOA7 M,+5@MA51*XA;[D(Q?X8V[@A@^VB*+/*/( 9@`XF&WZ2"?>B'Z]4>0<!%2F#_ M`T U:J6R.!-0C1?Q=;Q6<UE"`5*S`[DT2#AG1R6@'D@HD _Q9]-ED!YF6^<! M+4N#CLJ%9Q-3-H5VD$/DCW3(DCI9-D0Y-OP8BZ<(#20E.V-3-F/S@>%DD\?8 M+^%U%C2 `][R-T;@8TD61J:R`8$FDF+9:A @-:\1"7+4>.CU"06XD QI<6CX MCC0)E/M43/LG.R_V84-4DY4RC^''/WK)8/L3C_+(BT5T6W(a))CWU!EU.)C%G! M<Z272G-D0%IC3"<UEF-9``R@`;P1.HZ$6&I9F-$R5BWIDEJ8AN9QCH:(.B1S MF-<UF" H4\2$.D,2?J^Y/_D3BX64,+5IF[FIF[O9_YA4.5@7ECM(P$5)8 .1 MII$"-2:7B9G@R `/T#"VX1,XP"0S0 _,$"15I'0I$ -9"7]JB(JD9I=B=9Z4 M69@JV9OH:4E*N9J\R)[H>4W">8C)R'."&#-;&9I@=$<=@ $68 $7L"$#H@H& M>HD<< $*NJ 7H %P)Q07<B&-U%O&Y7G=F8HKD#REYWG,64K7-)]=Z)4?*E9] MJ9[BTX4H2I_UZ9C^(Q$ZP(RE-T?/&%5CPAX3H0,D8!2K`G6]<'GS$B=8!W= M(2=$4V(L97'?=Z%LAUE_DP07QTK9$J+O.9OE.9LV2:5-E:(JNJ*J495\8P-, MRD4^H(F4Z9CJ0'DW0"?!0/\4MH$^0 I#1 -#-):'C >1-\1V-!">WQ($>SBC M41JB# 2H7#JH^'5&I3 1&OHW2E #RYE^<X-P+D@L6/>F&%BIE8I];+91TW64 M)]2<V.5S\(>2?DJHI%JJQ>.EPJ4#>OHM2% #:MFAFM,N8/@K:V9BWD:&SW:% M&R5]$0B1L\2"2,5%0! BA1B1IGJLR&HIG)-$-Y"?^KF==/0^*=224WB+UGJM M*#B*<DF8-^D=)5617&0$S<*5HXJLYGJN[[,XA9$[B?HW10"M95H6)*,>> 9< M`':O^)JO]^J4CSB7G>6HWGI$6V21/#"NH8FN")NPZ5ILKJ4#Q\E%`/"NK\HO M=GG_6X%YL4;I8(a)J!FT0DE644L.[B`^_W7N4XF;"JL"AKJG<$9Q/Q`R,;,Q([ M@]U1F[]9L[D)FS29F^[9ETOFBR'[LHIB!)D862E;M.>*0Y@T$> *L3'+A[0I MG^T9M3N+I0)55RRPM$W:`W"34ZAGM%Y+JLI*"L*5`\$*L4A `Q,;*R6JI6QK MI3S+FVL8F<**4/8&GU][MS2XLLRJ`Z":5#YP$(MY;VT[N%NZD?LW"C2@@Q K M!"=ILG:+MY";7DBK<1(A9S!JD3_PI.?(I2OXA3[PL$S+1L2*<8\;N::K<Q3H M$)2'`Y\+L>\P!)J[N5/9N?PG!$#[+4;@.M0TAZ?;NXT9_[;_DSNMZ[H`@ 0C M`+C<JGX5&Q@KL .7&ZZ8!YKF\7F^6[VH.VGKP',Y,+RNJP1"$+M *;DT&X)# M<+NLZ@.-RY_6N[[O-KD7IG#;"[JNBP0_`(M\6;KX5K'I" 2K&JX^@);@QKOL M.\"3Y85'M&4V$+_$^PY%L /V6TE4ZZ'CFXX_\+P0:P0'M;6.Z+0$W,%^F+IP M!K_<N\ -;+\=*ZC22H=_67T5O,#OD+OSD9V.V&[&ZL$V+"MUV((BW+?$6P1_ M2VS 64AL:TGZPY0K$ 3RN\!"`"$:K(GE>L-0K".PA\!LH[@N7+Q!, ,SF;.O M%[4W:\0^0 3F:Y%!D,$RK+G4&__%:JPM4RQ@AV&[5PP/1A $.O"0U&>S>'R$ M(!;&_;O ]/LUQ%I\^+O&A-RS+$C%.P`$21S'2$ $0%#'C[BQ./MA9.,#05 $ M8]S#KX&=@4RZ-5S(H.R==H@[;.,#/!S'[J $1T $0_ #/R #_#J4KCP$1' $ MF;S 25#&L)$K,]R5H/S+\Y6*_H.F0Q$$MXS*R!S'/LS$CS;#Q?C)P!S*PAQ< MSH2C/F#!R9S-+IS+FZQ68;.8@QS-XOP)4>@N.KQP(Q $?:S-[*PH2D $OC O MW"2#X S-X_S+7D@-;0= :7HL8MS.`!VT/D "F-?,:)S&]YS0AUB'U*QPMD8" MIAS0$OW_PC^0&YV2G3;&A?:LT/@\S2UH=6PS`C]PRA,=QT90T2:)G6W6I]'* MT2Z=OW\Y"M3,SSEP+&%\S"4](TI0!"@MSX_V6]^'T"\]U"]RN.;,48_1SSDJ M!-B<TS."!$(PT"G-&!CM9H%KHD2=U3-+CS)](a)!.BU#SP`T.PR$[]#DE0!$#0 M"U/=&"\W?82IU7!=F?1JA[>C>\6R(6$]!$T=T$B UFK-1R66G;K"=U<=SG'] MTK3;DA;X@D(1##D:!+6,T_-;!%'=HU-MI"]'V%%IV(=-U(D]:V%X@5>GI@'S M`Y!=!$= UHJ"!*M,!$$@-23P&HT40M^V=VJ7O)V=VZ4RFA8[_VMMA8 O6!N_ MD*,!8Q1 $ 3(G=S*'01I7=QL>B'7F58;@6*,!\2=JMO8O=N'67T4$XP7**D6 M4IVX,=[DG1OGXZ:]-]UH5]T_N9;9_=YP&]/4NBM4.(;#`B= *J3Z/:09E5:! M_7N\>I3WN]'P/=3ZRS^SUMW!6(5X."R6.J<2,MW=IX];C)187> 8OM7;S90) M?H]9]8G<%^)G%WTI9I /F;/AF^$J+J(SA9@-II/W.I#X..,#N:\*)LGYPY@K MON-Z8YY?C)=&291"7I1/J9@Y#L$7SN-*_K2CZ9NWF9B!"9N_.;6<O>1+KL)$ MC,=:WL41;.5>+L$2);7MB:)?7N;$0T.X@VOF:JZ\A;OF;O[F<![G<C[G=%[G M=G[G>)[G>K[G?-[G?O[G@![H@C[HA%[HAG[HB)[HBK[HC-[HCO[HD![IR!H( "`#L` ` end

13 32

OK, Still gauging interest: polar_complex
by Mickey Moore 29 Nov '04

29 Nov '04

Seems a few people think I may have given up too easily, so I will respond further later (time doesn't permit right now) and solicit any other feedback on the idea. (My previous comment comparing the number of responses about this to the number of responses about the web page logo was just intended as a joke; I of course realize that that was not an accurate way of assessing interest.) -- Mickey Moore

1 0

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Peter Petrov <ppetrov(a)ppetrov.com> Fecha: Domingo, Noviembre 28, 2004 10:30 pm Asunto: [boost] Re: Logos - Last Minute Change of Heart > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > Anyway, I've just forged anoher idea. Not that I like > > it much, but the idea is a little different and might > > please some --sort of ++ breaking the barrier of sound > > or something. > > > > http://lists.boost.org/MailArchives/boost/png00027.png > > Hey, this is great! My favourite so far. > Thank you! I prefer my first design, though :( But Johnatan first Boost logo is also high in my list. > Why don't you try removing the distant parts of the circles > surrounding the + > signs (so that they look more like C's, rather than O's). > I think it's going to look clumsy, as the distants parts of the circles are mostly covered. In order to see something, the circles would have to be chopped way too much, roughly between 12:00 and 6:00, if you know what I mean. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

Re: [boost] Gauging Interest: polar_complex
by Mickey Moore 29 Nov '04

29 Nov '04

I appreciate everyone's comments (and I'll respond to a number below), but it seems interest in this is not widespread enough to justify trying to formally include it. I'll probably clean it up a bit and post it on my own web-site at some point in case someone somewhere might find it useful. It was a good exercise in humility to note that, judging from the message frequency, people are at least a hundred times more interested in the new logo for the Boost web-site. :) ------------------------------------------------------------ Regarding specific comments: Roland Schwarz wrote: > > For some applications, polar complex numbers have significant > > advantages over Cartesian complex (e.g., std::complex) in efficiency > > and numerical accuracy. > >Just out of curiosity: Can you give me an example of an algorithm where >this would be of advantage? Well, Hubert Holin gave one: tracking orbits (trajectories in polar coordinates). There are actually a number of subtleties to be aware of in mapping a physical 2D plane to the complex plane, so in that case, I would actually probably use a true polar_vector2D class rather than polar_complex. However, for field equations (including those from fluid dynamics, my area), using tools from complex analysis can create new, simpler formulations of problems in the complex plane. If the resulting mapping has a high order of circular symmetry, then polar_complex numbers have advantages. The most obvious use of polar_complex numbers would be in wave mechanics. The phase and magnitude are often weakly coupled; you can sometimes work with just one component in different parts of the calculations. At the lowest level, polar_complex numbers are best when the primary operations are multiplications/divisions and powers/roots. When you start adding/subtracting, then cartesian representations begin to win out (because of the cost of the trig functions). There's another advantage of polar_complex numbers that I didn't spell out separately: *development* efficiency, i.e. how quickly one can write an acceptable program for a simulation prototype or a quick-and-dirty calculation. Many problems (in fact, a majority of those I have worked with) are more naturally formulated in polar form; it's therefore easier to write a program that uses that representation. This is just the old programming adage "Think/write in the problem domain, not the language domain.". I'd address run-time efficiency later in those cases where it was a concern; I haven't yet seen any cases where the polar_complex representation was obviously inefficient. Hubert Holin wrote: > The main problems I foresee are in the commingling of the two >different classes. It is interesting to see a complex number (among >other ways) either as its two canonical coordinates, or in a polar >representation, but sometimes we just want to switch between the two for >a given instance. So I fear a substantial amount of typical run time >will be spent doing conversions. I defined explicit conversions to and from std::complex, but I used them fairly rarely. If the problem truly belongs in the polar representation, then you won't need many conversions. In fact, I wrote polar_complex in the first place in a case when I found myself very frequently calling abs, arg, and polar using std::complex -- the problem didn't belong in the cartesian representation. But you are right that the relation between them needs careful consideration; that was on my list of issues to address if I "boosted" it. > There is another, perhaps deeper, problem to consider, with the >representation of complex numbers (and others), as evidenced by a thread >on comp.std.c++ a couple of years back: layout guaranties. People >wanted, in essence, to be able to break encapsulation when it suited >them (for efficiency in time-critical code). The discussion also >encompassed thoughts about the polar representation (which, as you >remarked, also has advantages). As far as I know, there has been no >tangible result to that thread. > > In short, I am not sure a library for complex numbers in polar >form would be worthwhile, but I certainly think that if you could make >the above situation progress (as in: write a formal proposal), it would >be a great win for us all. Well, I needn't worry about polar_complex layout because there are no C or FORTRAN equivalents to be layout compatible with. :) Regarding std::complex, just about a month ago, I posted to comp.lang.c++.moderated about these very issues. The current status is in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1589.html The layout guarantee seems certain, and it lays out possible solutions for the second issue. I don't see much that I can add other than to give my recommendation on the solution and prod them to pick one already. I've already been doing both on clc++m; I suppose I could write Howard Hinnant directly, but he's responded to several threads so he's probably read most of my posts. This is becoming a digression, but my opinion, for what it's worth: std::complex should never have been encapsulated as it was in the first place. And to justify this, in addition to the efficiency issues, there is clarity of the code's intent. Consider: 1a) z = complex<double>(z.real(), 1); 2a) z.imag() = 1; 1b) z = complex<double>(z.real(), z.imag() + 1); 2b) z.imag() += 1; I think it's clearly much easier to read the intent of the code in the second cases. Matt Austern wrote: >But is it likely that you would want to use a package that provides >complex numbers in polar form? My experience is that if you're >working with complex numbers that you want to think of in the form >r exp(i phi), then you'll probably just do the work of separating out >the magnitude and phase ahead of time in your equations, and then >compute with them separately. After all: if you're doing something >where the magnitude-phase form is most convenient, it usually >means that putting numbers in that form makes the equations >simpler. True to a degree, though such separation is not always possible, especially in non-linear situations. And a similar argument is true for cartesian complex: if you're doing something where the real-imaginary form is most convenient, it also usually means that putting numbers in that form makes the equations simpler. But it's usually easier to keep track of, for instance, just vector< complex<double> > Numbers; than vector<double> NumbersReal; vector<double> NumbersImag; and there's usually no harm in combining them like that (unless of course complex is over-encapsulated, but I digress again. . .). Similarly, vector< polar_complex<double> > Wave; is simpler to deal with than vector<double> WaveAmplitude; vector<double> WaveMagnitude; so combine them if there's no harm in doing so. This is appealing to the "development efficiency" (and code clarity) argument I made above. > Still, from the discussion on comp.std.cpp a few years back, I >recall that there was a feeling that having multiple representations >(say cartesian and polar) at the same time would have been nice. Of >course, it would have been a bloated beast (at least in a naive >implementation), and a slow one at that (to keep track of the various >changes, in a naive implementation still). Furthermore it clashed with >the desire to have some layout guaranty which played nice with C (that >line of reasoning seems to have flown out in limbo, however). > > This illustration is merely there as a reminder that the wish for >concurrent multiple points of views of a given abstract entity is not a >futile one, if one that I fear can't be translated from mathematics to >CS. We've had another illustration of that recently with the affine >space/vector space discussion in a GUI thread a few days back here >(which also happens to be relevant to this discussion as well, at least >in two dimensions). Well now you are touching on an entirely separate point. For a mathematical primitive used in numerical work, making the same class hold different representations is a terrible idea. Pick the representation you need and stick with it, converting between representations only if/when you must. If you find yourself converting constantly, then you have picked the wrong algorithm or need another representation altogether. And how many representations should you implement in one class? Why cartesian and polar coordinates but not parabolic, elliptical, bipolar, etc.? ------------------------------------------------------------ Again, I appreciate all the comments, but the interest obviously isn't there for developing the class further. Thanks, Mickey Moore

7 6

regex and g++ 3.4.2 problem
by Maciej Sobczak 29 Nov '04

29 Nov '04

Hi, $ g++ --version g++ (GCC) 3.4.2 [FreeBSD] 20040728 (boost version 1.32) When compiling a very simple example for the regex library, I've got the following error: In file included from /usr/local/include/boost_1_32_0/boost/regex/v4/regex.hpp:99, from /usr/local/include/boost_1_32_0/boost/regex.hpp:34, from regex.cc:1: /usr/local/include/boost_1_32_0/boost/regex/v4/instances.hpp:71: error: ISO C++ forbids the use of `extern' on explicit instantiations *** Error code 1 A short investigation points to the following code in the instances.hpp file: #elif (defined(BOOST_MSVC) && defined(_MSC_EXTENSIONS)) || defined(__GNUC__) # ifndef BOOST_REGEX_INSTANTIATE # define template extern template // (*) # endif # ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660) # endif template class BOOST_REGEX_DECL reg_expression< BOOST_REGEX_CHAR_T >; IMHO (and rather guessing), the #define in (*) is performed unnecessarily for g++ 3.4.2, but is executed just because of too generic __GNUC__ a little bit higher. As a temporary solution, I have just uncommented the following line in boost/regex/user.hpp: #define BOOST_REGEX_NO_EXTERNAL_TEMPLATES Now the simple program compiles and works fine. What influence will the above change in user.hpp have on bigger programs? Is this a known problem? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

3 3

Gauging Interest: polar_complex
by Mickey Moore 29 Nov '04

29 Nov '04

I wanted to gauge whether there might be interest in a class for complex numbers with data stored in polar form. For some applications, polar complex numbers have significant advantages over Cartesian complex (e.g., std::complex) in efficiency and numerical accuracy. (I spent some time Googling and, somewhat to my surprise, didn't find any freely available versions of this.) I have a fairly well developed class that implements this; "boosting" it to be worthy of consideration would probably be straight-forward but non-trivial. My version of this is of course templated on the contained numeric type. It is also uses a policy-based design that determines whether or not the polar angle phi is always maintained in principal form or not and what constitutes principal form (default: no, -pi < phi <= pi). Thanks, Mickey Moore ---------------------------------------- Mitchell G. (Mickey) Moore, Ph.D. mgmoore(a)austin.rr.com

4 7

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 29 Nov '04

29 Nov '04

Thanks for the link. I'm not sure it applies though; the prog isn't spawning the threads simultaneously, so it shouldn't be taking many resources. I've found that even if I only have one thread spawned at one time (where the previous thread has died out before the new one is spawned) it still aborts at the same place. Over the holiday I pared my program down to just the thread spawning, and on my Mandrake setup at home it dies at the nice even (computer) number of 256 threads. The same pared-down prog dies on my work Fedora Core 3 machine at 405. Under Windows, it doesn't ever seem to die. I'm getting pretty convinced this is a bug in the boost library that manifests itself only under Linux, and not my code. Perhaps resources are not being properly released when the threads are dying out. Since the prog is pretty small, I'll include it here. It spawns a thread every second, and each thread only last one second. #include <iostream> #include <string> #include <stdlib.h> // for multithreading #include <boost/thread/mutex.hpp> #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/bind.hpp> int totalthreads = 0; boost::mutex io_mutex; // iostreams boost::mutex numthreads_mutex; // for changing value of numthreads boost::mutex threadid_mutex; // for manipulating thread_id using namespace std; void threadfunc() { // wait some secs boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread Exiting. " << std::endl; } } main() { boost::thread_group thrds; boost::xtime xt; int maxthreads=99999; // ******************************** // Main thread-spawning loop for (int i=0; i<=maxthreads; i++) { totalthreads++; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << "MAIN: Thread:" << totalthreads << " being spawned... " << std::endl; } thrds.create_thread( &threadfunc); // wait some seconds boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); } // end thread-spawning for loop thrds.join_all(); std::cout << "Done." << std::endl; } Here's the Makefile I build it with: lib = /usr/local/lib/libboost_thread-gcc-mt-1_32.so threadtest : threadtest.o g++ $(lib) $(lib2) -o threadtest threadtest.o -ldl -lc -lpthread threadtest.o : threadtest.cpp g++ -Wall threadtest.cpp -I/usr/local/include/boost-1_32 -pthread -c -w -O -o threadtest.o -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Friday, November 26, 2004 2:07 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? Tim Laplaca wrote: > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after > spawning 283 or so threads, it stops running and 'Aborted' is printed. Take a look at: http://www.kegel.com/c10k.html#threaded and check your sizes. -- Alexander Nasonov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Re: Another logo proposal
by Beman Dawes 29 Nov '04

29 Nov '04

At 01:11 PM 11/23/2004, Beman Dawes wrote: >At 06:18 PM 11/22/2004, Rich Johnson wrote: >> >>On Monday, November 22, 2004, at 04:02 PM, JOAQUIN LOPEZ MU?Z wrote: >> >>>> Is there a single color restriction for ease of printing? If not >>>> adding a third '+' in a different color (or perhaps in outline) >>>> would >>>> further emphasize building on C++. >>> >>> You mean, like the version attached? >>> I don't know, it kind of looks too irregularly shaped. Not >>> so blocky as the other designs. >>> >>> Joaquín M López Muñoz >>> Telefónica, Investigación y Desarrollo >>> <boost.gif> >> >>I was thinking more like: >> >> >> >> >> >>Which yields two steps up. I like that a bit. Is anyone keeping a list of the more likely candidates? --Beman

6 10

RE: [boost] Re: [ANN] Phoenix-2 Preview
by Eyal Farago 29 Nov '04

29 Nov '04

I'm not that familiar with phoenix (yet) but I think your implementation fails to handle const arguments. I think that the return type deduction mechanizm should first 'remove_cv' the argument type, then get the appropriate type from your existing metafunction, then 'add_const' if the argument was const and then 'add_reference'. (all of these can be easily done using boost::mpl and boost::type_traits libs). am I missing anything? maybe the framework does this for you? eyal. -----Original Message----- From: Reece Dunn [mailto:msclrhd@hotmail.com] Sent: Monday, November 29, 2004 2:06 PM To: boost(a)lists.boost.org Cc: spirit-general(a)lists.sourceforge.net; spirit-devel(a)lists.sourceforge.net Subject: [boost] Re: [ANN] Phoenix-2 Preview Joel wrote: > Reece Dunn wrote: >> I have written lazy veraions of pair.first and pair.second (see >> attachment). > > Nice! Seems like a beginning of a utility module. If you'd like > to submit it as part of the library, I'd need a test program. Done. Note that the libs/spirit/phoenix/test/Jamfile.v2 needs + # bring in rules for testing + import testing ; at the top to allow you to run bjam from that directory, otherwise it complains about 'run' being unrecognised. > I'd also > request conformance with the implied coding styles for the sake > of consistency. Done. > Many thanks! :) Regards, Reece

1 0

[repost][aligned_storage] problem for GCC 3.2 and proposed solution
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

Allow me to repost this, since seems it has gone thru the list indavertently. I'd be grateful if people with various versions of GCC can try the snippet so as to determine to which extent the problem shows. Original post follows: The following program: #include <boost/aligned_storage.hpp> struct foo { foo(int x){} private: boost::aligned_storage<sizeof(int)> a; }; int main() { foo f(5); return 0; } fails in GCC 3.2 20020927 with the error: /usr/local/boost_1_32_0/boost/aligned_storage.hpp: In function `int main()': /usr/local/boost_1_32_0/boost/aligned_storage.hpp:75: ` boost::aligned_storage<size_, alignment_>::aligned_storage(const boost::aligned_storage<size_, alignment_>&) [with unsigned int size_ = 4, unsigned int alignment_ = 0ffffffff]' is private Digging into aligned_storage.hpp, I find the following workaround: #if !BOOST_WORKAROUND(__GNUC__, <= 2) private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #else // gcc2.x public: // _should_ be noncopyable, but GCC compiler emits error aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #endif // gcc2.x workaround So, it seems like the problem was known but incorrectly assumed to affect GCC 2.x only. Anyone objects to extending the workaround to GCC 3.x? It remains to know whether this problem (that seems like an incorrect application of the copy ellision rules) persists in GCC 3.4.x, and in case it is fixed, which last version is for which we should have the workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Website MPL Docs.
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Thomas Witt <witt(a)acm.org> Fecha: Viernes, Noviembre 26, 2004 9:20 pm Asunto: [boost] Website MPL Docs. > > Maybe I am just going nuts but the mpl doc links on the website > seem to > be broken. > > http://www.boost.org/libs/libraries.htm > > contains a link to: > > http://www.boost.org/libs/mpl/doc/index.html > > This document seems to be outdated and all the > links in this document seem to be broken. > > The following url seems to point to the current docs > > http://www.boost.org/libs/mpl/doc > > I am lost > I think your browser cache is playing tricks on you. Everything looks OK from mine. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

[MPL] document autogeneration
by Cromwell Enage 29 Nov '04

29 Nov '04

Since the MPL docs are autogenerated using ReST, I'd like to know how to make the documentation for my own numeric constants conform to the new format. Access to the ReST sources themselves (even if they're only on mywikinet), accompanied by the steps needed to configure Docutils, would be best. TIA! Cromwell Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

DocBook local XSL stylesheets
by Edward Diener 29 Nov '04

29 Nov '04

It appears that the DocBook local XSL stylesheets at the DocBook SourceForge site only has a setup for Unix/Linux systems, not Windows. If this is the case, it should be mentioned in BoostBook documentation.

1 0

DocBook DTD distribution
by Edward Diener 29 Nov '04

29 Nov '04

In the DocBook documentation for Boost for configuring local XSL and DTD distributions it says that the DocBook DTD is at the OASIS DocBook site at http://www.oasis-open.org/docbook/xml/4.2/index.shtml . However clicking this link gets a Resource not found message on the Oasis web site. However using http://www.oasis-open.org/docbook/xml/4.2 works for me, and http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip is the actual zip file. Perhaps the document needs updating.

1 0

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Stefan Slapeta <stefan_nospam_(a)slapeta.com> Fecha: Domingo, Noviembre 28, 2004 11:25 pm Asunto: [boost] Re: Logos - Last Minute Change of Heart > JOAQUIN LOPEZ MU?Z wrote: > > > Anyway, I've just forged anoher idea. Not that I like > > it much, but the idea is a little different and might > > please some --sort of ++ breaking the barrier of sound > > or something. > > > > Sorry - blue and red don't harmonise! > Is it only the color you don't like, or also the rest? :) I mean, changing colors is easy enough, see attached example for instance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 28 Nov '04

28 Nov '04

----- Mensaje original ----- De: Peter Petrov <ppetrov(a)ppetrov.com> Fecha: Lunes, Noviembre 29, 2004 0:07 am Asunto: [boost] Re: Logos - Last Minute Change of Heart > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > > Why don't you try removing the distant parts of the circles > > > surrounding the + > > > signs (so that they look more like C's, rather than O's). > > > > > > > I think it's going to look clumsy, as the distants parts > > of the circles are mostly covered. In order to see something, > > the circles would have to be chopped way too much, roughly > > between 12:00 and 6:00, if you know what I mean. > > Mostly, but not completely. I played a little with your image and > removed them. > See the result, I think it looks better: > > http://www.ppetrov.com/temp/png00027pp.png > > Here is the original: > > http://www.ppetrov.com/temp/png00027.png > Umm... yes, I agree it looks cleaner. Would you mind changing it in the Wiki? As I said, I cannot do it myself. Thanx! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 28 Nov '04

28 Nov '04

Hi Jonathan ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Domingo, Noviembre 28, 2004 7:50 pm Asunto: [boost] Re: Logos - Last Minute Change of Heart > > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote in message > news:16080515fd9a.15fd9a160805@tid.es... > > > ----- Mensaje original ----- > De: Jonathan Turkanis <technews(a)kangaroologic.com> > Fecha: Sábado, Noviembre 27, 2004 10:03 pm > Asunto: [boost] Logos - Last Minute Change of Heart > > > > Dear All, > > > > > > Just as I was ready to add "logo" and "rocket" to my list of > > > messagefilters, I had a change of heart. Here are several sample > > > logos I designed > > > yesterday. > > > > > > > > >I like the first one. Simple and effective. > > Thanks. > > > Pleasefind attached a variaton of that based on my proposal > > --admittedly not as simple, but well, I though I'd > > drop it here to know people's opinions. > > I think seeing your design with the red, white and black color > scheme has helped > me figure out why I don't like it, despite its elegant > composition: it bears a > certain resemblance to a swastika. :( > Ouch! To me, it seems more like the Tetris game, but this connotation stuff is so tricky. Anyway, I've just forged anoher idea. Not that I like it much, but the idea is a little different and might please some --sort of ++ breaking the barrier of sound or something. BTW, I cannot edit the Boost Wiki, my usr or ip is blocked (??) I think it's gotta do with the fact I'm behind a corporate proxy. So, if some kind soul could upload this stuff for me I'd be eternally grateful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

Front page, new one..
by Daniel Wallin 28 Nov '04

28 Nov '04

Here's another one, wikipedia inspired. http://luabind.sourceforge.net/boost2.png -- Daniel Wallin

12 59

Compile problem with como-win32
by Brian Riis 28 Nov '04

28 Nov '04

Given: C:\src\workspace\boost>bjam "-sTOOLS=como-win32" "-sCOMO_BACKEND=dig" "-sCOMO_BACKEND_PATH=c:\dm" --with-python-root=c:\python24 stage I'd expect the build-process to start, using Digital Mars as backend. Boost.Jam tries to call c:\dm\..\Common7\Tools\vsvars32 and set COMO_MS_INCLUDE to c:\dm\include. Clearly it somehow thinks that it should setup for a VC7 backend, although it *does* correctly issue "como --dig ..." to compile. What's happening? -- /Brian Riis

2 1

Re: [boost] Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 28 Nov '04

28 Nov '04

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Sábado, Noviembre 27, 2004 10:03 pm Asunto: [boost] Logos - Last Minute Change of Heart > Dear All, > > Just as I was ready to add "logo" and "rocket" to my list of > messagefilters, I had a change of heart. Here are several sample > logos I designed > yesterday. > > I like the first one. Simple and effective. Please find attached a variaton of that based on my proposal --admittedly not as simple, but well, I though I'd drop it here to know people's opinions. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Alternate Logo Design
by Reid Sweatman 28 Nov '04

28 Nov '04

> -----Original Message----- > From: Reid Sweatman [mailto:drunkardswalk@earthlink.net] > Sent: Wednesday, November 24, 2004 2:33 PM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] Re: Logo... and page design. <all snipped> Just curious, and my feelings aren't hurt or anything, but did everyone really consider my idea so worthless as not to merit the time to dump on it? <g> Reattached in it's original, fine-minute quickie form here, in case the message is gone. Incidentally, my quick take on the ones I was able to view: the rocket ones were mostly really well done, but mostly way over-busy, as well. There was one that was sufficiently close to mine that they could likely be combined; might try that tonight. The Text ones were okay, but lifeless. The square braces didn't work for me, mostly, save for perhaps the one that formed a split-C (and someone had to point that out to me before I realized that was what it was). Reid

2 2

Merge of RC_1_32_0 with trunk?
by Joaquín Mª López Muñoz 28 Nov '04

28 Nov '04

Is this merge gonna happen soon? Any foreseeable problems if I begin evolving the trunk before that merge? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 7

Logo... and page design.
by Rene Rivera 28 Nov '04

28 Nov '04

Boosters, OK, I put together a new logo. I'm not going to say much about it because if I do it will likely skew perceptions. I will say that it comes in a variety of forms to accommodate the context: http://redshift-software.com/~grafik/boost/logo.htm Boost Logo And more changes to the front page: http://redshift-software.com/~grafik/boost/index.htm Boost C++ Libraries PS.. It looks like the logo page requires a conforming CSS1 browser :-\ So please use something other than IE ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

16 31

explicit-failures-markup question
by Bart 27 Nov '04

27 Nov '04

I see that wild-cards are supported for toolset names in explicit-failures-markup.xml. Are they also supported for test names? We have a series of tests that have similar names (testtime_serialize, testtime_serialize_xml, testtime_serialize_std_config). I'd like to use a wild-card to markup all three tests (testtime_serialize*). Will it work? Thanks, Bart

2 2

how to compile giallo?
by Roland Schwarz 27 Nov '04

27 Nov '04

I just wanted to study the giallo aka. boost_net library. Unfortunately so far I cannot manage to compile the lib. I checked out the sources from CVS. I am running W2K with vc-7_1. I set BOOST_ROOT, and invoked bjam -s"TOOLS=vc-7_1" --with-boost_net in giallo root. All I get, is a report of a number of targets, nothing else happens. Is the build assumed to work on Windows? Do I need a special dircetory layout? Any help appreciated! Roland

1 0

BOOST_NO_SFINAE not in docs
by Robert Ramey 27 Nov '04

27 Nov '04

in looking through some of the compiler config files, I find BOOST_NO_SFINAE. However, I don't find this in the config documentation. Is there a reason why it shouldn't be there? Robert Ramey

2 1

Re: [ANN] Phoenix-2 Preview
by Joel 27 Nov '04

27 Nov '04

Zhuo Qiang wrote: > > what about _a = var(arg1) which IMO is more explicit I considered that syntax too. Unecessarily verbose, IMO. The argN (like var(x)) already has reference semantics. That is why you can write: ++arg1 for example, instead of the more verbose: ++var(arg1). IMO, argN should always be implicitly an L-value, for consistency. >>>though the following code gives what I expect: >>> int i = 1; >>> >>> let(_a = val(_1)) >>> [ >>> cout << --_a << ' ' >>> ](i); >>> cout << i << endl; >> >>Exactly! args are L-values. vals are R-values. >> >>I'll emphasize that in the docs. Mind if I steal your example? > > > Sure! As you wish. Done :-) Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: [ANN] Phoenix-2 Preview
by Joel 27 Nov '04

27 Nov '04

Zhuo Qiang wrote: > I've just tried it and there's a question: > > int i = 1; > > let(_a = _1) > [ > cout << --_a << ' ' > ](i); > cout << i << endl; > > the output of above is : 0 0 > and I expected it to be "0 1" > seems _a hold a "reference" to _1 which in turn is just a reference of i.Is > it right? > I thought _a = _1 had some value semantic. That's right. That's the correct behavior. As noted in the docs: The type of the local variable assumes the type of the lambda-expression. Type deduction is reference preserving. For example: let(_a = arg1, _b = 456) _a assumes the type of arg1: a reference to an argument, while _b has type int. This is necessary because otherwise, we won't have l-value access to outer lambda-scopes. > though the following code gives what I expect: > int i = 1; > > let(_a = val(_1)) > [ > cout << --_a << ' ' > ](i); > cout << i << endl; Exactly! args are L-values. vals are R-values. I'll emphasize that in the docs. Mind if I steal your example? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: [boost] Alternate Boost Logo
by Beman Dawes 27 Nov '04

27 Nov '04

At 08:03 PM 11/26/2004, Reid Sweatman wrote: >This time with the file actually attached. <g> It was a long, drunken >weekend... I guess I'm just a person who thinks in terms of words rather than images. As images go your suggestion is fine, but I like the ones that have the word "Boost" in them. At least for some of the logos posted so far, I usually like "C++" being there too. --Beman

1 0

Alternate Boost Logo
by Reid Sweatman 27 Nov '04

27 Nov '04

> -----Original Message----- > From: Reid Sweatman [mailto:drunkardswalk@earthlink.net] > Sent: Wednesday, November 24, 2004 2:33 PM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] Re: Logo... and page design. <all snipped> This time with the file actually attached. <g> It was a long, drunken weekend... Just curious, and my feelings aren't hurt or anything, but did everyone really consider my idea so worthless as not to merit the time to dump on it? <g> Reattached in it's original, fine-minute quickie form here, in case the message is gone. Incidentally, my quick take on the ones I was able to view: the rocket ones were mostly really well done, but mostly way over-busy, as well. There was one that was sufficiently close to mine that they could likely be combined; might try that tonight. The Text ones were okay, but lifeless. The square braces didn't work for me, mostly, save for perhaps the one that formed a split-C (and someone had to point that out to me before I realized that was what it was). Reid

1 0

CW version 0x3004?
by Stefan Slapeta 26 Nov '04

26 Nov '04

Has anyone ever seen CW defining the version to 0x3004? Seems it's not handled by boost.config at the moment and boost.bind doesn't compile, either. Stefan

2 2

Re: [boost] Re: Boost Sandbox layout?
by Roland Schwarz 26 Nov '04

26 Nov '04

Michael Walter wrote: >Hm yeah I know of these, I thought those more resembled hard links. Hmm. > > > I would say: neither nor. They are implemented at the filesystem driver, so they are similar to an hardlink, but they can span devices, so they are similar to a symlink. Also you can only link directories, and not files. Roland

3 3

[named_params] Metafunction for extracting parameter types.
by Cromwell Enage 26 Nov '04

26 Nov '04

In the course of refactoring my multi-state mazes library to use Boost.NamedParams, I discovered that I couldn't create a default predecessor map without the proper vertex type, and I couldn't get that type without knowing the type of the input graph. So I went ahead and created a metafunction called find_named_param that helped me to accomplish this task. For example, you have the following tag types for your key words: struct input_graph_t; struct input_index_map_t; ... Then in your function, you can extract your types like so: typedef typename find_named_param< Params , input_graph_t >::type InputGraph; typedef typename find_named_param< Params , input_index_map_t , property_map< InputGraph , vertex_index_t > >::type InputIndexMap; Thus, given the following keywords: keyword<input_graph_t> input_graph; keyword<input_index_map_t> input_index_map; Assignment becomes less tedious: InputGraph& in_g = p[input_graph]; InputIndexMap index_map = p[ input_index_map | get(vertex_index_t(), in_g) ]; The third template parameter in find_named_param is the type whose member typedef ::type will be returned if the named parameter is unspecified. Of course, leaving this template parameter unspecified will result in a compile-time error if the function requires the named parameter. The corresponding argument type should be the same as (or assignment-compatible with) the type of the default value of the named parameter. The changes made to <boost/named_params.hpp>, in addition to effectively removing the dependency on BOOST_MPL_LIMIT_METAFUNCTION_ARITY, now include moving typedef H head_type; typedef T tail_type; out of the conditional macro body while remaining in detail::list, and adding the necessary functionality to make find_named_param work. I wouldn't call it sufficiently tested; however, the attached program works under MinGW (GCC 3.2) and MSVC 7.1. Happy Thanksgiving! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Website MPL Docs.
by Thomas Witt 26 Nov '04

26 Nov '04

Maybe I am just going nuts but the mpl doc links on the website seem to be broken. http://www.boost.org/libs/libraries.htm contains a link to: http://www.boost.org/libs/mpl/doc/index.html This document seems to be outdated and all the links in this document seem to be broken. The following url seems to point to the current docs http://www.boost.org/libs/mpl/doc I am lost Thomas -- Thomas Witt witt(a)acm.org

1 0

Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 26 Nov '04

26 Nov '04

I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after spawning 283 or so threads, it stops running and 'Aborted' is printed. It doesn't matter if I spawn them one after each other, or only 10 at a time, or if the threads only last 1 second or if they all stick around until the 283rd thread is spawned. Every combination I've tried results in the prog aborting at about the 283rd thread spawn. Does this sound familiar to anybody? Is there something my thread must do to properly shut itself down? Does it need to call some kind of procedure to announce it is going away for proper cleanup? I couldn't see anything in the examples like that. And is there documentation explaining the examples? I failed to find any. My thread procedure: void updatethread(void* inparams) { thread_params *tparam; tparam=(thread_params *)inparams; int local_threadid = tparam->param1; std::string DID = tparam->param2; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " running. " "UPDATE for " << DID << std::endl; } // wait some secs (just for debug, remove when real work is being done) boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 2; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " Exiting. " << std::endl; } { boost::mutex::scoped_lock scoped_lock(numthreads_mutex); --activethreads; } } MAIN calls it with this: //spawn thread tparam.param1=threadid; tparam.param2=dids[i]; boost::thread *pt; pt = thrds.create_thread(thread_adapter(&updatethread, (void*)&tparam)); Thanks, Tim

3 2

[aligned_storage] problem for GCC 3.2 and proposed solution
by Joaquín Mª López Muñoz 26 Nov '04

26 Nov '04

The following program: #include <boost/aligned_storage.hpp> struct foo { foo(int x){} private: boost::aligned_storage<sizeof(int)> a; }; int main() { foo f(5); return 0; } fails in GCC 3.2 20020927 with the error: /usr/local/boost_1_32_0/boost/aligned_storage.hpp: In function `int main()': /usr/local/boost_1_32_0/boost/aligned_storage.hpp:75: ` boost::aligned_storage<size_, alignment_>::aligned_storage(const boost::aligned_storage<size_, alignment_>&) [with unsigned int size_ = 4, unsigned int alignment_ = 0ffffffff]' is private Digging into aligned_storage.hpp, I find the following workaround: #if !BOOST_WORKAROUND(__GNUC__, <= 2) private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #else // gcc2.x public: // _should_ be noncopyable, but GCC compiler emits error aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #endif // gcc2.x workaround So, it seems like the problem was known but incorrectly assumed to affect GCC 2.x only. Anyone objects to extending the workaround to GCC 3.x? It remains to know whether this problem (that seems like an incorrect application of the copy ellision rules) persists in GCC 3.4.x, and in case it is fixed, which last version is for which we should have the workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

date_time from HEAD
by Victor A. Wagner Jr. 26 Nov '04

26 Nov '04

I've gone back to running regression tests from CVS HEAD, but the results don't seem to be displayed anywhere online. I've discovered in compiling my own programs, that there appears to be me a missing #include <boost/shared_ptr> missing from time_clock.hpp (also microsocond_time_clock.hpp?? .. I don't use it so I cannot tell) Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[patch] Fix for Boost.Test (bad XML format)
by Ferdinand Prantl 26 Nov '04

26 Nov '04

Hello, here we are yet another one fix for Boost.Test. Ending tangs of TestCase and TestSuite were accidentally extended with a dangling attribute value, e.g.: </TestSuite="UnicodeTest"> The fix for supplied_log_formatters.cpp is attached and it's quite clear. Apparently my former fixes did no get into 1.32; they help only HP compiler anyway, and maybe only the version I use. This one is more serious ;-) F. -----Original Message----- From: Ferdinand Prantl Sent: Friday, November 05, 2004 12:35 To: boost(a)lists.boost.org Subject: Compile fix for Boost.Test for aCC on HP-UX Hello, you can find a small fix for boost/test/detail/basic_cstring/basic_cstring.hpp attached and a dirty workaround for a compiler bug in aCC for boost/test/unit_test_suite.hpp. As of the latter; the compiler seems to get confused by equal names in different namespaces and classes; renaming Impl helps or making the previous structure friend helps too (this I chose to minimize the change). Ferda HP-UX B.11.11 U 9000/800 aCC: HP ANSI C++ B3910B A.03.37 <<basic_cstring.hpp.diff>>

1 0

Re: Boost Sandbox layout?
by Rene Rivera 26 Nov '04

26 Nov '04

Any comments on this from the Boost Sandbox admins, or anyone? -------- Original Message -------- Subject: Re: Boost Sandbox layout? Date: Wed, 17 Nov 2004 18:41:58 -0600 David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: > >>Was there ever a discussion as to the layout? (A cursory search did >>not reveal anything) > > I like what I _think_ you're suggesting we actually should do, but > would you mind spelling it out for everyone's benefit? I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-) I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself. For example I'm putting together the warnings submission and it would be nice to set it up like this: /boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks: 1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone. 2) An eventual long list of directories right at the top. One advantage is the reduce complexity of management by the library authors. As it would be much easier to do things like remove a library from the sandbox after it's been accepted into Boost, a single recursive cvs remove and commit instead of finding all the files and dirs. It might even be possible to setup some form of script automation to make snapshots of the individual libraries automatically available (without CVS access). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

5 7

[fsm] Adapted to 1.32
by Andreas Huber 25 Nov '04

25 Nov '04

Dear Boosters The fsm submission has been adapted to the 1.32 release. The zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm Feedback is highly welcome! Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

interest in a type_iterator (cast_iterator) ?
by troy d. straszheim 25 Nov '04

25 Nov '04

I'm wondering if there is any interest in a "type_iterator", built on top of the iterator_adaptor. If so I'll send it out. It is a kind of combination of transform_iterator and filter_iterator, where the transform is a cast, and the filter predicate is whether or not each entry in the container passes the cast. This you would want to do when iterating over heterogenous containers (where you are forced to reconstruct type information by downcasting) or containers of boost::any. I was going to call it downcast_iterator but the boost::any stuff isn't a downcast, so I came up with type_iterator. Maybe cast_iterator is better? Generally it looks like this type_iterator<TypeThatIWant, UnderlyingIterator> Here's an example: struct Base { virtual ~Base() {} }; struct Derived : public Base { virtual ~Derived(){}; virtual void OnlyDerivedHasThis(){} }; vector<Base*> v; // love boost::assign v += new Base, new Derived, new Base, ... etc. type_iterator<Derived,vector<Base*>::iterator> iter = make_type_iterator<Derived>(v.begin(), v.end()); while (iter.base() != iter.end()) { (*iter)->OnlyDerivedHasThis(); ++iter; } In order to cooperate with associative containers, containers of shared_ptr's and so forth, the type_iterator maps the type of the underlying iterator (and the cast used) like this: underlying iterator's type_iterator's cast reference_type reference_type ----------------------------------------------------------------------------- Base*& Derived*& dynamic_cast<> shared_ptr<Base>& shared_ptr<Derived>& dynamic_pointer_cast<> any& Derived*& any_cast<> pair<T,Base*>& pair<T,Derived*>& dynamic_cast<> pair<T,shared_ptr<Base> >& pair<T,shared_ptr<Derived> >& dynamic_pointer_cast<> pair<T,any>& pair<T,Derived*>& any_cast<> For instance: type_iterator< Derived, std::map<string,shared_ptr<Base> > > iter; *iter <= returns type pair<string,shared_ptr<Derived> >& I'm sure there are things that need changing, (for instance, should the "any" map to Derived* or just Derived? Should it incorporate the behavior of indirect_iterator and do an extra dereference? Dunno.) I'm just wondering if there is interest before I generalize too far beyond what my client needs. DISCLAIMER: it's widely believed that the need to iterate like this (or the need to downcast at all) indicates a lousy inheritance hierarchy and that in these cases the desire to downcast should be removed via improving the base classes. I hope I don't provoke any lectures on the evils of downcasting: this iterator is not intended to substitute for good class design... cheers, troy d. straszheim

1 0

Boost Shmem-Shared memory library first archive available
by Ion Gaztañaga 25 Nov '04

25 Nov '04

Hello to all, As promised two weeks ago, I have a first rough version of shared memory library in Yahoo Files. I've renamed and reenginered the classes from my STL in shared memory article and boostified almost all parts. The file is in: http://groups.yahoo.com/group/boost/files/boost.shmem.zip Shared memory mutex interface is taken from Boost Threads and scoped locks are needed to lock the mutexes. Since thread scoped locks can't be used from single threaded processes due to header checks, I've cloned them in Boost Shmem, but I would want to reuse thread locks if this library goes on. The offset smart pointer takes much of its interface from boost smart pointers. Boost config is used to build the different dll versions with auto-link and some boost utilities are used (noncopyable for example). This version uses templatized shared memory front-end so that a new shared memory management allocation can be used without changing existing code. In general, I've tried to all that I think it was necessary to adapt to boost, although surely there are many flaws here. The boost shmem jamfile builds for VC-7_1 in WinXP and gcc 3.4.1 in Mandrake 10.1. I've put several test and example files, although my poor jam knowledge makes that tests can only be build for windows using bjam (i don't know how to pass -l link specific options when building in linux to link with librt.a, sorry). Under proj directory there are some VC .NET IDE files to build the library, examples and tests and also a Makefile to build all under linux). I've also documented almost all files using doxygen style and the reference can be build using bjam --v2. If this library goes on, I plan to build a complete boostbook, since I've been reading all the documentation from boost utils. For now, there is a single page help as a tutorial/internal explanation. I would to know if those people that saw the library idea as interesting need any more features for this first version. Francis Andre needs some more sofisticated options and I would like to work with him for a more elaborated version if this library is accepted for boost. Francis suggested compatibility with boost.serialization and I would need some help with that. For this first and surely far from acceptable version I would like receive any comment you like regarding dessign, interface, etc... Help with bjam for building all correctly will be appreciated. I've put some attention in exception handling but surely there will be some problems due to my lack of experience in this area. If anyone wants to colaborate in any aspect of this library, please let me know, I'm totally open for this. Regards, Ion Gaztañaga

3 2

[signals] Replacing a connected slot
by Jody Hagins 25 Nov '04

25 Nov '04

I have a class that needs to react to a particular signal. However, the manner in which it handles the signal is state dependent. I would, therefore, like to change the connected slot when necessary. In general, this is not a problem. However, changing the connection inside another slot is problematic. For example, assume that Foo::bar() is already connected to signal_, and signal_() is called... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.disconnect(); current_connection_ = signal_.connect( boost::bind(&Foo::bar1, this)); } void Foo:: bar1() { std::cout << "Foo::bar1()\n"; } What I want to happen is that bar() will be called, then it will be disconnected, and bar1 will then be connected in its place. For example, given this calling sequence... signal_(); signal_(); I expect to see... Foo::bar() Foo::bar1() However, sometimes I may see... Foo::bar() Foo::bar1() Foo::bar1() because bar1() MAY get connected AFTER the place where bar() used to be connected, resulting in it also being called for the same signal invocation. What I think I want is a way to "replace" a connected slot, without disturbing anything else... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.replace_slot(&Foo::bar1, this); } This is especially important if the slot is originally connected with... signal_.connect( invocation_level, boost::bind(&Foo::bar1, this)); because I see no way to retrieve the ordering information from the connection. In any event, how do you suggest I "replace" a conected slot, while still guaranteeing that the "connection" is invoked exactly once? Thanks!!!

2 3

Re: Boost Shmem-Shared memory library first archiveavailable
by ION_G_M 25 Nov '04

25 Nov '04

Thank you Pavel for your comments, I would like to comment on some things >1. The HTML documentation does't allow to change font in browser. >2. End of document can be marked so it doesn't > look like cut in half during transmission. >3. docs 3.2: Sorry for errors and bad html. It was generated from MS Word so I will try to rewrite it using plan html. I'll change that shortly. >4. Example in 3.2: the "alignement" parameter in > segment.create() isn't found in code. I can't find the error you mention, I've just downloaded the zip file and 3.2 does not have any example. In 4.2 segment.create is missing a ",". >5. Example in 4.2: > segment.named_new<MyType> > ("MyType instance", /*name of the object*/ > 10 /*number of elements*/, > false /*if previously present, return error*/, > 0 /*ctor first argument*/, > 0 /*ctor second argument*/); a.It returns false. Exceptions are used only to indicate memory errors throwing bad_alloc. You are right there is info missing here. I will add more documentation in examples. b.If you find this approach more useful, I have no problem. I really don't like the boolean parameter, but I wanted to have a "find or create" functionality. If you like a find_or_named_new<>() additional function to indicate that approach I find it more clear than with a boolean parameters. c.The syntax you propose is better, no doubt. I don't have experience with it so to implement this I suppose named_new<> should return an proxy object with overloaded operator()() functions. Is that right? If you want to help me I'm open. If boosters prefer throwing exceptions instead or returning false no problem here. A problem I see is that my interface allows creating an array like new[]. Do you consider this necessary? You prefer a different function? Maybe the proxy object should have an operator[] that can be used to specify array allocation? > std::pair< MyType *, std::size_t> res = > segment.find_named_new< MyType > ("MyType instance"); >Why do I need the "size"? Doesn't a type have >always the same size regardless? Size contains the number of elements in case you allocate an array. with segment.named_new<MyType> ("MyType instance", /*name of the object*/ 10 /*number of elements*/, ... you allocate an array of 10 elements. so it will return 10. >6. Could you use namespace shmem_detail or so > instead of "detal" to avoid possible clashes? No problem. I've seen detail namespace in some projects so I thought it was not a problem. detail namespace is inside boost::shmem namespace so it wouldn't be necessary. You find it necessary even if detail namespace is really boost::shmem::detail? >7. exceptions.hpp: >a) file name should be shmem_exceptions.hpp or so No problem >b) does it make sense to have common base > for both exceptions there? My exception handling experience is null, so I based all in thread exception examples, where lock_error inherits from thread_exception. No problem changing this is you find it necessary. >8. offset_ptr.hpp: full_offset_ptr class >a) using char as de-facto bool class has usually > no practical advantage and may be actually slowe. No problem. You are right, with all platforms using 4 byte alignment bool and char use the same space and it can be slower I suppose due to mask operations. >b) The flag could be eliminated completely. > If m_offset == 0 it is NULL pointer and > no data allocated in shmem will starts > on the beginning. This would also eliminate > need for min_offset_ptr. The offset indicates the distance between the pointee and the this pointer of offset_ptr, so m_offset == 0 indicates a pointer pointing to itself and this is quite common in STL containers when empty, since next pointer in the end node points to end node, resulting in a m_offset = 0. Obviously this is different from a null pointer. If I change the meaning of m_offset to offset from the beginning of the segment I need the base address stored somewhere (and the base address is different in each process), so that I can convert from offset_ptr<A> to A* using get() or the constructor. Using my approach I can convert between A* and offset_ptr<A> without any additional data. Obviously, your approach is more performance friendly since m_offset does not need to be changed with each assignment and constructor. If boost people find the additional member as a waste comparing to A* <-> offset_ptr<A> conversions I would change it but I find my approach quite useful, since I don't want to deal with base addresses stored somewhere for each process when building a offset_ptr. >c) swap() could be added and other operators. Ok. I will add it. Which other operator you miss? >9. Maybe the protection of mutext from shared ptr > lib could be worked around I don't understand your point. Could you give me an example please? >10. The example in 4.3 uses very dirty C-like > approach with casts. Cannot it be rewritten > in C++ way with overloaded new? If you refer to (list_node*)segment.allocate(...) line, segment in this case is a low-level void* returning function. If you prefer an allocate<Type> approach, I don't have any problem, but remember that this segment object is of type shmem_alloc which allocs raw memory, something like when writing your own void* operator new(size_t size) for a class. If you have I workaround in mind, please let me know. >11. Some source files use Unix line ends, > some DOS line ends. Just bit strange. It's because I've tested and changed things in both windows and linux. I'll try to convert all to a common line feed. >12. The simple algorithm to find fitting memory > block may not be adequate for high-performance > apps (who are most likely to use shared > memory). You are right. The default algorithm is space-friendly, which I thought it was more important than performance for fixed size segments. You can write your own algorithm and use it since shmem_alloc is a typedef of basic_shmem_alloc<default_algo>. If you prefer another algo like segregated lists, I can try to write it, so that the user can choose the allocation algorithm. I've written the pooled allocator due to default algorithm slowness. >13. Can be be possible to identify named objects > with something else than C string? Say > wchar_t* or numeral or other templated type? Well, I've chosen a c string as an universal name, but other types could be used. Do you think that the key type should be templatized? I think that an integer key can speed up a lot searches but I have to think about which classes should be templatized. When storing other type of strings (for example std::string, I would need to build an allocator for strings in shared memory but also a std::string since it's probable that current STL won't work with Shemem STL allocator). The key meaning would be different since right now, I copy the string to shared memory but with configurable key type things are more complicated. >14. What I would like to see: >a) avoiding shmem specific containers/mutexes/etc > as much as possible. I think you can't avoid mutexes if you want to guarantee atomic memory allocation, since I have no skills to write a lock-free memory allocator. Regarding to containers, it was no my intention to write them, but I needed some of them to store name-buffer mappings and a node container to test the pooled allocator in several systems. For now, I have only succeed using shmem STL allocators in a modified Dinkum STL. STLport and libstc++ use suppose allocator::pointer to be a raw pointer, so I can't use STL containers. I've chosen internal containers to be public because I find them very useful, but if this is not accepted they can be used only for internal uses and removed from documentation. Regarding mutexes and etc... can you be more explicit? I propose mutexes to be general. If boost want to implement process-shared mutexes in other way, say in another library, I would use them, but for the moment, this is all that I have. >b) ability to "equalize" shared memory features I would need some help in this because my operating system knowledge is very limited. Mimic-ing UNIX way in windows can be very difficult, I think, unless you use a mapped file. I would need some serious help here. >c) support for inheritance in shmem using object > factories, e.g. like one in Classloader > http://s11n.net/papers/classloading_cpp.html I'll check it. Thanks for the url. >d) support for "transactions": I would like to My knowledge in transaction world is null so I can't help you with that. I suppose that a shared memory condition variable should be very interesting to notify events to other processes, but I'm afraid this is a work for more skilled programmers than me (people from boost::threads, perhaps?). As far as I know in windows is difficult to implement a shared memory condition variable, pthreads-win32 does no support it and I don't know how cygwin solves this. Thank you again for all your comments. I would like to make some changes you've suggested, so I will wait your response regarding open issues and comments from other boosters before doing any change. Regards, Ion

3 4

[iostreams(jonathan)] - using with 1.32
by Jeff Flinn 24 Nov '04

24 Nov '04

Jonathan, Do you have a version that works with the 1.32 release? If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp. I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient? I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp . Is this sufficient? I've got some other compile errors but I'm not sure if they are just downstream errors caused by these issues. Thanks, Jeff

3 7

RE: [boost] preprocessor fix
by Arias Brent-P96059 24 Nov '04

24 Nov '04

I can't allow the boost mailing to pour into my work account over the holidays, so I'm unsubscribing. However, I'd like to continue our conversation - I guess offline if thats ok. I'll want to ask about updates to Besser's printable enum for starters. My e-mail is panoply(a)att.net By the way, what other portions of Boost have you contributed to besides preprocessor programming? Remember, I will have already unsubscribed before you can respond to this letter - so if you respond, please respond to the e-mail I provided. Thanks, -Brent -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Paul Mensonides Sent: Tuesday, November 23, 2004 6:53 PM To: boost(a)lists.boost.org Subject: RE: [boost] preprocessor fix > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Arias Brent-P96059 > > Have you seen > http://www.cuj.com/documents/s=8470/cujboost0306besser/? > > > Yes, I have seen that before. I did not use it for several > reasons: (1) I think the source for Besser's ENUM was not > easily available, (2) my employer gets nervous when code > "looks" too C++ oriented and gets nervous when macros become > too "involved" - which means "lengthy" (3) Besser's ENUMX > macro requires that you specify the number of parameters > (e.g. ENUM3 or ENUM23). I believe that he got rid of that (really annoying) issue. At first, that code was written more like the pp-lib itself is written--repetition of macros. That almost defeats the purpose of using the pp-lib at all. The pp-lib's strength is that it provides basic interfaces that enable you to build more complex interfaces or solutions. That basic interface provides, among other things, an abstraction layer over manual repetition of macros--so clients don't have to do it. Later on, I think that the code changed to using sequences. > Reason #3 was a real hurdle for me - because I'm trying to > provide this macro to other developers who might "rebel" if > using the macro requires from them non-intuitive new concepts > or exercises. That is, if they didn't have to count the > number of parameters in the enumeration before - they may > well reject the ENUM macro if it starts to require them to > count the entries. I definitely understand that. > So, I set out to make an ENUM macro that (1) didn't need its > entries counted by the developer and (2) had a short > definition (which makes it less daunting for "managment" buy-in). I understand that as well. :( > You said: > > >there are still basic notions of computation, etc., such as control > >flow--which is nothing but a conditional "invocation" > >of its accompanying code. Those kinds of things still apply at the > >preprocessor level. What you really needed was a way to > conditionally > >enumerate some sequence elements, not enumerate a > conditional sequence. > > My implementation was "backwards" because I was unable to > make the code compile otherwise. That is, depending on the > value of ENUMS, the following code did not compile: Sorry, I'm getting way too used to variadics. If SEQ_ENUM generates more than one comma-separated element, then the comma will interfere with the internals of EXPR_IIF. E.g. #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define EXPR_IIF(bit, expr) PRIMITIVE_CAT(EXPR_IIF_, bit)(expr) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr #define COMMA() , EXPR_IIF(0, a COMMA() b) EXPR_IIF(1, a COMMA() b) Both of these invocations will (i.e. "should") fail. For 'expr', EXPR_IIF gets the argument "a COMMA() b". That is fine because it is a single argument. However, macro arguments (by default) are expanded _before_ they replace the formal parameter instances in the replacement list. The argument "a COMMA() b" expands to "a , b". With that, the expansion procedes as follows: EXPR_IIF(0, a COMMA() b) 0 -> 0 a COMMA() b -> a , b -> PRIMITIVE_CAT(EXPR_IIF_, 0)(a , b) -> EXPR_IIF_0(a , b) // error: too many arguments The same thing occurs if 'bit' is 1, and that is what is occuring with EXPR_IIF and SEQ_ENUM. BTW, an argument that expands to include open commas (i.e. it becomes more than one argument when passed again) is called (by me) an "intermediate". Dealing with intermediates is one of the major reasons why the pp-lib source is as hacked up as it is because many preprocessors don't do the expansion order correctly. Using intermediates requires that a single argument become some known number of arguments at a fairly particular time. BTW2, for anyone that may be interested, placemarkers (which is, in essence, C99 uses to deal with empty arguments) can be used to prevent argument expansion pretty much indefinitely. E.g. #define A(x) B(x) #define B(x) C(x) #define C(x) D(x) #define D(x) x A(x) Here 'x' gets scanned for macro expansion once on entry to A, once on entry to B, once on entry to C, once on entry to D, and once again during the rescan of D's replacement list. It gets scanned for macro expansion a total of five times. However, #define A(p, x) B(, p ## x) #define B(p, x) C(, p ## x) #define C(p, x) D(, p ## x) #define D(p, x) p ## x A(, x) Here 'x' gets scanned once--during the rescan of D's replacement list. (You can't get rid of that one.) The point of this is optimization. Scanning preprocessing tokens for expansion can become expensive (especially when the scan is a no-op--which the preprocessor cannot assume). For example, the following code... #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) x ...has more computational power than the pp-lib. The 'x' argument gets scanned 260 times. If there was nine macros (instead of four), the scan count is in the millions. With thirteen, the scan count is in the billions. It is a sum of powers plus one scan on entry to A. If 'n' is the number of macros, and 'b' is the parametric base (i.e. the number or "M(M(M(M(M(M(..." in the replacement lists), then the scan count is 1 + the summation from k=0 to n-1 of b^k -- which can be rewritten as 1+(1-b^n)/(1 - b). [If anyone actually wants to see this in action, try this on a compliant preprocessor (such as gcc)... // file.c #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define SPLIT(i, im) PRIMITIVE_CAT(SPLIT_, i)(im) #define SPLIT_0(a, b) a #define SPLIT_1(a, b) b #define IS_NULLARY(x) \ SPLIT(0, CAT(IS_NULLARY_R_, IS_NULLARY_C x)) \ /**/ #define IS_NULLARY_C() 1 #define IS_NULLARY_R_1 1, ~ #define IS_NULLARY_R_IS_NULLARY_C 0, ~ #define EMPTY() #define EAT(x) #define IIF(bit) PRIMITIVE_CAT(IIF_, bit) #define IIF_0(t, f) f #define IIF_1(t, f) t #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) E(E(E(E(E(E(x)))))) #define E(x) x #define KILL(x) x #define IS_ALIVE() IS_NULLARY(KILL(())) #define TEXT(t) \ IIF(IS_ALIVE())(TEXT_A, EAT)(t) \ /**/ #define TEXT_A(t) t TEXT_B EMPTY()()(t) #define TEXT_B() TEXT KILL( A( TEXT( Boost ) ) ) gcc --pedantic -x c++ -std=c++98 -E -P file.c ...this generates 'Boost' more than 1500 times. A word of warning: don't actually do this in real code, especially with something that generates lots and lots of scans because even though 't' (called, by me, an "active argument") eventually stops expanding (referred to, by me, as "reaching a terminal state") the preprocessor still performs the scans (etc.)--even though the scans might be no-ops. Scanning, for example, the single preprocessing token + billions of times (and the invocations required to generate those scans) is no small operation--in fact, it takes a *really* *really* *really* long time to generate a single + if you don't run out of memory first (which you probably will).] Obviously, scanning itself can become expensive. It is interesting that the most important benefit of placemarkers may well be that it provides a means to prevent argument expansion rather than providing the means to pass empty arguments (which is also very useful). > > #define ENUM(name, start, entries) \ > > BOOST_PP_EXPR_IIF(ENUMS)( \ > > BOOST_PP_SEQ_ENUM( \ > > (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ > > BOOST_PP_SEQ_TAIL(entries) \ > > (LAST_ ## name } name;) \ > > ) \ > > ) \ > You said: > > >You can do it, but EXPR_IIF does not lazily evaluate its > argument (the > >syntax above is what EXPR_IIF would look like if it *did* lazily > >evaluate it argument). > >In other words, when ENUMS is 0, SEQ_ENUM will still be invoked, but > >its results will be discarded. > > I'm not sure what you are suggesting. Depending on the value > of ENUMS, the code snippet I showed above would not compile - > lazy evaluation or not. If it won't compile, then there's > nothing for me to ponder (except to use a different approach > - which happily you taught me with the TUPLE_EAT macro). :) Apologies. I was thinking about EXPR_IIF with variadics. With variadics, you can, ala: #define EXPR_IIF(bit, ...) PRIMITIVE_CAT(EXPR_IIF_, bit)(__VA_ARGS__) #define EXPR_IIF_0(...) #define EXPR_IIF_1(...) __VA_ARGS__ E.g. here the number of arguments doesn't matter. If, on the other hand, EXPR_IIF did lazy evaluation, then you can still do it without variadics: #define EXPR_IIF(bit) PRIMITIVE_CAT(EXPR_IIF_, bit) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr syntax: EXPR_IIF(bit)(expr) Here, 'expr' doesn't get expanded at all if 'bit' is 0. The side-effect of lazy evaluation is that the argument is not passed on (internally) to another macro, which means that the situation that occurs in the pp-lib-style EXPR_IIF (the first one above) cannot occur. I could redesign EXPR_IIF (etc.) using the "EXPR_IIF(bit)(expr)" form. That would allow the code to work. I still couldn't guarantee lazy evaluation, of course, because preprocessors are terrible in general. However, if I do so, I open an encapsulation hole in the workarounds for various preprocessors. Granted, there are many of those already--the pp-lib cannot actually "fix" broken preprocessors after all--but client exposure is minimized. Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: Merge of RC_1_32_0 with trunk?
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Miércoles, Noviembre 24, 2004 6:00 pm Asunto: Re: [boost] Re: Merge of RC_1_32_0 with trunk? > Joaquín Mª López Muñoz writes: > > OK. A note of warning, though: during the last days before the > release,> Aleksey commited some changes to the docs directly in > the branch. These > > changes affect: > > > > 1. The main page (portions of the release notes) > > 2. The MPL docs > > 3. Boost.MultiIndex (some docs pages) > > 4. Other libraries? > > > > I'm sure Aleksey'll take care of 1 and 2, > > I'm going to take care of everything. > Oh, I'm afraid I've already done the job for multi_index :( So, you can safely skip that library. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 24 Nov '04

24 Nov '04

1.32 didn't make a difference. Thanks for the suggestion though. -----Original Message----- From: Tim Laplaca Sent: Wednesday, November 24, 2004 12:39 PM To: 'boost(a)lists.boost.org' Subject: RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? I think I'm on 1.31, so I'll give 1.32 a try. Thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, November 24, 2004 10:09 AM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca(a)voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com... > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and > after > spawning 283 or so threads, it stops running and 'Aborted' is > printed. > > It doesn't matter if I spawn them one after each other, or only 10 > at a > time, or if the threads only last 1 second or if they all stick > around > until the 283rd thread is spawned. Every combination I've tried > results > in the prog aborting at about the 283rd thread spawn. > > Does this sound familiar to anybody? > > Is there something my thread must do to properly shut itself down? > Does > it need to call some kind of procedure to announce it is going away > for > proper cleanup? I couldn't see anything in the examples like that. > > And is there documentation explaining the examples? I failed to > find > any. > > My thread procedure: > > > void updatethread(void* inparams) > { > > thread_params *tparam; > tparam=(thread_params *)inparams; > > int local_threadid = tparam->param1; > std::string DID = tparam->param2; > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " running. " > "UPDATE for " << DID << std::endl; > } > > > // wait some secs (just for debug, remove when real work is > being done) > boost::xtime xt; > boost::xtime_get(&xt, boost::TIME_UTC); > xt.sec += 2; > boost::thread::sleep(xt); > > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " Exiting. " << > std::endl; > } > > > { > boost::mutex::scoped_lock scoped_lock(numthreads_mutex); > --activethreads; > } > > } > > > MAIN calls it with this: > > //spawn thread > tparam.param1=threadid; > tparam.param2=dids[i]; > boost::thread *pt; > pt = thrds.create_thread(thread_adapter(&updatethread, > (void*)&tparam)); > > Thanks, > Tim > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 24 Nov '04

24 Nov '04

I think I'm on 1.31, so I'll give 1.32 a try. Thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, November 24, 2004 10:09 AM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca(a)voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com... > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and > after > spawning 283 or so threads, it stops running and 'Aborted' is > printed. > > It doesn't matter if I spawn them one after each other, or only 10 > at a > time, or if the threads only last 1 second or if they all stick > around > until the 283rd thread is spawned. Every combination I've tried > results > in the prog aborting at about the 283rd thread spawn. > > Does this sound familiar to anybody? > > Is there something my thread must do to properly shut itself down? > Does > it need to call some kind of procedure to announce it is going away > for > proper cleanup? I couldn't see anything in the examples like that. > > And is there documentation explaining the examples? I failed to > find > any. > > My thread procedure: > > > void updatethread(void* inparams) > { > > thread_params *tparam; > tparam=(thread_params *)inparams; > > int local_threadid = tparam->param1; > std::string DID = tparam->param2; > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " running. " > "UPDATE for " << DID << std::endl; > } > > > // wait some secs (just for debug, remove when real work is > being done) > boost::xtime xt; > boost::xtime_get(&xt, boost::TIME_UTC); > xt.sec += 2; > boost::thread::sleep(xt); > > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " Exiting. " << > std::endl; > } > > > { > boost::mutex::scoped_lock scoped_lock(numthreads_mutex); > --activethreads; > } > > } > > > MAIN calls it with this: > > //spawn thread > tparam.param1=threadid; > tparam.param2=dids[i]; > boost::thread *pt; > pt = thrds.create_thread(thread_adapter(&updatethread, > (void*)&tparam)); > > Thanks, > Tim > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[serialization] Enhanced Documentaiton for Argument Dependent Lookup?
by Jeff Flinn 24 Nov '04

24 Nov '04

Robert, The release notes page makes reference to: Differences from Draft #20 - Support for Argument Dependent Looup for serialization override invocations. - Enhanced documentation to help explain usage of the above. Where might this be found? A link here would be useful. Note: the misspelling of Lookup above is in the page. Thanks, Jeff

2 3

[graph] non-recursive version of undirected_dfs
by Synge Todo 24 Nov '04

24 Nov '04

Dear Boosters, I'm posting a non-recursive version of undirected_dfs, which should have advantages in space and time over the current implementation based on recursion, especially for huge graphs. It's a direct counterpart of the non-recursive version of depth_first_search for digraphs. I have confirmed that libs/graph/example/undirected_dfs.cpp as well as my own programs using undirected_dfs reproduce the identical outputs as those with the original recursive version. Best regards, Synge *** boost/graph/undirected_dfs.hpp 6 Aug 2004 05:02:41 -0000 1.1.1.1 --- boost/graph/undirected_dfs.hpp 19 Aug 2004 05:11:32 -0000 1.2 *************** *** 28,38 **** --- 28,106 ---- #define BOOST_GRAPH_UNDIRECTED_DFS_HPP #include <boost/graph/depth_first_search.hpp> + #include <vector> namespace boost { namespace detail { + // Define BOOST_RECURSIVE_DFS to use older, recursive version. + // It is retained for a while in order to perform performance + // comparison. + #ifndef BOOST_RECURSIVE_DFS + + template <typename IncidenceGraph, typename DFSVisitor, + typename VertexColorMap, typename EdgeColorMap> + void undir_dfv_impl + (const IncidenceGraph& g, + typename graph_traits<IncidenceGraph>::vertex_descriptor u, + DFSVisitor& vis, + VertexColorMap vertex_color, + EdgeColorMap edge_color) + { + function_requires<IncidenceGraphConcept<IncidenceGraph> >(); + function_requires<DFSVisitorConcept<DFSVisitor, IncidenceGraph> >(); + typedef typename graph_traits<IncidenceGraph>::vertex_descriptor Vertex; + typedef typename graph_traits<IncidenceGraph>::edge_descriptor Edge; + function_requires<ReadWritePropertyMapConcept<VertexColorMap,Vertex> >(); + function_requires<ReadWritePropertyMapConcept<EdgeColorMap,Edge> >(); + typedef typename property_traits<VertexColorMap>::value_type ColorValue; + typedef typename property_traits<EdgeColorMap>::value_type EColorValue; + function_requires< ColorValueConcept<ColorValue> >(); + function_requires< ColorValueConcept<EColorValue> >(); + typedef color_traits<ColorValue> Color; + typedef color_traits<EColorValue> EColor; + typedef typename graph_traits<IncidenceGraph>::out_edge_iterator Iter; + typedef std::pair<Vertex, std::pair<Iter, Iter> > VertexInfo; + + std::vector<VertexInfo> stack; + + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + stack.push_back(std::make_pair(u, out_edges(u, g))); + while (!stack.empty()) { + VertexInfo& back = stack.back(); + u = back.first; + Iter ei, ei_end; + tie(ei, ei_end) = back.second; + stack.pop_back(); + while (ei != ei_end) { + Vertex v = target(*ei, g); + vis.examine_edge(*ei, g); + ColorValue v_color = get(vertex_color, v); + EColorValue uv_color = get(edge_color, *ei); + put(edge_color, *ei, EColor::black()); + if (v_color == Color::white()) { + vis.tree_edge(*ei, g); + stack.push_back(std::make_pair(u, std::make_pair(++ei, ei_end))); + u = v; + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + tie(ei, ei_end) = out_edges(u, g); + } else if (v_color == Color::gray()) { + if (uv_color == EColor::white()) vis.back_edge(*ei, g); + ++ei; + } else { // if (v_color == Color::black()) + ++ei; + } + } + put(vertex_color, u, Color::black()); + vis.finish_vertex(u, g); + } + } + + #else // BOOST_RECURSIVE_DFS + template <typename IncidenceGraph, typename DFSVisitor, typename VertexColorMap, typename EdgeColorMap> void undir_dfv_impl *************** *** 69,74 **** --- 137,145 ---- } put(vertex_color, u, Color::black()); vis.finish_vertex(u, g); } + + #endif // ! BOOST_RECURSIVE_DFS + } // namespace detail template <typename Graph, typename DFSVisitor,

2 2

[Boost-bugs] [ boost-Bugs-1072605 ] condition variables and recursive_mutex
by SourceForge.net 24 Nov '04

24 Nov '04

Bugs item #1072605, was opened at 2004-11-24 09:00 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=1072605&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: condition variables and recursive_mutex Initial Comment: Hello - I've been working through the Boost.Threads example code, I'm new to the library, but i think i found a bug in the monitor.cpp example (boost_1_31_0/libs/thread/example/monitor.cpp) . When run using a recursive_mutex, the program hangs more often than not. It appears that the cuplrits are the calls to cond.wait(lk). For the recursive_mutex case, it appears that in some circumstances, these fall through without actually waiting for a change in the state of the lock lk. Attached is an example which is somewhat simpler that the one in monitor.cpp, but yields the same problem. Note that I'm compiling on a redhat ws3 system, with: Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) and linking against libboost_thread-gcc-mt.so Typical output as given is: sent 100, received 100 sender waits 99, receiver waits 49944 I.e. close to 50k calls to cond.wait() in the receiver thread) When recompiling with "recursive_mutex" replaced by "mutex", the number of waits is on the order of the number of receives (i.e. in the range 0-100) Any help/insight is appreciated. Regards, Bill Moser billm(a)ll.mit.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Named params lib review
by Gennadiy Rozental 24 Nov '04

24 Nov '04

Hi, Recently I became quite fond of interfaces with named parameters. I developed variety of different solutions with different trade-off and set of features. At first here is couple notes from my experience: 1. In most cases multiargument interface are not in high performance critical areas. 2. In many cases it's constructors. Now lets delve in more detailed discussion on: Design =============== I. Active vs. passive I found that there are two major branched in designs for named parameters: "active" parameters collection and "passive" one. Submitted library is a variation of "passive" solution: one need to call "get" method to retrieve any parameter from collection: template<typename Params> void foo( Params const& p ) { std::string name = p[name]; std::string description = p[descr]; ... } An "active" solutions automatically place parameters in appropriate slots by single 'apply' call: class A { public: template<typename Params> A( Params const& p ) { p.apply( *this ); } }; Even though "active" solutions in some cases provide an interface look more natural. I found that "passive" solution in most cases more flexible and easier to implement. While in both cases one may employ runtime polymorphism, with "passive interfaces it's more natural. Note that parameter may not necessary is just a simple value, it maybe some kind of optional feature and 'apply' method maybe not so trivial and even invoke some functions. All in all both design seems to have heir advantages and I believe we need to provide support for both flavors. II Interfaces a) Call interface and parameters combining IMO with some very rare exclusions (1/2 optional parameter) the named parameter framework shouldn't require/expect multiple overloading of target function with different number of parameters. As well as any "impl" functions. The only acceptable interface is the one with single Params template parameters (in some cases one may provide positional interface as well, though it's rather exclusion case). This is applicable both to active and passive solutions: class A { A() : ... {} template<typename Params> A( Params const& p ) : m_name( p[name] ), m_gulp( p[gulp] ) {} }; This immediately bring a need for automatic arguments combining. There are several ways to do so, depending on requirements (BWT I liked interface presented in some other post with using ',' as combine operator). b) Optional parameter support In case of active solutions there should be an interface to check presence of specific argument. Submitted solution will cause compile time error on access to non-supplied parameter. This may not be always most convenient and may not be the case at all with different implementation (runtime based) c) Default value support I specifically dislike an interfaces provided to support default values. They are unreasonably cryptic (who would remember difference between | and ||; and why | ) but also misleading since default value is actually with access brackets: what is p["abc"]? There are several alternatives. My personal preference is : int name_ = p.is_present<name> ? p[name] : "abc"; // you will need some MP trick to make it compilable or int name_ = p.is_present( name ) ? p[value] : "abc"; // this assumes runtime based implementation Active solutions doesn't have such issue. Whatever is there gets set by apply call. d) Type safety and restrictions I do not understand why wouldn't we keep data type somewhere around keyword type and require one to supply specific type during invocation.This library instead invented special mechanism of imposing restrictions. I do not believe we need that (Also my guess is that 8 out of 10 developers unfamiliar with library will be left spellbound facing this code) e) Mix of named and positional parameters I don't believe it's actually a good idea to support such mix. IMO it just adding unnecessary confusion and possible source of users errors.. Let's say I expect 2 parameters: 1. string name 2. int value. call foo( value = 5, "my_name" ) will fail, while foo( "my_name", value = 5 ) and foo( value = 5 ) won't. Too much chances to make mistake IMO. III. Implementation IMO whatever design you prefer implementation shouldn't as complex and cumbersome. Named parameters support is pretty simple task. This submission presents 1000 lines of tight MP code (and this is without numerous includes). In majority of the cases much more simple and straightforward solution is possible (with some acceptable IMO tradeoff). Following 80 lines (I think it's possible to make it even smaller would I use mpl) should basically present solution with similar tradeoff as submitted library (without default value support, but IMO it would take another 40-60 lines, just save it into keyword struct): // Library Code template<typename NP1,typename NP2> struct named_parameter_combine; template<typename T, int unique_id> struct keyword; template<typename Derived> struct named_parameter_base { template<typename NP> named_parameter_combine<NP,Derived> operator,( NP const& np ) { return named_parameter_combine<NP,Derived>( np, *static_cast<Derived*>(this) ); } }; template<typename T, int unique_id> struct named_parameter : named_parameter_base<named_parameter<T, unique_id> > { static const int id = unique_id; named_parameter( T const& v ) : m_value( v ) {} T const& operator[]( keyword<T,unique_id> const& ) const { return m_value; } T const& m_value; }; template<bool> struct selector; template<typename NP1,typename NP2> struct named_parameter_combine : named_parameter_base<named_parameter_combine<NP1,NP2> > { named_parameter_combine( NP1 const& np1, NP2 const& np2 ) : m_np1( np1 ), m_np2( np2 ) {} template<typename KW> typename KW::data_type const& operator[]( KW const& kw ) const { return selector<KW::id==NP1::id>::_( m_np1, m_np2, kw ); } NP1 const& m_np1; NP2 const& m_np2; }; template<> struct selector<true> { template<typename NP1,typename NP2,typename KW> static typename KW::data_type const& _( NP1 const& np1, NP2 const& np2, KW const& kw ) { return np1[kw]; } }; template<> struct selector<false> { template<typename NP1,typename NP2,typename KW> static typename KW::data_type const& _( NP1 const& np1, NP2 const& np2, KW const& kw ) { return np2[kw]; } }; template<typename T, int unique_id> struct keyword { typedef T data_type; static const int id = unique_id; named_parameter<T,unique_id> operator=( T const& t ) const { return named_parameter<T,unique_id>( t ); } }; //////////////////////////////////////////////////////////////// // Example: namespace test { typedef char const* c_str; keyword<c_str,1> name; keyword <float,2> value; keyword<int,3> index; double value_default() { return 666.222; } int foo( c_str name, float v, int i ) { } template<class Params> int foo(Params const& params) { foo( params[name], params[value], params[index] ); } } int main() { using test::foo; using test::name; using test::value; using test::index; foo(( index = 20, name = "foo", value = 2.5 )); return 0; } Strict type checking on top of it. This code works under gcc 3.4.2. Should work everywhere. As you may guess by now my vote is NO to accept this library. I personally wouldn't be using it in current form and IMO as it stands now it's just another collection of neat MP tricks. I do not have to much comments on docs and tests, other then they seems incomplete. Regards, Gennadiy P.S. Why is the RC branch of mpl is different from HEAD? Doesn't we supposed to fix HEAD and only then propagate to branch?

9 45

RE: [boost] Re: Boost Sandbox layout?
by Stefan Seefeld 24 Nov '04

24 Nov '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > I really wish there were a version control system with symlinks in > repository. Apparently subversion 1.1 support that: http://svnbook.red-bean.com/en/1.1/svn-book.html Regards, Stefan

1 0

how does one remove vertices from a graph
by Eyal Farago 24 Nov '04

24 Nov '04

adjacency_list documentations refers to 'stability' problems of vertex descriptors and iterators. it also provides two wrong and one correct ways to remove all vertices from a graph, trying to use the 'correct' way produced an exception from within vector::erase. after looking into the state of the iterators I understand that the 'correct' example isn't correct at all, the iterators still refers to the original offsets in the vertices vector when the current vertex is erased from the graph. i.e. suppose the graph had 7 vertices to begin with and we've already erased the first one, the iterator to current (vi in the example) should point to offset 0 and the end iterator(vi_end in the example) should point to offset 6, instead we have iterators to offsets 1 and 7. am I right? if so, what is the correct way to do it? eyal.

2 1

[graph] Why is there no boost::multimapS?
by David M. Jones 24 Nov '04

24 Nov '04

Hi all, I have a case where I'd like to create an adjacency_list whose edge container is a multimap. When I look through the boost files, I find boost::mapS and boost::multisetS so I don't see any obvious reason why there is no boost::multimapS. Thanks in advance, David

2 1

Serializing a variant
by Richard Peters 24 Nov '04

24 Nov '04

Hello, I'm looking for a way to serialize a variant. I see two possibly difficult things that I don't know how to accomplish: 1) In order to be able to retrieve a variant from an archive, the type of the value held by the variant must be stored. 2) When retrieving the data from an archive, once the type is read, a value of that type must be extracted from the archive and assigned to the variant. Has anybody tried this before, is this as difficult as it looks? Any help would be greatly appreciated. best regards, Richard Peters

5 6

Boost 1.32 vs. tru64cxx65
by Richard Hadsell 24 Nov '04

24 Nov '04

I'm trying to build some of the Boost libraries for the tru64cxx65 toolset. It seems that a header is missing from my compiler (Compaq C++ V6.5-030 for Digital UNIX V4.0F). This kind of error is showing up in a lot of code, since it seems to be a problem in a basic Boost header: cxx: Error: /tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/boost/cstdint.hpp, line 87: #5 could not open source file "inttypes.h" # include <inttypes.h> ----------------------^ cxx: Error: /tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/boost/cstdint.hpp, line 91: #282 the global scope has no "int8_t" using ::int8_t; ----------^ cxx: Error: /tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/boost/cstdint.hpp, line 92: #20 identifier "int8_t" is undefined typedef int8_t int_least8_t; ----------^ ... cxx: Info: 27 errors detected in the compilation of "/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/libs/filesystem/build/../src/convenience.cpp". cxx -c -timplicit_local -ptr "bin/boost/libs/filesystem/build/libboost_filesystem.so/tru64cxx65/release/cxx_repository" -noimplicit_include -D__USE_STD_IOSTREAM -nousing_std -msg_display_number -msg_disable 186,450,1115 -DNDEBUG -DNDEBUG -DBOOST_FILESYSTEM_DYN_LINK=1 -O2 -model ansi -I"bin/boost/libs/filesystem/build" -I"/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0" -I"/usr/include" -I"/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0" -o "bin/boost/libs/filesystem/build/libboost_filesystem.so/tru64cxx65/release/convenience.o" "/tmp_mnt/netDISKS/cgi/DIGITAL6/cgi/vendor/library/boost/boost_1_32_0/libs/filesystem/build/../src/convenience.cpp" -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

4 10

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 24 Nov '04

24 Nov '04

I switched the parameter-passing to the bind method, e.g. thrds.create_thread( boost::bind( updatethread, threadid, "123456789" ) ); with no difference. I did find that the same code that "aborts" under Linux seems to run ok under Windows. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tim Laplaca Sent: Tuesday, November 23, 2004 3:32 PM To: boost(a)lists.boost.org Subject: [boost] Thread: Why is my prog aborting after 283 or so threads? I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after spawning 283 or so threads, it stops running and 'Aborted' is printed. It doesn't matter if I spawn them one after each other, or only 10 at a time, or if the threads only last 1 second or if they all stick around until the 283rd thread is spawned. Every combination I've tried results in the prog aborting at about the 283rd thread spawn. Does this sound familiar to anybody? Is there something my thread must do to properly shut itself down? Does it need to call some kind of procedure to announce it is going away for proper cleanup? I couldn't see anything in the examples like that. And is there documentation explaining the examples? I failed to find any. My thread procedure: void updatethread(void* inparams) { thread_params *tparam; tparam=(thread_params *)inparams; int local_threadid = tparam->param1; std::string DID = tparam->param2; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " running. " "UPDATE for " << DID << std::endl; } // wait some secs (just for debug, remove when real work is being done) boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 2; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " Exiting. " << std::endl; } { boost::mutex::scoped_lock scoped_lock(numthreads_mutex); --activethreads; } } MAIN calls it with this: //spawn thread tparam.param1=threadid; tparam.param2=dids[i]; boost::thread *pt; pt = thrds.create_thread(thread_adapter(&updatethread, (void*)&tparam)); Thanks, Tim _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Another logo proposal
by Joaquín Mª López Muñoz 24 Nov '04

24 Nov '04

Here's my take. I'm providing b/w and color versions. The idea is to provide an abstract logo to associate with Boost while retaining the visual link with the previous artwork (through using the same Impact font for the name, a very appropriate font IMHO.) Some more rationales behind the proposal: * It can be easily rasterized. * It goes well with flat backgrounds. * It works as a transition from the old logo. As for the logo itself, it tries to convey the following connotations: * Its square shape, and the fact that is bottom aligned with the text, gives a sense of solidness. * It reminds the reader of a set of construction toolkit pieces, which associates well with Boost being a repository of general purpose libraries. * The "++" part of C++ is retained, integrated into the logo. Going a little pedantic, one can even recognize the logo as a deconstruction of "C++", where the L-shaped pieces are the two halves of an upper "C", split and shifted. Dya like it? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

15 23

RE: [boost] boost.thread : Can one create a thread withanobjectmemberfunction?
by Tim Laplaca 24 Nov '04

24 Nov '04

Thanks! For some reason it never occurred to me that there were includes at the boost root.... Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Tuesday, November 23, 2004 5:38 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread withanobjectmemberfunction? Tim Laplaca wrote: > I assume I need to include some bind includes to get this to compile > (I'm getting "error: `bind' undeclared in namespace `boost'". > > I see several includes in /usr/include/boost/bind. Which should I > include? None are obvious to me, like 'bind.hpp' would be. #include <boost/bind.hpp> :-) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Any interest in a boost::glob() function?
by Angus Leeming 24 Nov '04

24 Nov '04

Dear all, I've taken Richard Johnson's glob_iterator that he posted to the list back in January and re-written it completely, using Boost.Spirit to transform the input 'glob' into an equivalent regex. The result is a 'boost::glob' function that I believe is fully POSIX-conformant. Example usage: fs::path const starting_directory("."); std::list<fs::path> const matches = boost::glob("../te?t/foo*bar", starting_directory); The docs can be browsed online at http://www.devel.lyx.org/~leeming/globbing/index.html The library can be found at http://www.devel.lyx.org/~leeming/globbing.zip It should unzip to give: boost/glob.hpp boost/detail/glob.hpp libs/glob + ensuing sub directories and files. The code has been tested on Linux (g++ 3.3.2) and on Windows using MinGW/MinSys. There are still a few "issues" that I don't know how to resolve. Any pointers would be most welcome. DOCS ==== * It would be nice to insert a table inside an itemized list item, but quickbook doesn't like doing that. I need to add a separate paragraph. * boostbook/doxygen fails to document the glob_flags enum. * I generate a BOOST_LIB_NAME.html page and would like not to. BUILD ===== I have a couple of targets, lib/glob/example/real_glob.cpp and lib/glob/test/test_real_glob.cpp that I'd like to build only on POSIX machines. (They're wrappers for the system glob function.) Any pointers on how to instruct bjam to do that? REGEX ===== One test is failing on Windows "foo[[:alpha:]]bar". It works when compiled under Linux. Is there anything I should be aware of about Boost.Regex under MinGW/MinSYS? Regards, Angus

9 37

Booster rockets
by Deane Yang 24 Nov '04

24 Nov '04

How about just an upward slanted "C++" with booster rockets on each side of it shooting out flames? You don't even need the word "boost" with that, but it could still be there as Dave has it.

2 1

[Program Options Library] Does Program Options Library support "sections" in config file?
by 周方 Frank Chow 24 Nov '04

24 Nov '04

For example, to connect different databases according to different requests, there are some options stored in a config file, like this: [DB1] server=172.16.21.1 database=dbname1 userid=someone1 password=xxxxxx [DB2] server=172.16.21.2 database=dbname2 userid=someone2 password=oooooo i.e. with same key name in different sectors. In Win32 API, this method is very handy: // to get "server" in "[DB1]" char buf[256]; GetPrivateProfileString (""DB1, "server", "", buf, sizeof(buf), "configfile.ini"); Is there a mechanism in "Program Options Library" to support this config file? Or, does it intend to support? Thanks!

2 1

logos with rockets
by David Abrahams 24 Nov '04

24 Nov '04

Here are some further attempts. Be sure to look at the first two slides. http://www.luannocracy.com/logo.ppt Sorry about the file format. I have been having trouble exporting these pictures accurately from PowerPoint. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

7 11

RE: [boost] preprocessor fix
by Arias Brent-P96059 24 Nov '04

24 Nov '04

> Have you seen http://www.cuj.com/documents/s=8470/cujboost0306besser/? Yes, I have seen that before. I did not use it for several reasons: (1) I think the source for Besser's ENUM was not easily available, (2) my employer gets nervous when code "looks" too C++ oriented and gets nervous when macros become too "involved" - which means "lengthy" (3) Besser's ENUMX macro requires that you specify the number of parameters (e.g. ENUM3 or ENUM23). Reason #3 was a real hurdle for me - because I'm trying to provide this macro to other developers who might "rebel" if using the macro requires from them non-intuitive new concepts or exercises. That is, if they didn't have to count the number of parameters in the enumeration before - they may well reject the ENUM macro if it starts to require them to count the entries. So, I set out to make an ENUM macro that (1) didn't need its entries counted by the developer and (2) had a short definition (which makes it less daunting for "managment" buy-in). You said: >there are still basic notions of computation, etc., such as >control flow--which is nothing but a conditional "invocation" >of its accompanying code. Those kinds of things still apply >at the preprocessor level. What you really needed was a way to >conditionally enumerate some sequence elements, not enumerate a >conditional sequence. My implementation was "backwards" because I was unable to make the code compile otherwise. That is, depending on the value of ENUMS, the following code did not compile: > #define ENUM(name, start, entries) \ > BOOST_PP_EXPR_IIF(ENUMS)( \ > BOOST_PP_SEQ_ENUM( \ > (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ > BOOST_PP_SEQ_TAIL(entries) \ > (LAST_ ## name } name;) \ > ) \ > ) \ You said: >You can do it, but EXPR_IIF does not lazily evaluate its > argument (the syntax above is what EXPR_IIF would look > like if it *did* lazily evaluate it argument). >In other words, when ENUMS is 0, SEQ_ENUM will still be >invoked, but its results will be discarded. I'm not sure what you are suggesting. Depending on the value of ENUMS, the code snippet I showed above would not compile - lazy evaluation or not. If it won't compile, then there's nothing for me to ponder (except to use a different approach - which happily you taught me with the TUPLE_EAT macro). :) Paul, thanks so much for the help you've provided. -Brent

2 1

RE: [boost] Re: logos with rockets
by Brian Braatz 24 Nov '04

24 Nov '04

One could always shoot for the middle here, and have the BOOST word have "Jetpacks" on. I.e. evokes more of the power and energy Though, while I suggested that, I am not sure how to draw it :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Petrov > Sent: Tuesday, November 23, 2004 3:26 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: logos with rockets > > I don't think a rocket would be the most suitable symbol for Boost. To > me it communicates ideas like "flight" and "space", which obviously > don't fit very well. > > IMO, a much better variant would be a thunderbolt. It is commonly > associated with "power" and "energy", exactly in the spirit of the Boost > name. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Logo substance. [was: Re: Logo... and page design.]
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: Rene Rivera <grafik.list(a)redshift-software.com> Fecha: Lunes, Noviembre 22, 2004 11:06 pm Asunto: [boost] Logo substance. [was: Re: Logo... and page design.] > David Abrahams wrote: > > > "Peter Dimov" <pdimov(a)mmltd.net> writes: > > > >>I'm not a logo expert by any stretch of the imagination... but it > >>seems to me that if you have a rocket, you don't need the text > >>"boost". The rocket is the logo. It needs to have some unique visual > >>features that establish its identity as the "boost/C++" rocket, of > >>course. > > > > Interesting. But every logo I've seen includes the name of the > entity> it stands for somehow. > > Yes, and that's done to enforce the association between the logo > and the > company identity. Eventually the logo becomes synonymous with > the > identity and starts getting used more frequently without the name. > AT&T, > Cingular, Apple, and Motorola come to mind in that respect. > > > Even if the rocket isn't part of some "Boost" > > text, you need to choose a font for "Boost" and decide how it sits > > next to or below the rocket. > > True, but it will likely be easier to decide on the substance of > the > logo without the text. No distractions that way. Not that one > should > forget totally about the text. But it's much easier to think about > what > can represent Boost, without the word Boost in it. > > So far I see three different concepts for logo: > > 1) The "<>" brackets. > > 2) The "++" operator. > > 3) The rocket. > Thogu I prefer the ++ theme, here's a possible design for the rocket idea, kinda retro-style. The execution can be much improved, just wanted to know whether the general style feels OK. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

10 15

Ref documenation point of clarity
by Edward Diener 24 Nov '04

24 Nov '04

This may be seen as a nitpick by I think the generalized one-line explanation for 'ref', as well as the text in the 'ref' introduction should say "passing reference parameters to generic functions" rather than "passing references to generic functions".

3 6

Logo designs for Boost + Boost.Build
by Cromwell Enage 24 Nov '04

24 Nov '04

I guess I could throw in a couple of pennies into this discussion. I agree that we should try to pin down the logo's essential elements before submitting any prototypes. (If we *really* need pictures, we might consider setting up a Boost Wiki page for them.) IMHO, there are only two essential elements: Boost and ++. "Boost" should be there for the obvious reason, and "++" evokes enough of a positive association to the implementation language without having to say "C++". Why isn't "<>" an essential element? Because it's too solution-specific. For example, I can't imagine a Python programmer wanting to use Boost.Python because it utilized templates. Boost.PP is another great library that doesn't use templates at all, though it works great with them. Finally, Boost is the proving grounds for libraries that are candidates for the entire C++ standard, not just the STL. Of course, w/out the "C++" element, there's no point in using "/", either. Now that I've proprosed the elements, I think the idea of using the pre-increment operator instead of post-increment should also be incorporated into the logo, so hard-core programmers could see at a glance that we value performance, too. Putting it all together, I believe the essence of the logo should be: ++Boost You could have the word "Boost" look like a space shuttle orbiter, as someone else suggested. The colors would be perfect, as orbiters are black and white (w/out the U.S. flag). The "++" would then look like smoke exhaust. The essence for the Boost.Build logo could then be ++Boost Build where "Build" would look like a rocket-launching truck. (A vehicle assembly building would be more accurate, but less resonant, not to mention too big.) One objection I could foresee with this idea would be that space shuttles might be phased out in the near future because of the last national tragedy involving them. Say anything you want about C++, that's one form of resonance I wouldn't want to evoke. Feel free to take my place in the bicycle shed if that's what we're ending up building :) Cromwell Enage __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

RE: [boost] Re: logos with rockets
by Brian Braatz 24 Nov '04

24 Nov '04

I like page 5 the best IMO - a Couple of thoughts: * "Boost" is horizontal and not slanted- this evokes "Stability" (the slanted boost looks cool- but doesn't send the right message- i.e. it looks like a picture not hung properly) * care should be taken that the logo looks good in SMALL sizes and Large ones- this means that the image should not rely upon any distinctive features of the logo that do not show up well as a thumbnail When I worked at adobe (many years ago)- they actually had a "overall" logo for Adobe, and variations for large and small sizes Also- referring to #5, I suggest to bring the rocket down a little bit (because if you reduce the size this may not look properly) SUGGESTION- As this starts to settle, present the images of the logo in a SMALL MEDIUM and LARGE sizes- so that we can get a feel for what it looks like in those variations. That would be my my 2 cents :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Tuesday, November 23, 2004 4:01 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: logos with rockets > > Beman Dawes <bdawes(a)acm.org> writes: > > G> At 12:05 PM 11/23/2004, David Abrahams wrote: > > > > > >Here are some further attempts. Be sure to look at the first two > > >slides. > > > > > > http://www.luannocracy.com/logo.ppt > > > > The second one is a candidate, I'd say. > > There are more variations up there now. > > http://www.luannocracy.com/logo.ppt > http://www.luannocracy.com/logo.pdf > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Re: Logo substance. [was: Re: Logo... and page design.]
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Martes, Noviembre 23, 2004 11:25 pm Asunto: [boost] Re: Logo substance. [was: Re: Logo... and page design.] > Rich Johnson <rjohnson(a)dogstar-interactive.com> writes: > > >>> I find this one too static, compared to Dave's attempts. > >>> It does have the sense of solidity that some have asked for, > >>> but I'd rather have a more dynamic feel (which reflects, I think, > >>> more accurately what boost is. Much of boost is not for the > >>> faint-hearted.) > >> > >> Thanks. Actually I thought that Joaquín's design was plenty > dynamic>> and better than mine on simplicity grounds. I do agree > about the ring > >> and the ++. Put a little white gap between the rocket and the > ring at > >> the intersection, and you've got your "C." > >> > > Hmm... two little puffs of exhaust could be +'s and the third > could be > > a 'C'-ring. It's kinda' cartoony, but fun. > > Or you could make the +es into four-pointed stars. > Like this? (again, this can be implemented more carefully, it's just a sketch to explore the idea.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Re: Re: Any interest in a boost::glob() function?
by Beman Dawes 23 Nov '04

23 Nov '04

At 03:16 PM 11/23/2004, Rich Johnson wrote: >Yup. This is getting further into hypothetical design than is probably >appropriate, but....assuming the FS provides an is_name_equivalent() >convenience function (which I think it should): > >A monolithic 'is_name_equivalent()' function that sets up and tears >down a regex each time it's invoked would have performance issues when >used in the context of the globber. > >A reusable 'name_comparator' object(functor) supplied by the FS layer >could be instantiated once as part of the glob_predicate. > >Of course this raises the issue of what happens when you glob across a >FS boundary(mount points and links)--must the name_comparator change >accordingly? On Windows, it is not possible to tell if two names (or paths) are equivalent just by looking at the name (or path). The question can only be answered by inspecting the current state of the filesystem. For example, if a directory contains both files "A" and "a", then these two names are not equivalent. But if the directory only contains a file named "A", then "a" is equivalent in that directory at the current time. Since you can't determine equivalence, if neither exist then the equivalent() function throws in that case. --Beman

1 0

RE: [boost] boost.thread : Can one create a thread with anobjectmember function?
by Tim Laplaca 23 Nov '04

23 Nov '04

I assume I need to include some bind includes to get this to compile (I'm getting "error: `bind' undeclared in namespace `boost'". I see several includes in /usr/include/boost/bind. Which should I include? None are obvious to me, like 'bind.hpp' would be. Thanks, Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Monday, November 22, 2004 5:57 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread with anobjectmember function? Tim Laplaca wrote: > boost::thread_group thrds; > > objclass * objthread; > > > > objthread = new objclass; > > thrds.create_thread( (objthread->p) ); Do this instead: boost::shared_ptr<objclass> objthread( new objclass ); thrds.create_thread( boost::bind( &objclass::dowork, objthread ) ); Even better, drop the objclass entirely and do this: void dowork( int tid, string valtwo ) { // do work } thrds.create_thread( boost::bind( dowork, my_thread_id, my_valtwo ) ); _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: Another logo proposal
by JOAQUIN LOPEZ MU?Z 23 Nov '04

23 Nov '04

----- Mensaje original ----- De: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> Fecha: Martes, Noviembre 23, 2004 9:21 pm Asunto: Re: [boost] Re: Another logo proposal > David Abrahams wrote: > > > With all due respect, I find this logo direction dry, unattractive, > > and not memorable. > > For contrast, I think Joaquín Muñoz's preferred black on white > plus-plus > design is the best I've seen so far, including his rockets. If > all of > the thus-far proposed logos were put before me in a controlled > test, and > the examiner asked me which one of these logos was most likely the > logoof a high-quality, industrial-grade, corporate-accepted software > package, I'd go with the plus-plus design. > Hey, good to know there's someone on my side :) thanks! My particular "++ in a block" proposal aside, I think it'd be good that an stylized, abstract logo be adopted, or at least a simple one, amenable to multiple rendering contexts (b/w, small size, etc.) Cartoon logos might look fun, but they can clash with the environment in many aspects (general tone, color palette, style.) In contrast, a stylized logo has the same connotational power without any of the aforementioned potential problems. Companies that invest big bucks in corporate image know it well. I propose you a simple exercise: name the first 20 companies that come to your mind, visit their websites and take a look at the logo. How many of them have a figurative icon? How many of them have a multicolor icon (say, more than 3 colors)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: RE: [boost] Another logo proposal
by Robert Geiman 23 Nov '04

23 Nov '04

---- Original Message ---- From: joaquin(a)tid.es To: boost(a)lists.boost.org Subject: Re: RE: [boost] Another logo proposal Date: Tue, 23 Nov 2004 01:30:24 +0100 >> >> >I think this is what you've got in mind. >> >Myself, I don't like it much. Not so compact, and >> >the "C++" thing becomes too obvious. But well, this >> >is just my opinion, of course. >> >> Close, but not quite what I was thinking. The version you created >> goes below this bottom of the first +, which as you said makes it >> less compact. >> >> Take that bottom C part and puch it up one "block", making sure you >> keep the + sign on top of the background. In essence, you'd really >> just be adding a single block of background in the lower left gap >of >> the first +, and another block to the lower right gap of the first >+, >> if that makes any sense. >> > >Like this? That's it exactly. Although it's almost not obvious enough that there's a C there. Of course, in the inverted version you created, if the background C was a slightly different color than the ++ it would help it stand out a little more. - Robert Geiman

3 3

Logo design
by Miro Jurisic 23 Nov '04

23 Nov '04

I don't mean to put down anyone's effort, but some of the logo sketches were, well, terrible. I think that a number of people here have had interesting ideas in terms of what the logo might contain (whether it's a rocket or angle brackets), but very few of the resulting images were esthetically pleasing. My proposal is that we take a small set of possible ideas to someone with graphic design skills. I am not implying we have nobody like that here, I just think this is very quickly degenerating into a shed-painting discussion, and I think we can save everyone a lot of time by picking 1-3 ideas (e.g., "boost rocket") and having someone adept of converting ideas into images work with that. meeroh "I can't draw to save my life, and I know it" PS. I think a design which simply reads "boost" and has the letter t be the rocket would work well -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

8 13

[Review] Named Parameters library
by Thomas Witt 23 Nov '04

23 Nov '04

My vote for the Named Parameters library is a clear YES, but ... the documentation needs to be improved. - What is your evaluation of the design? I think the design is sound. It provides all the functionality I can think of. I particularly like lazy evaluation of defaults and controlling the overloadset. I am convinced that removing spurious overloads will become ever more important in modern C++. - What is your evaluation of the implementation? I did a very brief reading of the code. No complaints here. - What is your evaluation of the documentation? The documentation needs improvement. Ignoring a few typos in the current documentation I still think the documentation is not sufficient for using the library. A reference is needed. - What is your evaluation of the potential usefulness of the library? To me named parameters have the potential to significantly improve the interfaces used in C++ code, be it application code or library code. A problem that AFAICS every named parameter lib faces is the issue of keyword scoping. The keyword objects have the potential to reserve names in scopes that they shouldn't. I think the only way to find out how big this problem is in practice and what the best idioms for scoping the keywords are is by using named parameter libraries. The other issue is the tradeoff between ease of use/interface design and the associated compiletime and runtime costs. E.g. compile speed and codesize. Again I think we will only find out by experimenting. - Did you try to use the library? With what compiler? Did you have any problems? No. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 1.5h - Are you knowledgeable about the problem domain? No, as far as named parameter concepts outside C++ are concerned. Regards Thomas -- Thomas Witt witt(a)acm.org

2 2

RE: [boost] boost.thread : Can one create a thread with an objectmember function?
by Tim Laplaca 23 Nov '04

23 Nov '04

Thanks! Since I don't need the class anymore I don't need to use bind, but I'll keep this in mind for the future. Thanks again, Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Cory Nelson Sent: Monday, November 22, 2004 5:58 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread with an objectmember function? Yup! boost::thread(boost::bind(&classname::method, boost::ref(thisptr))); On Mon, 22 Nov 2004 10:50:17 -0500, Tim Laplaca <tlaplaca(a)voiceglo.com> wrote: > I am very new to boost, I apologize if this has been asked before. I > searched the mailing list archive but could not find an answer to my > question. > > I was successful creating threads with functions that are not members of > objects, but when I try to create threads with a pointer to an object > member I get compilation errors (MS Visual Studio .NET). > > Examples: > > class objclass; > > typedef void (objclass::*pmf)(); // ptr to member func > > class objclass > > { > > public: > > objclass() : thread_id (0) { p=&objclass::dowork; } > > inline setthreadid(int x) {thread_id = x;} > > inline setvaltwo(std::string str) {valtwo = str;} > > void dowork(); > > pmf p; // pointer to dowork member function > > int getthreadid() {return thread_id;} > > std::string getvaltwo() {return valtwo;} > > private: > > int thread_id; > > std::string valtwo; > > }; > > void objclass::dowork() > > { > > } > > (In the main...) > > boost::thread_group thrds; > > objclass * objthread; > > objthread = new objclass; > > thrds.create_thread( (objthread->p) ); > > I get the following error: > > c:\Boost\include\boost-1_31\boost\function\function_template.hpp(427): > error C2664: 'void > boost::function0<R>::assign_to<Functor>(FunctionPtr,boost::detail::funct > ion::function_ptr_tag)' : cannot convert parameter 2 from > 'boost::detail::function::member_ptr_tag' to > 'boost::detail::function::function_ptr_tag' > > with > > [ > > R=void, > > Functor=pmf, > > FunctionPtr=pmf > > ] > > Is there a way around this problem, or is it simply not possible to make > threads from object members with boost? > > Thanks, > > Tim > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > -- Cory Nelson http://www.int64.org _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] boost.thread : Can one create a thread with anobjectmember function?
by Tim Laplaca 23 Nov '04

23 Nov '04

Thanks, it turns out I don't need to object class so I dropped it. Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Monday, November 22, 2004 5:57 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread with anobjectmember function? Tim Laplaca wrote: > boost::thread_group thrds; > > objclass * objthread; > > > > objthread = new objclass; > > thrds.create_thread( (objthread->p) ); Do this instead: boost::shared_ptr<objclass> objthread( new objclass ); thrds.create_thread( boost::bind( &objclass::dowork, objthread ) ); Even better, drop the objclass entirely and do this: void dowork( int tid, string valtwo ) { // do work } thrds.create_thread( boost::bind( dowork, my_thread_id, my_valtwo ) ); _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review] Named parameter questions
by Thomas Witt 23 Nov '04

23 Nov '04

Hi, I was going to provide a (late) review for the named parameter lib, but I have some questions before I can do that. 1) I find the use of the name "keyword" for the type of the named parameter somehow odd. It does not seem to fit with what I associate with keywords. What's the rationale behind that choice. 2) The docs give the following example for mixing named and positional parameters: foo("bar", 3.14f); foo(value = 6.28f, "baz") Should print: bar = 3.14 baz = 6.28 I believe the parameter deduction in this case is too smart. Is there a way for the user of the library to enforce a rule like "No positional param after named params" on a case by case basis? 3) Section 5 has the following example // implementation of bar() template <class Params> void bar_impl(Params const& params) { // Extract arguments float x_ = params[x]; float theta_ = params[theta | pi]; float span = params[span || boost::bind(default_span, x_, theta_)]; //!! ^^^^ ^^^^ ... } IIUC this does not work. I assume the second span should refer to a named paramter object. I think it refers to the local span object. Did I miss something? Regards Thomas PS: Doug I know I am late, feel free to ignore me. -- Thomas Witt witt(a)acm.org

5 5

[Named Parameters] BGL named parameters -> review Named Parameters
by Doug Gregor 23 Nov '04

23 Nov '04

The attached "named_function_params.hpp" allows the BGL named parameters to coexist with the named parameters library up for review. The attached "page_rank.hpp" file implements a simple algorithm that now supports both named parameters interfaces. The test file exercises both interfaces. Worked for me on Apple's GCC 3.3. A review is still in the works. Doug

2 1

[Review] Named parameters questions, comments, and food for thought
by Doug Gregor 23 Nov '04

23 Nov '04

I've just implemented a new BGL algorithm using the named parameters library for the interface. The algorithm itself is very simple, but illustrates some of the benefits and pitfalls of the named parameters library. After writing this, I of course have some questions and comments about the named parameters library. This is not actually a review: that will come later. And don't confuse this with my role as review manager. --------------------------Fixed positional parameters----------------------------- The first issue I ran into was that I really wanted a fixed number of positional parameters before any of the named parameters. These parameters will not have defaults and there is no reason to allow them to have names. I say this is an "issue" and not a "problem" because there are several workarounds: 1) Don't use BOOST_NAMED_PARAMS_FUN; write out the forwarding functions manually. (This is the option I chose) 2) Make the required, positional parameters into named parameters (so that we can use BOOST_NAMED_PARAMS_FUN) but do not provide the objects of type "keyword" for these parameters. So, for instance, I'll have "struct graph_t {};" but no corresponding keyword "boost::keyword<graph_t> graph;". The algorithm would also have to use boost::named_param to say that there is no default value for these parameters. I chose option (1) for various reasons. The primary reason actually had to do with something another reviewer brought up: it's rather hard to deal with creating defaults for named parameters that rely on other named parameters. This was never easy (the BGL has the same problem), but picking (2) above makes things much harder: for instance, the first positional parameter is _always_ the graph, and nearly every default value depends on knowing the graph type. However, I wouldn't be able to get at the type of p[graph_t()] without passing it to another helper function and doing the work there. ------------------------Default parameters---------------------- Both normal and lazy defaults work very cleanly. The dispatch to my implementation function is quite readable: detail::page_rank_impl (g, rank_map, p[done | n_iterations(20)], p[num_active_vertices | num_vertices(g)], p[rank_map2 || vector_property_map_builder<Graph, rank_type>(g)]); vector_property_map_builder is a new function object a had to create to perform the lazy construction of a vector_property_map, but that doesn't hurt so badly. A better version of it would just end up somewhere in the BGL and be reused. -----------------------The type of params[foo | def]------------------- Going into this, I had the notion that I'd be able to use BOOST_NAMED_PARAMS_FUN to eliminate all of the extra levels of dispatching calls. It still took 3 levels of function calls: 1 for bundle the parameters, one to stick defaults in, and one to do the actual work. If we could get the return type of p[foo | def] or p[foo || def] directly, we could solve those problems. To make that usable, perhaps some"auto"-like macro: BOOST_NAMED_PARAMS_AUTO(g, graph_t); BOOST_NAMED_PARAMS_AUTO_DEF(done, done_t, n_iterations(20)); BOOST_NAMED_PARAMS_AUTO_LAZY_DEF(rank_map2, rank_map2_t, (vector_property_map_builder<Graph, rank_type>(g))); Unfortunately, I think we need typeof to do that :) ----------------------- Question on boost::keyword ------------------- If the BGL is going to switch to this library, we are going to need backward compatibility. I can do that easily if I'm allowed to derive my keywords from boost::keyword instead of using exactly a "boost::keyword". Can I do that? More comments and probably a real review later... I want to go home now. Doug

2 1

Using program_options with other options methods
by Allen Bierbaum 23 Nov '04

23 Nov '04

I have recently started using the program_options library, and I find it very useful. Unfortunately I can't seem to figure out how to allow it to work with other option parsers/handlers at the same time. For example, right now I am writing an application that uses a library that has its own set of common options that are process internally. So I end up needing to write code similar to the following: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("my_opt", po::value<int>(), "set my option") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); custom_lib::options opts; opts.process(ac, av); Then when I run this application: ./app --my_opt=10 --liboption=custom The problem is that I get an exception from program_options: error: unknown option --liboption Is there any way to tell the program options parser to ignore options that it does not recognize? If there is no option like this, how can program_options be used with other option parsers? -Allen -- -- Allen Bierbaum allenb(a)vrac.iastate.edu

1 0

posix_time::time_from_string() assertion failed due to bad input format
by Alexander Konovalenko 23 Nov '04

23 Nov '04

boost::posix_time::time_from_string() terminates the program due to a failed assertion on certain inputs. Boost version used: 1.31.0. Compiler used: GCC 3.3.4. (All the tools come from pre-built Debian GNU/Linux packages.) I didn't find a fix for this problem in the latest change log. Running the attached test program (see the source) gives the following output: date_format_bug_demo: /usr/include/boost/token_iterator.hpp:59: const Type& boost::token_iterator<TokenizerFunc, Iterator, Type>::dereference() const [with TokenizerFunc = boost::char_delimiters_separator<char, std::char_traits<char> >, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Type = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]: Assertion `valid_' failed. Aborted I expected it to throw some descendant of a standard exception instead. Is it indeed the accepted policy in the Date_time library to always handle invalid input data by throwing an appropriate exception? Or are there cases where the input is intentionally assumed to be correct and is thus left unchecked? Thanks in advance! -- Alexander

2 3

Boost license
by Falk Hueffner 23 Nov '04

23 Nov '04

Hi, the boost license (http://www.boost.org/LICENSE_1_0.txt) does not allow redistributing modified versions. Is that intentional or an oversight? -- Falk

7 27

Boost 1.32.0 released
by Aleksey Gurtovoy 23 Nov '04

23 Nov '04

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + NOTE: This is a stripped-down copy of the Boost 1.32.0 release + + notes. See http://www.boost.org for the full version. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Important - New Toolset Names ----------------------------- The names of some the Boost.Build toolsets have been changed to remove the "." (dot) character and to fix some other naming inconsistencies. For example, vc7.1 toolset was renamed to become vc-7_1. Please refer to the Supported Toolsets section of the installation guide for the complete list of the current toolset names. This change was made as a part of the effort to make the Boost distribution compatible with ISO 9660 level 2 requirements. New Libraries ------------- * Assignment Library: Filling containers with constant or generated data has never been easier, from Thorsten Ottosen. * Minmax Library: Standard library extensions for simultaneous min/max and min/max element computations, from Herv Brnnimann. * Multi-index Containers Library: Containers with multiple STL-compatible access interfaces, from Joaqun M Lpez Muoz. * Numeric Conversion Library: Optimized policy-based numeric conversions, from Fernando Cacciola. * Program Options Library: Access to configuration data given on command line, in config files and other sources, from Vladimir Prus. * Range Library: A new infrastructure for generic algorithms that builds on top of the new iterator concepts, from Thorsten Ottosen. * Serialization Library: Serialization/de-serialization of arbitrary C++ data structures to various formats including text, binary, and xml, from Robert Ramey. * String Algorithms Library: Collection of string related algorithms for case conversion, trimming, find/replace operations and more, from Pavol Droba. * Tribool: 3-state boolean type library, from Doug Gregor. Updated Libraries ----------------- * Compose: This deprecated library has been removed. * Graph: - Added bundled properties to the adjacency_list and adjacency_matrix class templates, greatly simplifying the introduction of internal vertex and edge properties. - The LEDA graph adaptors have been ported to LEDA 4.5. - Added algorithms for betweenness centrality and betweenness centrality clustering. - Added circle layout and undirected spring layout algorithms. * MPL Library: - Updated to use the Boost Software License. - New documentation, including a complete reference manual. - Major interface changes and improvements, many of which are not backward compatible. Please refer to the 1.32 changelog for the detailed information about upgrading to the new version. * Python Library: - Updated to use the Boost Software License. - A new, better method of wrapping classes with virtual functions has been implemented. - Support for the new Python Bool type, thanks to Daniel Holth. - Support for upcoming GCC symbol export control features have been folded in, thanks to Niall Douglas. - Improved support for std::auto_ptr-like types. - Components used by other libraries have been moved out of python/detail and into boost/detail to improve dependency relationships. - Miscellaneous bug fixes and compiler workarounds. * Signals Library: Introduced deterministic slot ordering, permitting slots to be connected at the beginning or end of slot groups or the slot list itself. Combiners may safely have state and are accessible from the signal. * Utility: class template result_of added. * Test Library: - namespace names gets shorten; old one still supported till next release. - added proper encoding of XML PCDATA. - support for wide string comparison implemented. For complete list of changes see Test Library release notes. Regression tests ----------------- This release has been extensively tested on a variety of different compilers and platforms. It is known to contain no regressions against the previous reference release on the compilers and configurations tested. Please refer to the corresponding regression reports at http://www.meta-comm.com/engineering/boost-regression/1_32_0 to see how well your compiler performs on the new Boost codebase. Acknowledgements ---------------- This release wouldn't have been possible without the dedicated effort of many, many members of the Boost community who generously contributed their outstanding expertise, time and energy to making it happen. For patches, bug fixes, troubleshooting, expert advice, and prompt responses to the release manager's requests we thank: David Abrahams, Misha Bergal, Jonathan Brandmeyer, Fernando Cacciola, Marshall Clow, Christopher Currie, Pavol Droba, Caleb Epstein, Eric Friedman, Jeff Garland, Michael Glassford, Doug Gregor, Joel de Guzman, Hubert Holin, Jaakko Jrvi, Hartmut Kaiser, Bronek Kozicki, Tarjei Knapstad, Toon Knapen, Aaron W. LaFramboise, Joaqun M Lpez Muoz, Christoph Ludwig, John Maddock, Paul Mensonides, Guillaume Melquiond, Thorsten Ottosen, Vladimir Prus, Robert Ramey, Rene Rivera, Gennadiy Rozental, Stefan Slapeta, Jonathan Turkanis, Pavel Vozenilek, Jonathan Wakely, Daryle Walker, Victor A. Wagner Jr. and Martin Wille. Also, our special thanks go to: John Maddock for the managing the effort of converting the majority of the Boost libraries to the Boost Software License, Eric Niebler and Joel de Guzman for taking on the important job of improving the Boost documentation's look and feel, and last, but not least, to our regression test runners, without whom we simply would never have released: Toon Knapen, Bronek Kozicki, Rene Rivera, Markus Schpflin, Stefan Slapeta, Victor A. Wagner Jr. and Martin Wille. Thank you everybody! -- Aleksey Gurtovoy MetaCommunications Engineering

6 8

[date-time] small interface nitpick
by Pavol Droba 23 Nov '04

23 Nov '04

Hi, I have spoted another small inconsistence in the date-time interface. Generic date_time::time_duration 4-parameter contructor have a default values for seconds and fractional seconds. Posix variant have default value only for frac_seconds. Regards, Pavol

2 1

date_time request for addition
by Pavol Droba 23 Nov '04

23 Nov '04

Hi, In the Date-Time library, date_duration class provides a set of basic arithmetic operations. Among others there is multiplication and division. Current interface supports only integer factors. Sometimes this precision is not sufficient. I have actualy came accross such a occasion. I need to adjust the duration using a multiplier from range <0,1>. Currenly it is not feasible, and I have to workaroud it by converting to microseconds and back. Would it be possible to alter the interface, so it will be able to use real factors? Thanks. Regards, Pavol

2 5

MPL documentation
by Edward Diener 23 Nov '04

23 Nov '04

The MPL documentation is better than before and the reference is excellent. However I do not believe the tutorial is adequate for bringing new programmers interested in understanding metaprogramming using MPL into a general understanding of how MPL works and how to use it. This is because the tutorial does not start at the beginning of defining MPL concepts but jumps into high order metafunctions without explaining the basis of metafunctions or metaprogramming classes to begin with. I understand the problem, that metaprogramming is a large concept and that understanding the basics would entail starting at a point where explaining anything further takes up much more space than a mere tutorial would normally encompass. The answer no doubt is to buy Mr. Abrahams and Mr. Gurtovoy's book. However despite the good intent of the tutorial, I think that it only performs the function of bringing further knowledge of the MPL library to those who already understand how the basics of the library already work. For those C++ programmers who want to learn to understand how to use the MPL library from scratch, I do not think the tutorial is adequate. Perhaps MPL was never meant to appeal to those without a knowledge of its precepts to begin with, but by assuming that I think that the tutorial will either leave C++ programmers who would like to learn to use MPL feeling pretty cold about it, or force them to buy the book in order to understand how it works.

2 5

result_of?
by Brock Peabody 23 Nov '04

23 Nov '04

I replaced my home grown result_type<> with boost::result_of<> today only to find that I couldn't get it to work. When I try to use result_of with VC 7.1: struct test_struct { typedef int result_type; }; boost::result_of<test_struct>::type i = 5; I get: test.cpp(10) : error C2027: use of undefined type 'boost::result_of<F>' I get the same results if I use function types of pointer to function types: boost::result_of<int (*)()>::type i = 5; boost::result_of<int ()()>::type i = 5; Am I missing something? Thanks, Brock Peabody

2 2

Re: [boost] Boost 1.32.0 released
by JOAQUIN LOPEZ MU?Z 23 Nov '04

23 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Sábado, Noviembre 20, 2004 5:23 am Asunto: [boost] Boost 1.32.0 released > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > + NOTE: This is a stripped-down copy of the Boost 1.32.0 release + > + notes. See http://www.boost.org for the full version. + > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > [stuff deleted] First of all, congratulations to everybody :) Has this announce been posted to comp.lang.c++.moderated? I haven't seen anything there yet. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[program_options] Compiler warning in 1.32 release
by Jody Hagins 23 Nov '04

23 Nov '04

/home/jody/boost_1_32_0/libs/program_options/src/cmdline.cpp: In member function `void boost::program_options::detail::cmdline::clear_error()': /home/jody/boost_1_32_0/libs/program_options/src/cmdline.cpp:732: warning: ` boost::program_options::invalid_command_line_syntax::kind_t re' might be used uninitialized in this function In this case, the enumeration "re" of type kind_t is not initialized, and will hold "any" value. The switch does not set the value in the default section, and then an exception is thrown with the uninitialized "re" variable.

2 3

[config] Compiler warning: 1.32 release
by Jody Hagins 23 Nov '04

23 Nov '04

Several similar warnings for each of... PRINT_ORDER(short); PRINT_ORDER(int); PRINT_ORDER(long); because the comparison in the "for" loop of print_byte_order() is comparing "i" of type T against the return of sizeof() which is unsigned... /home/jody/boost_1_32_0/libs/config/test/config_info.cpp: In function `void regex_lib_print_byte_order(const char*, T) [with T = short int]': /home/jody/boost_1_32_0/libs/config/test/config_info.cpp:723: instantiated from here /home/jody/boost_1_32_0/libs/config/test/config_info.cpp:74: warning: comparison between signed and unsigned integer expressions /home/jody/boost_1_32_0/libs/config/test/config_info.cpp:80: warning: comparison between signed and unsigned integer expressions /home/jody/boost_1_32_0/libs/config/test/config_info.cpp:84: warning: comparison between signed and unsigned integer expressions

2 1

[Boost-bugs] [ boost-Support Requests-1071583 ] building date_time boost_1_32_0
by SourceForge.net 23 Nov '04

23 Nov '04

Support Requests item #1071583, was opened at 2004-11-23 10:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1071583&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: vbdevnet (vbdevnet) Assigned to: Nobody/Anonymous (nobody) Summary: building date_time boost_1_32_0 Initial Comment: Hi I need to build date_time boost_1_32_0 for .NET 2003 Here is dos build command line and output: D:\some_path\boost_1_32_0>bjam -sTOOLS="vc-7_1- stlport" -sBUILD="<stlport-iostream>on" - sSTLPORT_PATH="D:\some_path" --with-date_time stage ...found 641 targets... ...updating 12 targets... vc-C++ bin\boost\libs\date_time\build\boost_date_time.dll\vc- 7_1-stlport\debug\threading-multi\greg_month.obj greg_month.cpp D:\_Vlad_Job\boost_1_32_0\boost\lexical_cast.hpp (150) : error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'boost::date_time::date_names_put<Config,charT,O utputIterator>::string_type' (or there is no acceptable conversion) with [ Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=_STL::ostreambuf_iterator<wchar_t,_STL ::char_traits<wchar_t>> ] D:\_Vlad_Job\boost_1_32_0\boost\lexical_cast.hpp (189) : see reference to function template instantiation 'bool boost::detail::lexical_stream<Target,Source>::operator >><Target>(InputStreamable &)' being compiled with [ Target=boost::date_time::date_names_put<boost::grego rian::greg_facet_config,wchar_t,_STL::ostreambuf_iterat or<wchar_t,_STL::char_traits<wchar_t>>>::string_type, Source=const char *, InputStreamable=boost::date_time::date_names_put<bo ost::gregorian::greg_facet_config,wchar_t,_STL::ostrea mbuf_iterator<wchar_t,_STL::char_traits<wchar_t>>>::s tring_type ] D:\_Vlad_Job\boost_1_32_0 \boost\date_time\date_names_put.hpp(126) : see reference to function template instantiation 'Target boost::lexical_cast<boost::date_time::date_names_put< Config,charT,OutputIterator>::string_type,const char*> (Source)' being compiled with [ Target=boost::date_time::date_names_put<boost::grego rian::greg_facet_config,wchar_t,_STL::ostreambuf_iterat or<wchar_t,_STL::char_traits<wchar_t>>>::string_type, Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=_STL::ostreambuf_iterator<wchar_t,_STL ::char_traits<wchar_t>>, Source=const char * Any suggestions ? PS: All other libs (thread, regex, test etc) build Ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1071583&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

C++/Tcl
by Maciej Sobczak 23 Nov '04

23 Nov '04

Hi, I have just released the 1.0.0 version of my library for integration between C++ and Tcl scripting language: http://cpptcl.sourceforge.net/ This library may be of some interest to Boosters, since: - it was inspired by Boost.Python and shamelessy mimicks its syntax ;) - there are people working on Boost.Langbinding that may find C++/Tcl concepts more or less interesting (I do not see my posts in their maillist archive) - it uses some of Boost - it itself has high ACBR ("angle/curly brackets ratio") Your comments are welcome, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

1 0

[serialization] Compiler warnings: 1.32 release
by Jody Hagins 23 Nov '04

23 Nov '04

Many, many warnings of the following type (g++ 3.2)... /home/jody/boost_1_32_0/libs/serialization/src/basic_iarchive.cpp: In member function `bool boost::archive::detail::basic_iarchive_impl::track(boost::archive::deta il::basic_iarchive&, void*&)': /home/jody/boost_1_32_0/libs/serialization/src/basic_iarchive.cpp:291: warning: choosing `boost::archive::object_id_type::operator unsigned int&()' over ` boost::archive::object_id_type::operator unsigned int() const' /home/jody/boost_1_32_0/libs/serialization/src/basic_iarchive.cpp:291: warning: for conversion from `boost::archive::object_id_type' to `unsigned int' /home/jody/boost_1_32_0/libs/serialization/src/basic_iarchive.cpp:291: warning: because conversion sequence for the argument is better /home/jody/boost_1_32_0/libs/serialization/src/basic_iarchive.cpp: In member function `void boost::archive::detail::basic_iarchive_impl::load_object(boost::archive ::detail::basic_iarchive&, void*, const boost::archive::detail::basic_iserializer&)':

3 5

[Boost-bugs] [ boost-Support Requests-1071409 ] Add Boost folder to VS directory list
by SourceForge.net 23 Nov '04

23 Nov '04

Support Requests item #1071409, was opened at 2004-11-22 18:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1071409&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add Boost folder to VS directory list Initial Comment: Dear Mr/s, I'm doing a program in C#, visual Studio.net environment. I need to generate random numbers, not just from the system class, but others like mersenne twister, fobinacci etc. The Boost library has a set of random number generators in C++, so I downloaded the "boost" from boost.org page. My program in C# has a wrapper to use the generators from the boost folder, the "reference" (boost) and the corresponding "using boost". My problem is how to add the "boost" folder to the list of include directories in VS so that the "reference" in my C# project can find it. If you know how, could you please indicate me the steps. Thanks for attention Sergio Almonacid Oregon State University almonacs(a)onid.orst.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1071409&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: RE: [boost] Another logo proposal
by JOAQUIN LOPEZ MU?Z 23 Nov '04

23 Nov '04

----- Mensaje original ----- De: Robert Geiman <rgeiman(a)buckeye-express.com> Fecha: Martes, Noviembre 23, 2004 0:55 am Asunto: Re: RE: [boost] Another logo proposal > ---- Original Message ---- > From: joaquin(a)tid.es > To: boost(a)lists.boost.org > Subject: Re: RE: [boost] Another logo proposal > Date: Tue, 23 Nov 2004 00:19:53 +0100 > > >I think this is what you've got in mind. > >Myself, I don't like it much. Not so compact, and > >the "C++" thing becomes too obvious. But well, this > >is just my opinion, of course. > > Close, but not quite what I was thinking. The version you created > goes below this bottom of the first +, which as you said makes it > less compact. > > Take that bottom C part and puch it up one "block", making sure you > keep the + sign on top of the background. In essence, you'd really > just be adding a single block of background in the lower left gap of > the first +, and another block to the lower right gap of the first +, > if that makes any sense. > Like this? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Spirit] What changed in spirit 1.8.1?
by Marcin Kalicinski 23 Nov '04

23 Nov '04

How can I find out what changed from 1.8.0 to 1.8.1 in Spirit? I could not find any changelog in the docs. Best regards, Marcin

2 1

Re: RE: [boost] Another logo proposal
by Robert Geiman 22 Nov '04

22 Nov '04

---- Original Message ---- From: joaquin(a)tid.es To: boost(a)lists.boost.org Subject: Re: RE: [boost] Another logo proposal Date: Tue, 23 Nov 2004 00:19:53 +0100 > > >> Yes, I like the simplicity a lot. However, I'd also make a slight >> change to the background of the ++. Could you remove the lower >right >> background of the ++, and instead mirror the upper left background >> vertically. That is, the background would appear in the upper and >> lower left area of the ++. >> >> To me this would look better as the background would look like the >> letter C, which would go nicely with the ++. >> > >I think this is what you've got in mind. >Myself, I don't like it much. Not so compact, and >the "C++" thing becomes too obvious. But well, this >is just my opinion, of course. Close, but not quite what I was thinking. The version you created goes below this bottom of the first +, which as you said makes it less compact. Take that bottom C part and puch it up one "block", making sure you keep the + sign on top of the background. In essence, you'd really just be adding a single block of background in the lower left gap of the first +, and another block to the lower right gap of the first +, if that makes any sense. - Robert Geiman

1 0

Re: [boost] Re: Another logo proposal
by JOAQUIN LOPEZ MU?Z 22 Nov '04

22 Nov '04

----- Mensaje original ----- De: Daniel Frey <d.frey(a)gmx.de> Fecha: Lunes, Noviembre 22, 2004 11:43 pm Asunto: [boost] Re: Another logo proposal > JOAQUIN LOPEZ MU?Z wrote: > > You mean, like the version attached? > > I don't know, it kind of looks too irregularly shaped. Not > > so blocky as the other designs. > > Hm, no offense intended, but this logo seems more appropriate for > a > mortician. YMMV. :) > LOL :) What do you make of this, then? http://tinyurl.com/59y5z Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: RE: [boost] Another logo proposal
by JOAQUIN LOPEZ MU?Z 22 Nov '04

22 Nov '04

----- Mensaje original ----- De: Robert Geiman <rgeiman(a)buckeye-express.com> Fecha: Lunes, Noviembre 22, 2004 11:49 pm Asunto: RE: [boost] Another logo proposal > Yes, I like the simplicity a lot. However, I'd also make a slight > change to the background of the ++. Could you remove the lower right > background of the ++, and instead mirror the upper left background > vertically. That is, the background would appear in the upper and > lower left area of the ++. > > To me this would look better as the background would look like the > letter C, which would go nicely with the ++. > I think this is what you've got in mind. Myself, I don't like it much. Not so compact, and the "C++" thing becomes too obvious. But well, this is just my opinion, of course. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: Another logo proposal
by JOAQUIN LOPEZ MU?Z 22 Nov '04

22 Nov '04

Hi Rich ----- Mensaje original ----- De: Rich Johnson <rjohnson(a)dogstar-interactive.com> Fecha: Lunes, Noviembre 22, 2004 8:57 pm Asunto: Re: [boost] Re: Another logo proposal > > I like the stair-step imagery of the second .png- (the one with no > backing field) > It's a nice play on the use of building blocks. I think it still > carries a blocky, solid/stable feel. > > Is there a single color restriction for ease of printing? If not > adding a third '+' in a different color (or perhaps in outline) > would > further emphasize building on C++. You mean, like the version attached? I don't know, it kind of looks too irregularly shaped. Not so blocky as the other designs. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

boost.thread : Can one create a thread with an object member function?
by Tim Laplaca 22 Nov '04

22 Nov '04

I am very new to boost, I apologize if this has been asked before. I searched the mailing list archive but could not find an answer to my question. I was successful creating threads with functions that are not members of objects, but when I try to create threads with a pointer to an object member I get compilation errors (MS Visual Studio .NET). Examples: class objclass; typedef void (objclass::*pmf)(); // ptr to member func class objclass { public: objclass() : thread_id (0) { p=&objclass::dowork; } inline setthreadid(int x) {thread_id = x;} inline setvaltwo(std::string str) {valtwo = str;} void dowork(); pmf p; // pointer to dowork member function int getthreadid() {return thread_id;} std::string getvaltwo() {return valtwo;} private: int thread_id; std::string valtwo; }; void objclass::dowork() { } (In the main...) boost::thread_group thrds; objclass * objthread; objthread = new objclass; thrds.create_thread( (objthread->p) ); I get the following error: c:\Boost\include\boost-1_31\boost\function\function_template.hpp(427): error C2664: 'void boost::function0<R>::assign_to<Functor>(FunctionPtr,boost::detail::funct ion::function_ptr_tag)' : cannot convert parameter 2 from 'boost::detail::function::member_ptr_tag' to 'boost::detail::function::function_ptr_tag' with [ R=void, Functor=pmf, FunctionPtr=pmf ] Is there a way around this problem, or is it simply not possible to make threads from object members with boost? Thanks, Tim

3 2

RE: [boost] Another logo proposal
by Robert Geiman 22 Nov '04

22 Nov '04

---- Original Message ---- From: joaquin(a)tid.es To: boost(a)lists.boost.org Subject: RE: [boost] Another logo proposal Date: Mon, 22 Nov 2004 16:49:12 +0100 >Here's my take. I'm providing b/w and color versions. The idea >is to provide an abstract logo to associate with Boost while >retaining >the visual link with the previous artwork (through using the same >Impact font for the name, a very appropriate font IMHO.) >Some more rationales behind the proposal: > >* It can be easily rasterized. >* It goes well with flat backgrounds. >* It works as a transition from the old logo. > >As for the logo itself, it tries to convey the following >connotations: > >* Its square shape, and the fact that is bottom aligned >with the text, gives a sense of solidness. >* It reminds the reader of a set of construction toolkit >pieces, which associates well with Boost being a repository of >general purpose libraries. >* The "++" part of C++ is retained, integrated into the >logo. Going a little pedantic, one can even recognize >the logo as a deconstruction of "C++", where the L-shaped >pieces are the two halves of an upper "C", split and shifted. > >Dya like it? Yes, I like the simplicity a lot. However, I'd also make a slight change to the background of the ++. Could you remove the lower right background of the ++, and instead mirror the upper left background vertically. That is, the background would appear in the upper and lower left area of the ++. To me this would look better as the background would look like the letter C, which would go nicely with the ++. - Robert Geiman

1 0

[serialization] std::set compile errors
by Jeff Flinn 22 Nov '04

22 Nov '04

Robert, boost 1.32, with VC7.1 I'm getting compiler errors in two unrelated translation units both dealing with std::set<std::string> data members. I've gone through and ensured that i've #include'd the <set.hpp> and <string.hpp> headers from boost/serialization. Any ideas on what might be causing this problem? This has worked fine previously with boost 1.31 and serialization20 version of the library. Why would the 3 argument overload not be found? Below are the (beginnings of the ) related compiler errors. Thanks, Jeff ======================== C:\boost\boost_1_32_0\boost\serialization\split_free.hpp(55) : error C2780: 'void boost::archive::load(Archive &,T &)' : expects 2 arguments - 3 provided C:\boost\boost_1_32_0\boost\archive\detail\iserializer.hpp(514) : see declaration of 'boost::archive::load' C:\boost\boost_1_32_0\boost\serialization\split_free.hpp(54) : while compiling class-template member function 'void boost::serialization::free_loader<Archive,T>::invoke(Archive &,T &,const unsigned int)' with [ Archive=boost::archive::text_iarchive, T=std::set<std::string> ] .... ======================== C:\boost\boost_1_32_0\boost\serialization\split_free.hpp(55) : error C2780: 'void boost::archive::load(Archive &,T &)' : expects 2 arguments - 3 provided C:\boost\boost_1_32_0\boost\archive\detail\iserializer.hpp(514) : see declaration of 'boost::archive::load' C:\boost\boost_1_32_0\boost\serialization\split_free.hpp(54) : while compiling class-template member function 'void boost::serialization::free_loader<Archive,T>::invoke(Archive &,T &,const unsigned int)' with [ Archive=boost::archive::binary_iarchive, T=std::set<std::string> ] ....

1 0

[serialization] and macro 'max' compiler warning on VC71
by Jeff Flinn 22 Nov '04

22 Nov '04

I've just tried to move to 1.32 and get the following warning: C:\boost\boost_1_32_0\boost\archive\basic_binary_oprimitive.hpp(101) : warning C4003: not enough actual parameters for macro 'max' which points to: assert( static_cast<std::size_t>(std::numeric_limits<std::streamsize>::max()) >= count ); Any suggestions on avoiding this with an MFC based project? Thanks, Jeff

3 4

[assign] documentation - bugs in examples
by Anton Gutsunaev 22 Nov '04

22 Nov '04

Some examples in <boost>/libs/assign/doc/index.html file print "Assertion failed" message or cannot be compiled. <boost>/libs/assign/doc/index.html#operator+= vector<int> values; values += 1,2,3,4,5,6,7,8,9; // insert values at the end of the container BOOST_ASSERT( values.size() == 9 ); BOOST_ASSERT( values[0] == 1 ); BOOST_ASSERT( values[9] == 9 );// <---must be "values[8]" <boost>/libs/assign/doc/index.html#operator() map<string,int> months; insert( months ) ( "january", 31 )( "february", 28 ) ( "march", 31 )( "april", 30 ) ( "may", 31 )( "june", 30 ) ( "july", 31 )( "august", 31 ) ( "september", 30 )( "october", 31 ) ( "november", 30 )( "december", 31 ); BOOST_ASSERT( m.size() == 12 ); //<---change "m" to "months" BOOST_ASSERT( m["january"] == 31 ); //<---same here after words "If operator()() is too cumbersome to use with eg. push_front()we can also say": deque<int> di; push_front( di ) = 1,2,3,4,5,6,7,8,9; BOOST_ASSERT( di.size() == 9 ); BOOST_ASSERT( di[8] == 9 );//<-- must be di[8]==1 or di[0]==9 because of push_front <boost>/libs/assign/doc/index.html#list_of: const stack<string> names = list_of( "Mr. Foo" )( "Mr. Bar")( "Mrs. FooBar" ).to_adapter(); const stack<string> names2 = (list_of( "Mr. Foo" ), "Mr. Bar", "Mrs. FooBar" ).to_adapter(); BOOST_ASSERT( names.size() == 3 ); BOOST_ASSERT( names[0] == "Mr. Foo" ); //<---can't use operator [] with stack BOOST_ASSERT( names[2] == "Mrs. FooBar" ); //<---same here example after words "A more general list can be constructed with repeat_fun()": template< class T > struct next { T seed; next( T seed ) : seed(seed) { } T operator()() const //<---remove const or declare "T seed" as mutable { return seed++; } };

2 1

[TYPO] Assignment Library
by Javier Estrada 22 Nov '04

22 Nov '04

Under the Reference section, the sentence: Originally const references was used, but it lead to many problems with string-literals. Should read: Originally const references were used, but it led to many problems with string-literals.

2 1

Typo in Assignment Library documentation
by Javier Estrada 22 Nov '04

22 Nov '04

In http://www.boost.org/libs/assign/doc/index.html there is a typo under the Introduction section. The sentence: These two operators makes it possible to construct lists of values which are then copied into a container: Should read: These two operators make it possible to construct lists of values which are then copied into a container:

3 2

[thread] Compiler warnings: 1.32 release
by Jody Hagins 22 Nov '04

22 Nov '04

Compiler warnings, g++ 3.2... /home/jody/boost_1_32_0/libs/thread/src/recursive_mutex.cpp: In member function `boost::recursive_mutex::recursive_mutex()': /home/jody/boost_1_32_0/libs/thread/src/recursive_mutex.cpp:299: warning: unused variable `int res' /home/jody/boost_1_32_0/libs/thread/src/recursive_mutex.cpp: In member function `boost::recursive_try_mutex::recursive_try_mutex()': /home/jody/boost_1_32_0/libs/thread/src/recursive_mutex.cpp:455: warning: unused variable `int res' gcc-C++-action /home/jody/boost_1_32_0/bin/bin/boost/libs/thread/build/libboost_thread .so/gcc/release/shared-linkable-true/threading-multi/read_write_mutex.o /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:943: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:101: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:943: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:114: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:943: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:127: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_write_lock() [with Mutex = boost::mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:948: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:170: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:948: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:187: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:948: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:205: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_promote_to_writ e_lock() [with Mutex = boost::mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:968: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:678: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::try_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:983: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:101: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:983: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:114: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:983: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:127: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_write_lock() [with Mutex = boost::try_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:988: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:170: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:988: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:187: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:988: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:205: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_promote_to_writ e_lock() [with Mutex = boost::try_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1024: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:678: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::timed_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1044: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:101: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1044: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:114: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1044: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:127: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_write_lock() [with Mutex = boost::timed_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1049: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:170: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1049: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:187: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1049: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:205: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `bool boost::detail::thread::read_write_mutex_impl<Mutex>::do_timed_read_lock (const boost::xtime&) [with Mutex = boost::timed_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1075: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:353: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1075: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:371: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1075: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:389: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `bool boost::detail::thread::read_write_mutex_impl<Mutex>::do_timed_write_loc k(const boost::xtime&) [with Mutex = boost::timed_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1080: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:469: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1080: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:491: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1080: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:514: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_promote_to_writ e_lock() [with Mutex = boost::timed_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1100: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:678: warning: unused variable `int loop_count' /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp: In member function `bool boost::detail::thread::read_write_mutex_impl<Mutex>::do_timed_promote_t o_write_lock(const boost::xtime&) [with Mutex = boost::timed_mutex]': /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:1110: instantiated from here /home/jody/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:770: warning: unused variable `int loop_count' gcc-C++-action /home/jody/boost_1_32_0/bin/bin/boost/libs/thread/build/libboost_thread .so/gcc/release/shared-linkable-true/threading-multi/thread.o

1 0

possible date-time documentation bug
by Pavol Droba 22 Nov '04

22 Nov '04

Hi, It seems that there is a bug in the date time documentation Documentation says this: " To use the alternate resolution (64 bit microsecond) the variable BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG must be defined in the library users project files (ie Makefile, Jamfile, etc). This macro is not used by the Gregorian system and therefore has no effect when building the library." But in reality, the negation is actualy true. 64bit precision is used when this macro is NOT defined. In addition there is a slight problem with posix_time::microseconds() (and possibly with other similar function as well). Somewhere along the way, parameter is converted to long. This might cause some problems, since the resolution is larger (64bit). For instance time_duration::total_microseconds() returns 64bit integer. If the return value is used to initialize a duration of that lenght, overflow occurs. I'm using current cvs version of boost. Regards, Pavol

2 1

[Boost-bugs] [ boost-Support Requests-1071040 ] Static linking boost::thread, vc-7_1-stlport
by SourceForge.net 22 Nov '04

22 Nov '04

Support Requests item #1071040, was opened at 2004-11-22 07:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1071040&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Static linking boost::thread, vc-7_1-stlport Initial Comment: bjam -sTOOLS="vc-7_1-stlport" -sBUILD="<stlport-iostream>on" -sSTLPORT_PATH="D:\path" --with-thread stage When builded libboost_thread-vc71-mt-sgdp-1_32.lib contain ref: ??0thread@boost@@QAE@ABV?$function0@XV?$allocator@Vfunction_base@boost@@@_STL@@@1@@Z Is there any way to rebuild thread so libboost_thread-vc71-mt-sgdp-1_32.lib will contain ref: __imp_??0thread@boost@@QAE@ABV?$function0@XV?$allocator@Vfunction_base@boost@@@_STL@@@1@@Z (__imp_ added) ? Thank you ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1071040&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost.Build V2 logo wanted
by Vladimir Prus 22 Nov '04

22 Nov '04

Boost.Build V2 is in need of a good logo. The one used now on http://boost.org/boost-build2 is the C++ Boost logo, which is not accurate and confusing. I'd very appreciate any contribution! There's no requirements what should be on the logo, only two preferences: - vector format (or a very large bitmap file) - one version of logo should include "Boost.Build" text. Ideally, there would be two versions, with and without the text, but with the same graphical elements. Right at the moment we're also discussing new C++ logo. While it would be cool to have some common graphics elements, it's OK for Boost.Build logo to be completely different. Thanks in advance, Volodya

1 0

gcc4 not recognized
by Neal D. Becker 22 Nov '04

22 Nov '04

Attempting to use boost with gcc4 says version not recognized. I ran configure. BTW, configure should be chmod +x. Here is the result:

2 1

[Review] Named Parameters library (ongoing)
by Doug Gregor 22 Nov '04

22 Nov '04

Today is the last day of the review of the Named Parameters library by David Abrahams and Daniel Wallin. Let's hear some more comments! The original announcement follows: The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

1 0

[patch] [shared_ptr] out-of-date comment
by Jonathan Wakely 22 Nov '04

22 Nov '04

The attached patch removes an old comment from shared_count.hpp that refers to initial_use_count and initial_weak_count. Those parameters were removed from the constructor a while ago. jon -- "Whenever you find that you are on the side of the majority, it is time to reform." - Mark Twain

2 1

[TYPO] MinMax Library
by Javier Estrada 22 Nov '04

22 Nov '04

Under the Motivation section, the sentence: Please note: the intent is not to fix the known defaults of std::min and std::max, but to add one more algorithms that combines both; Should read: Please note: the intent is not to fix the known defaults of std::min and std::max, but to add one more algorithm that combines both;

2 1

shared_ptr and serialization
by Robert Ramey 22 Nov '04

22 Nov '04

Would it be possible to add something like friend template<class Archive> boost::serialization::serialize(Archive &ar, T &t); to boost::shared_ptr ? This would let me remove a problematic hack in boost/serialization/shared_ptr which is creating a headache when shared_ptr serialization is used with some other headers. The same may be necessary for some other headers - e.g. weak ptr. Another alternative would be to change the private members to protected or maybe even public. I realize that this creates a dependency between boost::serialization and boost:: shared_ptr that you have hoped to avoid. But until this is resolved at another level, its would be better than the current situation. Alternatively, you might want to consider expanding the shared_ptr interface with enough information to permit serialization to be implemented via the public interface. This has worked well for the stl collections. I don't know if this was an intentional design decision or just an accident. We really need a real solution now for boost::shared_ptr / boost::serialization . Robert Ramey

9 33

[Boost-bugs] [ boost-Support Requests-1070583 ] boost_1_32_0: Cant build date_time
by SourceForge.net 21 Nov '04

21 Nov '04

Support Requests item #1070583, was opened at 2004-11-21 12:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1070583&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost_1_32_0: Cant build date_time Initial Comment: boost_1_32_0 bjam -sTOOLS="vc-7_1" --with-date_time stage ...found 447 targets... ...updating 34 targets... vc-C++ bin\boost\libs\date_time\build\boost_date_time.dll\vc- 7_1-stlport\debug\threading-multi\greg_month.obj greg_month.cpp C:\_Vlad_Job\boost_1_32_0\boost\lexical_cast.hpp (150) : error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'boost::date_time::date_names_put<Config,charT,O utputIterator>::string_type' (or there is no acceptable conversion) with [ Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=std::ostreambuf_iterator<wchar_t,std::c har_traits<wchar_t>> ] C:\_Vlad_Job\boost_1_32_0\boost\lexical_cast.hpp (189) : see reference to function template instantiation 'bool boost::detail::lexical_stream<Target,Source>::operator >><Target>(InputStreamable &)' being compiled with [ Target=boost::date_time::date_names_put<boost::greg orian::greg_facet_config,wchar_t,std::ostreambuf_iterat or<wchar_t,std::char_traits<wchar_t>>>::string_type, Source=const char *, InputStreamable=boost::date_time::date_names_put<bo ost::gregorian::greg_facet_config,wchar_t,std::ostream buf_iterator<wchar_t,std::char_traits<wchar_t>>>::strin g_type ] C:\_Vlad_Job\boost_1_32_0 \boost\date_time\date_names_put.hpp(126) : see reference to function template instantiation 'Target boost::lexical_cast<boost::date_time::date_names_put< Config,charT,OutputIterator>::string_type,const char*> (Source)' being compiled with [ Target=boost::date_time::date_names_put<boost::greg orian::greg_facet_config,wchar_t,std::ostreambuf_iterat or<wchar_t,std::char_traits<wchar_t>>>::string_type, Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=std::ostreambuf_iterator<wchar_t,std::c har_traits<wchar_t>>, Source=const char * ] C:\_Vlad_Job\boost_1_32_0 \boost\date_time\date_names_put.hpp(122) : while compiling class-template member function 'void boost::date_time::date_names_put<Config,charT,Output Iterator>::do_put_special_value (boost::date_time::date_names_put<Config,charT,Outpu tIterator>::iter_type &,boost::date_time::date_names_put<Config,charT,Outp utIterator>::special_value_enum) const' with [ ... etc Any suggestions how to fix this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1070583&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[mpl] replace_if
by Jonathan Turkanis 21 Nov '04

21 Nov '04

Hi Aleksey, The new MPL document is very nice! I believe the synopsis for replace_if (http://www.boost.org/libs/mpl/doc/refmanual/replace-if.html) is missing the third template parameter. Is that correct? Jonathan

2 3

Can I get the function signature of the result of a bind() ?
by Roland Schwarz 21 Nov '04

21 Nov '04

Sorry if my question seems somehow weird. I already posted a similar one to the users list but with no result. So I try again but also post a small example to make my question clear. The purpose of the example is to autoconnect a couple of member classes to a containing class without the need to explicitely call the constructors of the member classes: #include <boost/signal.hpp> #include <boost/any.hpp> #include <boost/bind.hpp> boost::any pinit; // todo: should be thread local in MT version template<typename Function> struct ctor_signal_push : public boost::signal<Function>{ ctor_signal_push() { pinit = this; } // todo: make it a stack }; template<typename Signature, typename Function> void ctor_connect(Function fn) { boost::any_cast<ctor_signal_push<Signature>* >(pinit)->connect(fn); // can this be done without the Signature parameter? // i.e. can the Signature be deduced from Function? (which might be a functor) } class A; class B { public: B() { ctor_connect<void (A*)>(boost::bind(init, this, _1)); } void init(A* p) { pOuter = p; }; A* pOuter; }; class C { public: C() { ctor_connect<void (A*)>(boost::bind(init, this, _1)); } void init(A* p) { pOuter = p; }; A* pOuter; }; class A { public: A(); ctor_signal_push<void (A*)> init; B aB; C aC; B aB1; B aB2; // ctor_signal_pop; }; A::A() { init(this); // connect all member classes } int main(int argc, char* argv[]) { A aA; return 0; } This does work well so far, but I would like to get rid of the explicit "void (A*)" parameter in ctor_connect<void (A*)>(boost::bind(init, this, _1)); Is this possible? Perhaps I am even trying to do something that I should better avoid because there is a better solution available. Does anyone know? Thank you for any hints, Roland

1 0

Re: [boost] Re: Front page redesign...
by JOAQUIN LOPEZ MU?Z 21 Nov '04

21 Nov '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Noviembre 21, 2004 4:29 pm Asunto: Re: [boost] Re: Front page redesign... [...] > I'll have some additional thoughts on content organization if I > can ever get > finished with my OOPSLA workshop writeup. We had some specific > discussionsabout content changes that need to be made... > Dou you have any idea when you'll have this done? I'm very much interested in knowing what the workshop came up with (as most of us here at the list, I guess.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: Re: Re: shared_ptr and serialization
by Dave Gomboc 21 Nov '04

21 Nov '04

> Honestly, I don't need to serialize std::tr1::shared_ptr - why would > any of us ever use it as long as we have boost::shared_ptr which (with > serialization is a superset of std::tr1::shared_ptr.) That's a completely bogus argument. > I understand your objection to boost::serialization depending upon the > implementation details of boost::shared_ptr. I just don't see any way to > address this other than making big changes to either the serialization > libary or shared_ptr. Even then, its not obvious to me that its even > possible. Doesn't Peter's own serialization library succeed in not requiring special access to boost::shared_ptr? If so, it is an existence proof that there's a way to do it, which I think means that big changes may need to be made to Boost.Serialization. It will be a reasonable expectation for a Boost.Serialization user to serialize std::tr1::shared_ptrs in the future. Has Peter described the algorithm he used? Dave

3 2

[name_params] Flag arguments?
by Rene Rivera 21 Nov '04

21 Nov '04

Dave, Daniel, I have a use case which would be nice to support. I have some functions which take some number of flag arguments, akin to: void foo(const char * name, float value, bool flag1 = false, bool flag2 = false) { std::cout << name << " = " << value << "\n"; } And I can add the named arg interface, so I can use it as: foo((value = 5.2f, name = "baz", flag1 = true)); But ideally I'd like the use to look like: foo((value = 5.2f, name = "baz", flag1)); That is, the presence of the keyword is enough to set the argument to true. Possible? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 2

RE: [boost] preprocessor fix
by Arias Brent-P96059 21 Nov '04

21 Nov '04

>Not a bug. Empty macro arguments are currently undefined behavior in C++. There is nothing that I can do about that. C99 added explicit support for them, but they are not (yet) part of C++. I very much appreciate your answer. And ultimately this hasn't become a big deal, since - as you saw - I found a way around the problem all the same. But now let me answer a very good question you asked: > #define ENUM(name, start, entries)\ > BOOST_PP_SEQ_ENUM( \ > BOOST_PP_IIF(ENUMS, \ > (typedef enum{ BOOST_PP_SEQ_HEAD(entries) = start) \ > BOOST_PP_SEQ_TAIL(entries) \ > (LAST_##name } name;) \ > , \ > (static void PP_NILFUNC();) \ > ) \ > ) >Why are you doing the test *inside* of the invocation of SEQ_ENUM? The short answer: I wanted a **single** ENUM macro definition that permitted the printable strings *AND* the enums themselves to be conditionally compileable. I think my intention will make more sense if I show you the entire printable enum. It looks like this: #ifndef ENUMS /*By default, turn enums on*/ #define ENUMS 1 #endif #ifndef ESTRINGS /*By default, turn printable strings on*/ #define ESTRINGS 1 #endif #ifndef EDEBUG #define EDEBUG 0 /*By default, turn ESTRINGS "compliment" condition off */ #endif /*Used internally by the ENUM macro*/ #ifdef ENUM_STR #undef ENUM_STR #endif #define ENUM_STR(r, data, elem) BOOST_PP_STRINGIZE(elem) #define ENUM(name, start, entries) \ BOOST_PP_SEQ_ENUM( \ BOOST_PP_IIF(ENUMS, \ (typedef enum{ BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_##name } name;) \ , \ (static void PP_NILFUNC();) \ ) \ ) \ BOOST_PP_SEQ_ENUM( \ BOOST_PP_IIF(BOOST_PP_BITOR(EDEBUG,ESTRINGS), \ (static const char* name##_Str[]={ BOOST_PP_STRINGIZE(BOOST_PP_SEQ_HEAD(entries)) ) \ BOOST_PP_SEQ_TRANSFORM(ENUM_STR, _, BOOST_PP_SEQ_TAIL(entries) ) \ (};) \ , \ (static void PP_NILFUNC();) \ ) \ ) Now, as I think you pointed out yourself, you can't place the BOOST_PP_SEQ_ENUM inside of a BOOST_PP_EXPR_IIF statement like this: #define ENUM(name, start, entries) \ BOOST_PP_EXPR_IIF(ENUMS)( \ BOOST_PP_SEQ_ENUM( \ (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_ ## name } name;) \ ) \ ) \ So, what I've shown you in the printable enum above was the only solution I could think of to achieve the result: i.e. a **single** ENUM macro definition that permitted the printable strings *AND* the enums themselves to be conditionally compileable. On the other hand, I'm intrigued with what you presented here: #define ENUM(name, start, entries) \ BOOST_PP_IIF( \ ENUMS, \ BOOST_PP_SEQ_ENUM, BOOST_PP_TUPLE_EAT(1) \ )( \ (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_ ## name } name;) \ ) \ I didn't pay attention to BOOST_PP_TUPLE_EAT when I was (frantically) trying to make a printable enum. Perhaps it is a means by which I can get rid of the "hack" I described earlier? It sure looks like it will work! Oh, by the way, I was so pleased with the printable enum - I was actually thinking of submitting it for inclusion into Boost. Would a submission like that be more nuisance than benefit? Thanks, -Brent

2 1

[Boost-bugs] [ boost-Bugs-1070327 ] vc-7_1-stlport native-wchar_t problem
by SourceForge.net 21 Nov '04

21 Nov '04

Bugs item #1070327, was opened at 2004-11-20 23:09 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=1070327&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: vc-7_1-stlport native-wchar_t problem Initial Comment: There is a problem with "tools/build/v1/vc-7_1- stlport.tools.jam". I tried to build boost 1.32.0 with jam optioned as "- snative-wchar_t=on". But cl option didn't include a '/Zc:wchar_t'. :( Therefore, i modified "tools/build/v1/vc-7_1- stlport.tools.jam" as following (not correct fix, just for workaround) #feature native-wchar_t : off on ; feature native-wchar_t : on off ; Finally it worked! - veblush ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1070327&group_… ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

boost 1.32 acknowledgements
by Bronek Kozicki 21 Nov '04

21 Nov '04

In the acknowledgements section I see my name twice, while I do not see Aleksey Gurtovoy . I understand that our release manager is very modest person, but listing my name (person who did very little for Boost, if anything) and forgetting name of release manager seems wrong. B.

20 47

Build of boost_1_32_0 hangs on MacOS X build
by Steve Hartwell 21 Nov '04

21 Nov '04

Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3? The problem I'm seeing is that while compiling "xml_grammar.cpp", cc1plus slows to a crawl while its virtual memory allocation rises to 1.8GB until my system becomes so unresponsive I have to kill it. Jam then proceeds until the release build of "xml_grammar.cpp", with the same results (cc1plus hanging). Killing that process leads to the same problems in the debug compile of "xml_wgrammar.cpp", as well as the release compile of "xml_wgrammar.cpp". I have observed this problem both with a dual-processor G5 and a single-processor G4. Everything else in the build seems to be proceed OK after I kill the cc1plus processes that hang on "xml_grammar.cpp". The command line I'm using to build is: bjam -sTOOLS=darwin -sBUILD="debug release <runtime-link>static/dynamic" Please let me know if anyone is having better luck with this. Best regards, Steve Hartwell p.s. There is an additional difficulty with the build of boost 'serialization' where some directory names end with ".a" and ".dylib". Although these are legal directory names, this confuses the heck out of the Xcode IDE, and makes it impossible to include the contents of these named directories into an Xcode project. It would be nice if the names of these directories could be changed to end with "_a" and "_dylib" instead, or something similar. p.p.s. boring (but precise) stuff about the cc1plus hang follows: When cc1plus hangs, ps shows the following arguments: /usr/libexec/gcc/darwin/ppc/3.3/cc1plus -quiet -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1666 -D__DYNAMIC__ -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp -D__GNUG__=3 -fPIC -quiet -dumpbase xml_wgrammar.cpp -auxbase-strip bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar o -O3 -Wno-long-double -Wno-inline -Wall -ftemplate-depth-256 -finline-functions -fcoalesce-templates -D__private_extern__=extern -o Since this is all 'ps' is willing to output for this process, here is the parent process, whose arg list seems more complete: c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp

6 8

Library TR draft available
by Beman Dawes 20 Nov '04

20 Nov '04

The latest draft of the C++ Standard Library Technical Report is now available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf There may be editorial (non-substantiative) changes to the final version of the TR document, but this latest draft is believed to be final in terms of technical content. Thus it should be safe for implementors or users to write code based on this latest draft. It will be several years before most compilers come with a full implementation of the TR. But some vendors (Metrowerks, for example) are already shipping a few TR components. That brings up the question of what Boost code does during the transition. To insure Boost code works with various TR implementations, some Boost code will want to use the compiler vendor's version of the TR if the TR component required is available, but otherwise will want to use Boost equivalent code. How do we handle that? The TR doesn't provide in configuration macros, so I guess we will have to roll our own. --Beman

7 17

RE: [boost] GUI validation [was: GUI Library Proposal for a Proposal]
by Arias Brent-P96059 20 Nov '04

20 Nov '04

I have not been paying attention to any of the GUI posts - until now. So I havn't the slightest idea if my comment is relevant. Here it goes: >** events, propagation and handling mechanisms, (event_target, listener, >subscribers...) I've never seen an "events, propagation, handling" mechanism as elegant as Miro Samek's Quantum Framework / Quantum Hierarchical State Machine. If there are any reading this who have not heard of it - you'd do well to buy his book and "settle in". At work we're using it for an embedded software defined radio, and at home I intend on using it for GUI/DirectX development. -Brent

1 0

tarball build doc issue
by Jared McIntyre 19 Nov '04

19 Nov '04

The documentation for bjam setup in more/getting_started.html says to "chdir boost-1.31.0" as a possible place to you may have installed boost. Should this be made 1.32.0? Jared McIntyre

2 1

[jamboost] [fsm] gcc-3.4.x patches
by Juergen Hunold 19 Nov '04

19 Nov '04

Hi ! The attached patch fixes the last problems with gcc-3.4.1 due to missing "template" keywords. Tested against gcc-3.3.4 (SuSE-9.2) Andreas, I tried to sent you my V2 jamfiles to your yahoo.com address, but did not get a reply from you. Is that a throw-away address ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de ------------------------ Yahoo! Groups Sponsor --------------------~--> $9.95 domain names from Yahoo!. Register anything. http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/z3wwlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/jamboost/ <*> To unsubscribe from this group, send an email to: jamboost-unsubscribe(a)yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

3 5

Macro for using overloaded functions with templated code.
by Daniel James 19 Nov '04

19 Nov '04

I've written a macro (the implementation is attached) for generating a function object for using overloaded functions with generic code such as the STL algorithms and boost::bind. A simple example of it's use: void foo(int); void foo(char*); GENERATE_OVERLOADED(void, foo); int main() { int values[] = { 1, 2, 3, 4 }; std::for_each(values, values+4, foo_overloaded); } GENERATE_OVERLOADED (yes, the naming is pretty bad) creates an object called which contains overloaded calls to operator() which forward to the named functions. Something like: struct foo_overloaded_type { void operator() const { return foo(); } template <class T1> void operator(T1 const& p1) const { return foo(p1); } template <class T1, class T2> void operator(T1 const& p1, T2 const& p2) const { return foo(p1, p2); } // etc. } foo_overloaded; The main advantage is that you don't have to select the desired overload. It can also be useful when different calls will have different argument types such as iterating over a tuple in fusion (I guess you could call it a visitor). Any comments on this? Would anyone else find this useful? Also, has anyone done something similar? I'd be surprised if no one has, I always feel like I'm missing something when I'm doing this kind of thing. The implementation is lacking in several ways - it doesn't work for non-const references, the return type is fixed, needs to deal with member functions, namespace issues and so on. I suppose, it could also be better integrated with bind, lambda or pheonix. Daniel

3 8

configure script not executable
by Jonathan Wakely 19 Nov '04

19 Nov '04

The libs/config/config.htm page says you should run /libs/config/configure as "./configure" but the file isn't executable in either CVS or the 1.32.0 release candidate. The docs should be changed as per the attached patch, although it might be too late for 1.32 jon -- "Self-respect: the secure feeling that no one, as yet, is suspicious." - H.L. Mencken

2 3

preprocessor fix
by Arias Brent-P96059 19 Nov '04

19 Nov '04

I've invented a printable enum, based on the Boost preprocessor programming lib. But although the printable enum works, I think my efforts revealed a bug in Boost. The BOOST_PP_SEQ_ENUM preprocessor macro doesn't work with the empty "false" result of BOOST_PP_EXPR_IIF. This has forced me to do hacks like this: #define ENUM(name, start, entries)\ BOOST_PP_SEQ_ENUM( \ BOOST_PP_IIF(ENUMS, \ (typedef enum{ BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_##name } name;) \ , \ (static void PP_NILFUNC();) \ ) \ ) As you can see in the above definition, I've included an explicit "false" clause for BOOST_PP_IIF() that expands into the harmless (and utterly superfluous) expression "static void PP_NILFUNC();". I would instead have preferred to use BOOST_PP_EXPR_IIF and thus avoid the eye-sore. But the hack was necessary, as I said before, because BOOST_PP_SEQ_ENUM does not elogantly handle the empty "false" result of BOOST_PP_EXPR_IIF. Can this be fixed? -Brent

3 3

[Boost-bugs] [ boost-Bugs-1069225 ] date_time type conversion warning
by SourceForge.net 19 Nov '04

19 Nov '04

Bugs item #1069225, was opened at 2004-11-18 21:21 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=1069225&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: date_time type conversion warning Initial Comment: from boost 1.32.0 final draft tarball. d:\development files\boost 1.32.0 \include\boost\date_time\date_parsing.hpp(211) : warning C4244: 'argument' : conversion from '_STL::basic_string<_CharT,_Traits,_Alloc>::value_t ype' to 'char', possible loss of data with [ _CharT=wchar_t, _Traits=_STL::char_traits<wchar_t>, _Alloc=_STL::allocator<wchar_t> ] d:\development files\boost 1.32.0 \include\boost\date_time\date_parsing.hpp(253) : see reference to function template instantiation 'date_type boost::date_time::from_stream_type<date_type,_STL::b asic_string<_CharT,_Traits,_Alloc>::iterator> (iterator_type &,iterator_type &,wchar_t)' being compiled with [ date_type=boost::gregorian::date, _CharT=wchar_t, _Traits=_STL::char_traits<wchar_t>, _Alloc=_STL::allocator<wchar_t>, iterator_type=_STL::basic_string<wchar_t,_STL::char_tr aits<wchar_t>,_STL::allocator<wchar_t>>::iterator ] d:\development files\boost 1.32.0 \include\boost\date_time\gregorian\parsers.hpp(78) : see reference to function template instantiation 'boost::date_time::period<point_rep,duratio n_rep> boost::date_time::from_simple_string_type<boost::grego rian::date,wchar_t>(const _STL::basic_string<_CharT,_Traits,_Alloc> &)' being compiled with [ point_rep=boost::gregorian::date, duration_rep=boost::gregorian::date_duration, _CharT=wchar_t, _Traits=_STL::char_traits<wchar_t>, _Alloc=_STL::allocator<wchar_t> ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1069225&group_… ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[assign] documentation bug
by Caleb Epstein 19 Nov '04

19 Nov '04

In the assign library documentation page <boost>/libs/assign/doc/index.html#repeat: v = list_of(1).repeat(5,2)(3); // v = [1,2,2,2,2,2,3] BOOST_ASSERT( v.size() == 1 + 5 + 3 ); push_back( v )(1).repeat(1,2)(3); // v = old v + [1,2,3] BOOST_ASSERT( v.size() == 12 ); I think the first BOOST_ASSERT should be BOOST_ASSERT (v.size() == 1 + 5 + 1) and the last one should be BOOST_ASSERT( v.size() == 10 ); -- Caleb Epstein caleb.epstein(a)gmail.com

3 3

[1.32] dynamic_bitset docs
by Pavel Vozenilek 19 Nov '04

19 Nov '04

Documentation for dynamic_bitset contains TODO notes at the beginning. Maybe they should be removed for Release, they are of little value for user and rather give impression of library being unfinished. Chapter "Changes from previous version(s)" contains striken text "reserve(), capacity()" that may be removed (functions are present but undocumented).. /Pavel

2 1

[progress] progress_timer inserts \n and std::endl
by Caleb Epstein 18 Nov '04

18 Nov '04

Is there any that boost::progress_timer to inserts *both* \n and std::endl to the output stream when it is destroyed? I think it should just do the std::endl. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

bug in bgl?
by Eyal Farago 18 Nov '04

18 Nov '04

I'm trying to use the edge(u, v, g) on a revese_grap h, I get a stack overflow after the programs enters an infinite loop(or actually infinite recursive call). once looking at the selected overload I could see a very strait-forward correction: template <class BidirectionalGraph, class GRef> inline std::pair<typename BidirectionalGraph::edge_descriptor, bool> edge(const typename BidirectionalGraph::vertex_descriptor u, const typename BidirectionalGraph::vertex_descriptor v, const reverse_graph<BidirectionalGraph,GRef>& g) { return edge(v, u, g); //this should be: edge(v, u, g.mg) } the next call to edg(...) shoul pass the adapted grap. eyal.

2 1

RE: [boost] Re: [Review] Named parameters library
by Stefan Seefeld 18 Nov '04

18 Nov '04

> From: Doug Gregor [mailto:dgregor@cs.indiana.edu] > Since I've been researching in this area for several years... > > Dave is correct: no compiler out there is going to optimize this, > because the side effects are killer. It is possible to analyze that > behavior and perform the optimization Thorsten is describing, but > > (1) There are better ways than looking at it from the memory > subsystem/pointer magic angle > (2) This is very much an open research area; don't > expect this from a > research compiler for at least 2 years. > (3) This is very much an open research area; don't > expect this from a > commercial compiler for at least 10 years. > > Copy elision and the RVO are all we have. We can't rely on anything > more than that. out of curiosity: what about the LD_PRELOAD trick that's used on ELF systems to replace symbols at startup ? It's notably used by some tools to swap in special versions of operator new/delete to analyze memory management without the need to recompile anything. Is there any way for a compiler to know that some calls can be fully evaluated at compile-time ? Thanks, Stefan

2 1

[review] Formal review of the Smart Container library ends today
by Pavol Droba 18 Nov '04

18 Nov '04

Hi All, Formal review of the Smart Container library ends today. I'd like to thank you all, that participated and offered opinions about this library. I will now take my time as the review manager to sumarize the conclusion for the final verdict. Best regards, Pavol PS: There is still a little time to submit a review if somebody is willing to do so.

2 2

index.htm: gratuitous HTML reformatting
by David Abrahams 18 Nov '04

18 Nov '04

It appears that recent changes to our index page changed all tags on the index page to uppercase. From cvs annotate: ... 1.186 (rogeeff 28-Oct-04): </P> 1.186 (rogeeff 28-Oct-04): </TD> 1.186 (rogeeff 28-Oct-04): </TR> 1.186 (rogeeff 28-Oct-04): </TABLE> 1.186 (rogeeff 28-Oct-04): <TABLE> 1.186 (rogeeff 28-Oct-04): <TR> 1.186 (rogeeff 28-Oct-04): <TD> </TD> 1.186 (rogeeff 28-Oct-04): <TD> 1.186 (rogeeff 28-Oct-04): <P>The Boost.. ... Every line with a tag in it was last changed by "rogeeff". These kinds of sweeping changes are really bad for any source control system, especially when they're entirely unneccessary. In this case it's complicating the process of merging changes into the release branch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 6

[More IO] Review Status?
by Jonathan Turkanis 18 Nov '04

18 Nov '04

Dear Daryle or Tom, I can see from the most recent review schedule that the More IO library has been rejected, but I have not seen a review result posted. I'm interested to know the rationale for the rejection and future plans for More IO, since I would like to add the Iostreams library to CVS as soon as possible and several of the open issues depend on the status of More IO. For example, during the review of both libraries there was definite support for some sort of null_sink/null_buf. I'd like to know if I should go ahead and add these classes to the iostreams library, or whether I should wait for Daryle to produce a revised version of More IO. Certainly I can put off some of there decisions until later, but I'd rather take a few days and prepare a revision of the Iostreams library all at once. Best Regards, Jonathan

2 1

Fwd: FW: [bug] xml_escape.hpp/xml_woarchive_impl.ipp causecompileerrors with VC8.0 beta
by Marvin Sielenkemper 18 Nov '04

18 Nov '04

"Robert Ramey" <ramey(a)rrsd.com> wrote in message news:<cng1lp$2jk$1(a)sea.gmane.org>... > Very good call - precisely the correct fix! Thank you. > I was never able to see any test results from VC 8.0 since the library > failed to build because of some issue with VC 8.0 and spirit 1.8. I > believe this issue has since been resolved but since then testing > hasn't been done pending final release of 1.32. Yes, this issue is resolved. I posted a fix some time ago directly at sourceforge. :-) > I'm wondering if this is the only issue in relation to VC 8.0? Were > you able to run all the tests and build all the libraries? If so what > kind of results did you get? The library pass 100% with VC 7.1 (no > suprise because that's what I use here). Actually, up to now I only compiled the libraries. The current CVS head (with fixes) compiles 100% with VC 7.1 and VC 8.0. I'll try to run the regression tests. > I would hope that accommodating VC 8.0 would entail only the most > minimal adjustments. Any insight you can give me here would be > interesting. No problems here. The compiler is a little bit closer to ISO. > Also how does one aquire his own copy of vc 8.0 beta - is it worth it?. Try http://lab.msdn.microsoft.com/vs2005/ ... its free ... It does refactoring - but sadly not for C++. It comes with managed C++ - really nice. It contains .Net 2.0 - C# with templates. Sometimes it reminds me of Eclipse. We're currently using it to develop a filesystem filter driver for Win2k/XP. The driver is C++, the tests are partially (managed) C++ and partially C#. Works nicely ... > Personally I hate dealing with microsoft betas. I give the feed back > on problems and the release version has all the same issues. We did report a bug in the new STL (the one that causes boost to break ;-) and it was acknowledged and fixed ... -- MfG Marvin H. Sielenkemper, PROVISIO GmbH

1 0

How bugs fixing policy works in boost?
by Vyacheslav E. Andrejev 18 Nov '04

18 Nov '04

Some time ago I've posted some bugs in date_time, and format libraries. There is no answer, there is no fix, there is no any reaction at all. The only two authors reacts and have applied suggested fixes: Hartmut Kaiser has fixed problem with select_p in spirit and Robert Ramey has partially fixed problem with ADL and vc7.1 in serialization. All others bugs are unanswered. But release is going to be issued. Why this? What is the bugs policy? Release is going to contain known bugs? -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

6 11

base_from_member suggestions
by Joe Gottman 18 Nov '04

18 Nov '04

I used base_from_member today for the first time. It got me out of a sticky situation, but I think it could use a few modifications. Since it is designed to be used as a base class but does not have any virtual functions, the copy constructor, assignment operator, and destructor should all be protected. Joe Gottman

3 4

Re: Lazy Metaprogramming Library
by Vesa Karvonen 18 Nov '04

18 Nov '04

Frank Laub: >Vesa Karvonen wrote: > > Lazy Metaprogramming Library [...] >This is awesome! Thanks! I noticed that you replied to my original post. Have you fetched the latest version of the library from the files section? (See later in this message.) >I have been working on something very similar to this; looks like I'm >not alone in the lazy evaluation idea. I'm not surprised. It seems that similar ideas have occured to several people over the years. >My library goes a bit farther than proof-of-concept by actually trying >to use it in a real-world case. I'm currently looking for an interesting real world problem to solve as an example of using Lazy TMP. If you (who is reading this e-mail) have an idea of a good example, I'm all ears! >I have run into a significant problem however: the template nesting >limitation. I have not yet seen a way to make Lazy TMP scale >for any real problems. Yes, nesting can be a problem. The problem can be alleviated by using optimizations guided by techniques that are called strictness analysis. My proof-of-concept library contains such optimizations. >[...] nth is a fairly trival function: > >#define FUN(n, _name) \ > template<BOOST_PP_ENUM_PARAMS(n, typename _p) > \ > struct _name { >#define BEGIN typedef typename >#define END ::eval eval; }; > >// _p0 = index >// _p1 = {list} >FUN(2, nth) >BEGIN > if_< _p1, > if_< equals< _p0, I<0> >, > car< _p1 >, > nth< > sub< L2< _p0, I<1> > >, > cdr< _p1 > > > > >, > nil > > >END > >Yes, the above code is actually C++! The magic of lazy evaulation >lets us write such elegant stuff. Here is an unoptimized implementation of the same metafunction (it's called AT) from my library. No macros are involved here. template<class i, class l> struct AT : HEAD<DROP<i, l> > {}; template<class n, class l> struct DROP : IF<IS_0<n>, l, DROP<PRED<n>, TAIL<l> > > {}; The DROP-metafunction, in particular, can be optimized using strictness analysis. Here is how one might do it: template<class n, class l> struct DROP : DROP<INT<n::value>, typename l::eval>::eval {}; template<long n, class h, class t> struct DROP<INT<n>, CONS<h, t> > : DROP<INT<n-1>, typename t::eval>::eval {}; template<class h, class t> struct DROP<ZERO, CONS<h, t> > : CONS<h, t> {}; template<class n> struct DROP<n, NIL> : NIL {}; [[Actually, the above optimized implementation is slightly too strict. It shouldn't matter a lot in practise, though. It is also possible to avoid the unwarranted strictness. Can you spot the invalid invocation?]] >The thing is, even with this little example, the compiler will have to >slog though many many nested types (espically brutal is the car and >cdr). This usually results in the compiler running out of memory >pretty quickly for lists that are only 10 elements. Yes. This issue (the buildup of complex unevaluated expressions) is explained in detail using "equational reasoning" in the factorial function example that you can find in the library: http://groups.yahoo.com/group/boost/files/LazyMPL/ See the file `lazy_mpl/example/example_fact.cpp'. >I've looked at your approach and it looks promising, but I'm not sure >it will aleviate this problem. Is there something special about >inheritance that makes the compiler happier in that it doesn't eat up >its memory as fast? The solution is not inheritance. Inheritance doesn't necessarily reduce memory consumption. Inheritance is only used to reduce the notational burden. Use of inheritance eliminates the need for the kind of macros you seem to be using. The key to making Lazy TMP viable (or at least approximately as viable as Strict TMP) is to optimize lazy metafunctions using strictness analysis when necessary. This is explained to some extent in the factorial example and used throughout the library. (I think the technique needs further explanations.) A library of optimized higher-order functions should make Lazy TMP quite useful to the casual template metaprogrammer. >I'm starting to think that C++ was never really meant to do this kind >of thing, Well, it wasn't. You can take it as an axiom. >and therefore is a lost cause? >BTW, I'm cleaning up my library for others to look at, but I can send >it to you in its current state if you don't mind the mess. I can wait for the revised edition. (I'm too busy at the moment working on several other things.) >It works for VC7.1 and (believe it or not) EVC4. I'm sure with a bit >of tweaking it will work fine on g++; the hard part was working around >partial and full specializations not working right on evc4. Been there... Novadays I have very little sympathy for broken compilers. It has been about 6 years since the C++ standard was ratified. I personally find it quite revealing that most compilers still don't implement the standard. I have very little interest to spend my life working around compiler bugs. -Vesa Karvonen _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Lazy Metaprogramming Library
by Vesa Karvonen 18 Nov '04

18 Nov '04

Lazy Metaprogramming Library ============================ Vesa Karvonen vesa_karvonen(a)hotmail.com 30. October 2004 This is a minimal proof-of-concept library that shows how one can implement lazy template metaprograms. Problem ------- Most contemporary template metaprogramming libraries are strict, which means that the result of a metafunction call is evaluated completely once the metafunction is invoked. Furthermore, metafunctions are written so that the arguments they receive are assumed to be completely evaluated. In addition to strictly evaluated function calls, most strict programming languages provide lazy control structures, such as `if' and `while', that evaluate their subexpressions only when needed. In contemporary template metaprogramming libraries, there usually is no clear separation between lazy control structures and strict metafunctions, which can make programming quite confusing and burdensome. Basically, a programmer using a contemporary template metaprogramming library has to explicitly annotate the evaluation order of the metacode by carefully selecting when to invoke and when not to invoke a metafunction. The invocations can not simply be completely left out, because strict metafunction do not accept uninvoked arguments. Solution -------- The metaprogramming style used in this library is different. Metafunctions and data structures (type lists) in this library are designed to be lazy. In particular, metafunctions assume that the arguments they receive are only delayed promises to compute the actual argument once explicitly invoked. This change of style eliminates the need to constantly think about evaluation order. Metafunction invocations are only needed when a value explicitly needs to be examined. For example, the metafunction `HEAD<l>' evaluates to the head of the given list `l'. In order to do that, `HEAD' needs to explicitly invoke the parameter `l' to expose the list constructor `CONS' for pattern matching. However, and most importantly, callers of `HEAD' do not need to invoke the parameter. In theory, the style used in this library could be the ideal way to implement template metaprograms, because the C++ standard almost requires template instantiations to be cached, which means that delayed promises are actually computed only once, saving CPU time. In functional programming terms, C++ implementations are almost required to perform memoization or graph reduction. In practice, however, the representation of type information may take a lot of memory and access to the instantiation cache isn't necessarily implemented efficiently. This can make lazy metaprograms less efficient in terms of time and space than their strict counterparts. Contents of the package ----------------------- The `inc/lazy_mpl' directory contains the library implementation. Only a minimal core plus a couple of higher-order functions on lists are provided. The `test' directory contains a couple of ad hoc tests demonstrating the lazy programming style and the use of lazy lists. To get most out of the code, you should take a look at the implementation of the higher-order list manipulation metafunctions `MAP', `FOLD[R|L]', `APPEND', `TAKE', `DROP', `ITERATE', `FILTER', and `ZIP_WITH'. As you can hopefully see, they are very cleanly expressed. That is how lazy metaprogramming would look like to a casually user. Future work ----------- This library is only a proof-of-concept. The intention is to show that lazy template metaprogramming is possible and can yield correct and highly readable metaprograms. The metafunctions in this library are written for clarity rather than optimized for heavy use. In particular, many of the provided metafunctions are strict in one ore more parameters, which means that those parameters are always invoked as a result of invoking the metafunction. An optimization technique called ``strictness analysis'' could be used to systematically optimize the metafunctions. The optimization would not change the way the metafunctions are used, but would change how they are evaluated internally. In some cases the optimization could be significant. Another practical issue would be to implement some sort of lambda mechanism, which would make the use of higher-order metafunctions more convenient. Copyright --------- (C) Copyright Vesa Karvonen 2004. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE.) _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/

4 3

Re: Lazy Metaprogramming Library
by Vesa Karvonen 17 Nov '04

17 Nov '04

David Abrahams >Terje Slettebø: > > >> Yes, that is exactly what I mean above. *Systematic* use of lazy > >> template metaprogramming would yield the following (unoptimized) > >> factorial function: > >> > >> template<class n> > >> struct FACT > >> : IF<IS_0<n>, > >> INT<0>, > >> TIMES<n, FACT<PRED<n> > > > {}; > > > > Elegant, indeed. > >But it doesn't work ;-) Yes, the code snippets in my message have several typos. Like I recall seeing certain B.S. saying in a USENET posting, I don't (always) compile my e-mails. :) However, I have written a complete walkthrough of the factorial example that you can find in the library I just updated: http://groups.yahoo.com/group/boost/files/LazyMPL/ [...] >In fact it would look almost the same in MPL, though ;-) > > template<class n> > struct fact > : if_<equal_to<n, int_<0> >, > int_<1>, // <== here's the fix ;-) > multiplies<n, fact<typename prior<n>::type> > > {}; Yes, I realize that MPL contains *lots* of "glue" to make Strict TMP (strict template metaprogramming) as pleasant as possible. However, are you sure that the above works? It seems to me that you are missing at least an invocation... ;--) >The one typename appears there because prior can work on iterators as >well as numeric types. We can kill it this way: > > template<class n> > struct fact > : if_<equal_to<n, int_<0> >, > int_<1>, > multiplies<n, fact<minus<n, int_<1> > > > > {}; > >And this particular case is especially friendly to MPL. ^^^^^^^^^^^^^^^^^^^^^^^^^^ >Some of those advantages are lost when you're not manipulating >numeric values. I'm not sure what mean here. Please elaborate. > >> As you can see, all explicit invocations are eliminated. I think > >> that there is a huge difference between applying laziness in an > >> essentially ad hoc manner (little here and little there) rather than > >> applying it systematically (all metafunctions are lazy). > >Agreed, in the general case. Yes, like I said earlier, the factorial function isn't a particularly good example---for several reasons. (However, the factorial function does have the virtue of being a simple case to understand and discuss.) > >> template<long n> > >> struct FACT<INT<n> > // #1.A > >> : INT<(n * FACT<(n-1)>::eval::value)> {}; > ^^^^^ >I don't think so. You can only pass a type here. [Again, this is fixed in the example that you can find in the updated library.] >MPL isn't afraid of specializations, FWIW. There's nothing going >on in the above example that couldn't be done with MPL so far. Also note that Lazy TMP (lazy template metaprogramming) can be done without pattern matching. I've used pattern matching in the proof-of-concept library, because it can sometimes be simpler and I have no interest to avoid pattern matching just because some compiler might not support it properly. (Of course, pattern matching is something that should be avoided when one is designing generic operations. Explicitly naming a specific (type) constructor in a pattern can make the code dependent on a particular representation.) >This FACT isn't generic (doesn't work for LONG<3>, for example; I >assume you have LONG). No. The library only has the INT-template, whose template argument is a long. Designing a complete numeric tower hasn't been a priority so far. (Actually, I think that supporting several primitive integer types may be an unnecessary overkill anyway, but this is something I have no interest to discuss at this point. It would be a red-herring, IMO. The issue is orthogonal to the issues of Lazy TMP vs Strict TMP.) > > [...] concept of using both strict and non-strict > > parameters in the same algorithm. :) > > Just when I thought I had grokked metaprogramming. ;) >It's just an FP thing. Has nothing to do with TMP, really. Yes, that is basically true. (While speaking of the concept of strictness, that is.) However, issues related to strictness and laziness are particularly important when it comes to template metaprogramming. The C++ template mechanism is both too lazy and too strict. It is too lazy in the sense that a metafunction has to be explicitly invoked to get the final value of a computation. It is too strict in the sense that once a metafunction is invoked, all the invocations in the body of the metafunction (or specialization) are evaluated immediately. > >> #1.A and #1.B) The explicit invocation of the `l' parameter > >The only explicit invocation of `l' I can see is in #1. Maybe that's >what you meant. [Yes. #1 referred to the invocation and #1.A/#1.B referred to points where the information revealed by the invocation was used.] -Vesa Karvonen _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

2 1

Dynamically growing Graph and Graph Algorithms.
by Manas Singh 17 Nov '04

17 Nov '04

The graph algorithms like depth first search and breadthe search works fine when you have the graph readily available before you call the BFS/DFS function. But I am trying to make the DFS and BFS work when I have a dynamiccaly growing graph. More specifically I start with only one node and call the DFS function. When the DFS discovers a node, I add more nodes to the graph in the visitor discover function. But I am not able to grow the graph's color map. So although I am adding vertices to the graph the color map remains the same, and so the DFS fails. Is there any way I can make DFS work with dynamically growing graphs. I come across this requirement while trying to build a web crawler using DFS. When crawling I start with one node only. But gradually I keep on adding nodes in the discover vertex method of DFS. Any suggestions are welcome. Thanks, Manas.

1 0

Boost Graph Library - Property Map Conversions
by Manas Singh 17 Nov '04

17 Nov '04

Is it possible to convert other Property Maps to Vector Property Map? My requirement is that the property map should be able to grow/expand (as I am using it with a dynamic graph which also grows). But I want to make it generic so that it works for any kind of property map. So I think if I am able to convert any type of property map to vector property map then I can grow the property map, when I add new vertices to the graph. Thanks, Manas.

1 0

Building Boost 1.32.0 RC on FreeBSD (GCC 3.4.2)
by Simon Barner 17 Nov '04

17 Nov '04

Hi, I am trying to build the lastest boost release candidate (also tried the latest CVS version), and I am getting the below compiler error. I suppose, there is some problem with the wide character support, but I could not fix it. Perhaps someone on this list had similar problems and knows what to do? System Info: FreeBSD 5.3-STABLE, Compiler: (gcc -v) Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 Let me know, if you need more info, or if I should ask somewhere else, and thanks in advance for your time. Regards, Simon /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp: In instantiation of `boost::archive::iterators::filter_iterator<<unnamed>::remove_whitespace_predicate<wchar_t>, boost::archive::iterators::istream_iterator<wchar_t> >': /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:165: instantiated from `boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >' /usr/include/c++/3.4/bits/stl_iterator_base_types.h:129: instantiated from `std::iterator_traits<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/detail/iterator.hpp:83: instantiated from `boost::detail::iterator_traits<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_categories.hpp:163: instantiated from `boost::iterator_traversal<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/mpl/eval_if.hpp:33: instantiated from `boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::iterator_traversal<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >, boost::mpl::identity<boost::use_default> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:167: instantiated from `boost::detail::ia_dflt_help<boost::use_default, boost::iterator_traversal<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:218: instantiated from `boost::detail::iterator_adaptor_base<boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t, boost::use_default, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:266: instantiated from `boost::iterator_adaptor<boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t, boost::use_default, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/transform_iterator.hpp:92: instantiated from `boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/binary_from_base64.hpp:86: instantiated from `boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>' /usr/include/c++/3.4/bits/stl_iterator_base_types.h:129: instantiated from `std::iterator_traits<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/detail/iterator.hpp:83: instantiated from `boost::detail::iterator_traits<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_traits.hpp:49: instantiated from `boost::iterator_difference<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/mpl/eval_if.hpp:33: instantiated from `boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::iterator_difference<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >, boost::mpl::identity<boost::use_default> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:167: instantiated from `boost::detail::ia_dflt_help<boost::use_default, boost::iterator_difference<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:218: instantiated from `boost::detail::iterator_adaptor_base<boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>, boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, wchar_t, boost::single_pass_traversal_tag, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:266: instantiated from `boost::iterator_adaptor<boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>, boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, wchar_t, boost::single_pass_traversal_tag, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:54: instantiated from `boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/impl/basic_text_iprimitive.ipp:68: instantiated from `void boost::archive::basic_text_iprimitive<IStream>::load_binary(void*, size_t) [with IStream = std::wistream]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/libs/serialization/build/../src/basic_text_wiprimitive.cpp:27: instantiated from here /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:143: error: `boost::archive::iterators::filter_iterator<Predicate, Base>::m_predicate' has incomplete type /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:78: error: declaration of `struct <unnamed>::remove_whitespace_predicate<wchar_t>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp: In member function `typename boost::iterator_adaptor<boost::archive::iterators::filter_iterator<Predicate, Base>, Base, boost::use_default, boost::single_pass_traversal_tag, boost::use_default, boost::use_default>::reference boost::archive::iterators::filter_iterator<Predicate, Base>::dereference_impl() [with Predicate = <unnamed>::remove_whitespace_predicate<wchar_t>, Base = boost::archive::iterators::istream_iterator<wchar_t>]': /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:140: instantiated from `typename boost::iterator_adaptor<boost::archive::iterators::filter_iterator<Predicate, Base>, Base, boost::use_default, boost::single_pass_traversal_tag, boost::use_default, boost::use_default>::reference boost::archive::iterators::filter_iterator<Predicate, Base>::dereference() const [with Predicate = <unnamed>::remove_whitespace_predicate<wchar_t>, Base = boost::archive::iterators::istream_iterator<wchar_t>]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:516: instantiated from `static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::archive::iterators::filter_iterator<<unnamed>::remove_whitespace_predicate<wchar_t>, boost::archive::iterators::istream_iterator<wchar_t> >]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:634: instantiated from `Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::archive::iterators::filter_iterator<<unnamed>::remove_whitespace_predicate<wchar_t>, boost::archive::iterators::istream_iterator<wchar_t> >, Value = wchar_t, CategoryOrTraversal = boost::single_pass_traversal_tag, Reference = wchar_t, Difference = ptrdiff_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/transform_iterator.hpp:137: instantiated from `typename boost::detail::transform_iterator_base<UnaryFunction, Iterator, Reference, Value>::type::reference boost::transform_iterator<UnaryFunction, Iterator, Reference, Value>::dereference() const [with UnaryFunction = boost::archive::iterators::detail::to_6_bit<wchar_t>, Iterator = boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, Reference = boost::use_default, Value = boost::use_default]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:516: instantiated from `static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:634: instantiated from `Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>, Value = wchar_t, CategoryOrTraversal = boost::single_pass_traversal_tag, Reference = wchar_t, Difference = ptrdiff_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:139: instantiated from `CharType boost::archive::iterators::transform_width<Base, BitsOut, BitsIn, CharType>::fill() [with Base = boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, int BitsOut = 8, int BitsIn = 6, CharType = wchar_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:71: instantiated from `CharType boost::archive::iterators::transform_width<Base, BitsOut, BitsIn, CharType>::dereference_impl() [with Base = boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, int BitsOut = 8, int BitsIn = 6, CharType = wchar_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:78: instantiated from `CharType boost::archive::iterators::transform_width<Base, BitsOut, BitsIn, CharType>::dereference() const [with Base = boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, int BitsOut = 8, int BitsIn = 6, CharType = wchar_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:516: instantiated from `static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:634: instantiated from `Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>, Value = wchar_t, CategoryOrTraversal = boost::single_pass_traversal_tag, Reference = wchar_t, Difference = ptrdiff_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/impl/basic_text_iprimitive.ipp:79: instantiated from `void boost::archive::basic_text_iprimitive<IStream>::load_binary(void*, size_t) [with IStream = std::wistream]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/libs/serialization/build/../src/basic_text_wiprimitive.cpp:27: instantiated from here /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:132: error: `m_predicate' undeclared (first use this function) /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:132: error: (Each undeclared identifier is reported only once for each function it appears in.) ...failed gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/gcc/release/basic_text_wiprimitive.o... gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/gcc/release/basic_text_woprimitive.o

2 1

[bug] xml_escape.hpp/xml_woarchive_impl.ipp cause compile errors with VC8.0 beta
by Marvin H. Sielenkemper 17 Nov '04

17 Nov '04

I tried to compile the current boost libraries with VC8.0 beta. It stopped and reported the following error: ---- SNIP ---- C:\Code\boost\boost\archive\iterators\xml_escape.hpp(47) : error C2440: 'type cast' : cannot convert from 'const wchar_t *' to 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] No constructor could take the source type, or constructor overload resolution was ambiguous C:\Code\boost\boost\archive\impl\xml_woarchive_impl.ipp(108) : see reference to function template instantiation 'boost::archive::iterators::xml_escape<Base>::xml_escape<const _Elem*>(T)' being compiled with [ Base=std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>>, _Elem=wchar_t, T=const wchar_t * ] C:\Program Files\Microsoft Visual Studio 8\VC\include\xmemory(135) : while compiling class template member function 'void boost::archive::xml_woarchive_impl<Archive>::save(const std::wstring &)' with [ Archive=boost::archive::xml_woarchive ] C:\Code\boost\boost\archive\xml_woarchive.hpp(84) : see reference to class template instantiation 'boost::archive::xml_woarchive_impl<Archive>' being compiled with [ Archive=boost::archive::xml_woarchive ] ---- SNIP ---- The problem seems to be the more restrictive STL implementation which doesn't allow/use pointers as wstring iterators. The following change fixed the problem for me: Index: boost/archive/impl/xml_woarchive_impl.ipp =================================================================== RCS file: /cvsroot/boost/boost/boost/archive/impl/xml_woarchive_impl.ipp,v retrieving revision 1.5 diff -u -w -b -r1.5 xml_woarchive_impl.ipp --- boost/archive/impl/xml_woarchive_impl.ipp 7 Nov 2004 21:27:53 -0000 1.5 +++ boost/archive/impl/xml_woarchive_impl.ipp 16 Nov 2004 08:58:47 -0000 @@ -105,8 +105,8 @@ void xml_woarchive_impl<Archive>::save(const std::wstring & ws){ typedef iterators::xml_escape<std::wstring::const_iterator> xmbtows; std::copy( - xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.data())), - xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.data() + ws.size())), + xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.begin())), + xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.end())), boost::archive::iterators::ostream_iterator<wchar_t>(os) ); } Regards Marvin H. Sielenkemper, PROVISIO GmbH

2 1

GUI library - something to think about
by Maciej Sobczak 17 Nov '04

17 Nov '04

Hi, Considering the fact that some of the Boosters work on the GUI library, I would like to throw something to the mix: http://cpptk.sourceforge.net/ This library uses some template techniques, especially in those places where GUI integrates with C++ (callbacks, variable binding, etc.). As a result, the library is highly generic, uses some of the Boost, should be compatible the rest of Boost and may benefit from further "boostification". Anyway - please note that the concepts used in this library (well, and in Tcl/Tk which is used as an underlying engine) are very different from what normally comes to mind when we think "GUI programming". In particular, this library is not object-based and does not use RAII at all (apart from a couple of places which are not related to GUI), but somehow still manages to "keep the shape". It may help to put some things in perspective. Your comments are welcome, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

4 8

Re: [Boost-testing] Re: Re: Intel 7.1-linux tarball results
by Aleksey Gurtovoy 17 Nov '04

17 Nov '04

Robert Ramey writes: > I was considering the situation whereby a particular compiler/configuration > fails all or most of the test because of some issue in the test computer's > build configurtation. Which is what we had. > Since the "release package" just points to the test > results, they can be updated at anytime after the release. Of course. > So I don't see > that this test problem should hold up the release. Oh, definitely not. > > That's all I meant to say. OK, thanks for the clarification. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[logging] file_appender and rolling_file_appender
by Caleb Epstein 17 Nov '04

17 Nov '04

Attached please find an implementation of two functors for John Torjo's boost::log library which I have called "file_appender" and "rolling_file_appender". Documentation is scant, so I'll try to describe them here. The "file_appender" is meant as a more-or-less drop-in replacement for John's write_to_file functor, except that it keeps the output file open instead of re-opening it for each write. "rolling_file_appender" derives from file_appender and allows the user to specify a maximum file size and a number of files to keep. After each write, it checks if the file is >= <max_size> and, if so, calls the rollover method. This method renames existing logfiles using a numbered suffix, keeping at most <num_files> backups. If <max_size> is specified as 0, rolling_file_appender behaves the same way as file_appender. If <num_files> is 0, there will be only one logfile which will be truncated every time it reaches <max_size>. Both of these objects support a "filename_factory" function which the caller can use to generate unique or date-stamped (or ...) filenames from a user-supplied filename "prototype". I've included a factory function called "strftime_filename_factory" which will take the filename prototype and run it through std::strftime. The rolling_file_appender uses boost::filesystem to handle file remove/rename operations. Feedback is welcome. -- Caleb Epstein caleb dot epstein at gmail dot com

2 2

Re: [Boost-testing] Re: Intel 7.1-linux tarball results
by Aleksey Gurtovoy 17 Nov '04

17 Nov '04

Robert Ramey writes: > Isn't this a link from the 1.32 release package. I'm sorry, but the question doesn't make sense to me. What _is_ "a link from the 1.32 release package"? For that matter, what's "1.32 release package"? We didn't release yet; we only have "final draft tarballs", and the link I posted points to the reports for those. > Can't the link just be left and point to the updated results? Please be more specific: which link? left where? > In fact, isn't possible that a newer version of a compiler (e.g. gcc > 3.4.3?) comes out and we want to re-run show updated test results > eventhough the 1.32 package is frozen. OK, I understand this one :). Yes, it's surely possible, and we can easily do that. > I don't see this has having anything to do with release drafts. Depends what "this" is. The results at http://www.meta-comm.com/engineering/boost-regression/developer/index.html most definitely report the status of the draft tarballs. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0