- Boost - lists.boost.org

Boost Logo Contest Extended
by Joel de Guzman 28 Feb '05

28 Feb '05

Hi Y'all, The deadline for submission of entries is technically over but I still keep getting new entries. I am extending the deadline to March 1. There's no reason to hurry, I guess. The more the better :) It's also been a busy month and I still need to setup a system for getting and tabulating the votes. Any suggestion on how to do this will be highly appreciated. Right now, I'm inclined to just do it manually. << Currently, there are 73 entries + a few more in my inbox. See: http://boost.org/more/logo_contest.htm >> Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

11 29

[mpl] rational_c, fraction_c
by Andy Little 28 Feb '05

28 Feb '05

Hi All, What is the current status of compile time fractions / rationals? Various directions are 1 Alexei Gurovois in boost/mpl/math/rational_c.hpp 2 Cromwell Enages work on the files section <http://groups.yahoo.com/group/boost/files/mpl_math.zip> 3 Hugo Duncans: http://tinyurl.com/2qrpq However the three are not compatible with each other In Cromwells (named fraction_c) and Hugo Duncans the numerator and denominator are mpl Integral Constants not values, as in Alexeis original. mpl::rational_c<int,1,2>::denominator; // == 2 against mpl::rational_c<int,1,2>::denominator::value; == 2 Cromwell's version is not a nullary_metafunction whereas Hugo Duncans and Alexeis are. This is the right thing IMO because the type can be reduced eg 2/2 ---> 1, Also see http://lists.boost.org/MailArchives/boost-users/msg06245.php I appreciate that there my be advantages to Cromwells and Hugo Duncans versions.. Ultimately either the version in the release should be removed/ modified or 'lived with'. Anyone have any thoughts. And is anyone still working on this? regards Andy Little

2 2

[program_options] Deprecating 'implicit' and 'multitoken' options
by Vladimir Prus 28 Feb '05

28 Feb '05

Hello, the program options library allows to mark an option as "implicit". That mean that specifying a value on the command line is optional. One can write either --someoption foo or --someoption --someotheroption In the first case, the --someoption has a value 'foo', and in the second case, it has no explicit value. This behaviour is tricky -- we try to look at the next token and figure out if it's option or not. In particular, we'll fail for the case of --someoption -1 and we'll also fail for the case where the token following "--someoption" is an option recognized by the user-provided "additional parser". I would like to deprecate the 'implicit' options and eventually remove them. Another alternative is to require that value for implicit options is specified in the same token: --someoption=foo Another problem is with the "multitoken" options. Those are options which allow the value to span several tokens on the command line. Again, we need to check, for each token, if it looks like option or like value, and this is tricky. I'd like to deprecate this behaviour as well. Any objections? - Volodya

2 1

utf8_codecvt_facet location
by Robert Ramey 28 Feb '05

28 Feb '05

I've made changes so that the serialization library uses the utf8_codecvt_facet in boost/detail. Now I have a couple of questions: a) Where should the documentation page be moved to? I would expect that there should be: boost/libs/detail/codecvt/doc - but its not there b) Where should the test be moved to? Right now I'm running the test as part of the serialization libray. But I would be happy it moved to somewhere else. Looking at what we do to import the same code module under different namespaces makes me think we would have been better off just getting it officially into boost. The current system seems adequate - but its a little cumbersome and different than all the other boost libraries - so its one more thing to figure out and keep track of for someone who wants to use it somewhere else. Robert Ramey

3 3

special_functions_test
by Gennadiy Rozental 28 Feb '05

28 Feb '05

Hi, Hubert For some reason I couldn't locate message to respond, but here is reply to your last post: > Well, actually, I am held up at the moment by what seems to be > internal Boost.Test problems. > I checked in a few days ago some modifications to the special > functions tests, which take into account the modifications to the > BOOST_CHECK_PREDICATE macro, but compilations still fails (Xcode 1.5): 1. You are using unit_test_ex.hpp. I forgot to remove this header. We don't need it anymore. Boost .Test now works with boost::function out of the box without any extra support. Just use unit_test.hpp 2. I noticed that your test could benefit from BOOST_TEST_TEMPLATE facility. I spend some time and look on attached version that do the trick. Fell free to use it if you want. 3. Usually It's not good idea to do ant thing from within init_test_suite function. This code is not guarded and should only be used for test tree creation. Gennadiy begin 666 special_functions.rar M4F%R(1H'`,^0<P``#0````````#;Q70@D#,`)@,``#4(```"^,CM3-U@6#(= M,PX`( ```&%C;W-H7W1E<W0N:'!P`+#Q:F 1W0S,S/T8$7NO"CCO$JR1)NVS MC(Y,R116R99\<K5O58FD6V<J:2J^$C<N3W>Y7)*VBD@4DVTU4YQG4\"O@-&@ MG1I/C@&@D$ :`#G[_F;F#P(<TTQ1.%A%"2#.8"MD$PR[!B2Q//:,Z_&^*,8' MB,E8;T<R682NN04#((C7(@@!*(:B(E'7LKY<.*..>*^1\/#K97!?"W;^*4XY MS%-0P+\7D:"K-$H.^5V2XR[SN"'O8?T;I*R22 FZ+\1_`%"*XE;2D?O$).32 MN2NXWF',LC.&C5O3T**]=Y5>XN8\.20D-;,AHDR89Y24Z%[@T#O_PE?/24H_ MPIUI9%#T>Z1!EN*505W3N[-AQU/[&&.34KW'5$SFB<;S#)TI!?-R>I1["0=/ M4SKNO_:!RR#'R798@( B;9N2DE)KI^KL.63F6K&:RT:K37"HMZN1]^:C.]TJ M41BZ"..LDTO[0.$B@.F0QP<$CC6<8OP<-E #ZQ6<$]!Y8^+(!R*5-\K*[9<< MTU-$KB)]T9XZB!H?6?->4?1W(),V%T. R[Z1'C?;!B_$+9HMW!&IE\<@](0: M-0BL*MC*$_/3X\B/#9A?#-,3@9?6*03QUL'HH747$?\#\-X^?FVIV^0+9+W; M$\J%WWGG#KYZA"!EALC6HDV35.E#E37!@0Q/N#JRX'7B@AR]G9>6765#)3DO M*AZ]7;T\F=7^?WZU%NCLZQTM0=P=T-$:6GJ)CJS+W)]%1VE@C'NS.+$5R?FW M)J'1NT'#HKD_29:U,^7;H7;?"47.\5<[P75@MZN-$\.TE:JKN>3Y0S/AD:#= MMOA#Q=S]RV?UW-Q&<=HT^U);D%Q4M$/Q!"!Z;^]OVT4ZW\WT:SPZ]N*<ZJGU M7[?LKS="@(L.E[;<U<"Y/U%,X>?H[J JF!V?(4+E#K5CY1D*FI\3V*0[G2M: M^8P=.@44S<1&?R/:+]G$^R2J?A^T_&3!63:>+8I^I@54RT[%?#N4HQD:K%-$ M6Q*M,&J1!W>'4:9&_.V%F/BJ0J#;&B[$;U+VZ57U]@"0]X[F^C_U;%2\;:7C M@V\K[0Y:S>[:.IP=2-5FV"M4=&W\0-P"=""0,P`?`P``*0@```)Y,YW V&!8 M,ATS#@`@````87-I;FA?=&5S="YH<' `\".12!'=#,S,_1@1>Z\*..\2K)&F M[;.,CDS)%';)EGQRM6]5B:1;9RII*KX2)RY/=[E<DK:):!23;353G&=3P330 MT: =&D^.;H! (^)!S]_X;@\"'-1043A810D@S& K9!,0%<Q6<3SV?.OR/BD& M!XC)6&\_,EF$KKD$X]!$:Y$D@(B&JF)5U[(^7#BDCGBOD?#\=;.2+X6K7QLS M#G,4U# OQ>1H*JT2<\Y770*[SN"'O8?S[I*R0\!-T7XD^ *6*W9M63OWB$F) M6&67<;S#F0[.&>[>GH5N]=ZZO;7,>&,Y(7JR%DF3#-(T'0O<&<=_^+-]%)LR M?A4J2J:7H]QT&6XM"@KFG<TN''2^L@8SZE>XZ8F8PI(\HRE"2+Y>4U*/62B$ M]40NZ_]G'*X*CPNR<H@")=FSTDH,Z?]<AR'YT58S66D5:6X4^/5R/ORT9GNT M)1&+G(Y*CEE_:2 (LMA1Z<' =QK,,7X.&N@(**^"SH@\LC5<$<BT)OE97;+C MEFHH*HB;=&:0H L?73=?B3I+.)*V&5' 9-Z1'C';!B_$+9H;F"13+XSCT #3 MI%:PJFL@3]%/CC3X:\'PRS$P3)ZQ2"?G6P>I.N1<2/@/PWML?7R!C<O=L#]( MA[T*UM[6@98;(UJF]DL4HWU2NTP(8GW!TY<#KQ22Y>SLO++K70\*\EZZ'KU= MO3R9E?Y_?K56Z.SK'0TA#(a)[H61I9^GF.K*O<GTNCL+!&1D_,,$5R;FH?4.BQ MH.&"N3=(MC4RJY<#*CX2%T.^KH=Q<6#'Q<::(=BS8IK8B;\H9GPG:#=MKA#\ MN9NW:1Z[FXG,&GM[J2V,7%0S='#B$#TW][?M)J5/IOIU'AU[?*\]U7ZK]OVN M\W0J"*CH>HW+7 N3]12N(GZ>ZD*EH=?Q^QIICJ5CY)^:>M>*,$I=SI6M?+@. MF8* S,1&?R/:+\F$^R2F;A9I_D>"HFDT6M3>B!33IIV*^'<-/J-JH4SQ:TJT MP:96#N\.HQ&WYMA8HU3(TAZMH-B-ZF;-*K:^O<D/>.WOI_]7!4/#M,TX-O)] MH<M9?=O6XK4C51M@K$_1G^**;W0@D#,`= 0``-P2```"UE[C`]5@6#(=,PX` M( ```&%T86YH7W1E<W0N:'!P`/ W!C\,&8T,S0_-@1N[_%8'0'4JXVG-VSC& MY )KUV[!9LD%;MZH)I8V\&II/5\)&MNS_O15+NMI)HXL23242FQN2Z+PS@DT ML)]/PSTG,3_,'T_3"<)'A\ P$\#R()SD@@)M8C0FALZC(148DFDELUO-HT:\ MNP\^9X6=`TR)*Z^^E-HBZS)D^RV_<=:L``1U\\5]?0XP3+F>CW-XQL!V75(L M+U7+GKMQ(OM(_1\&-OO%`:B@S#GL77 +PKY&NU)C7N@B8X(!\ OY>]D&6+AM MW+<#^$8X(a)1)--?/HV0.0,Y3/;T<]_!TX<"/"B^=K3 2#Z)@Y00/$I;#FM''K M';]2WC*RK;WY4*"H?6^A^$"":K>Q05Z2)H<.69[7@SP:DT<LU*B$D'GA&0CE M&B[*$LQZ13++U L]T?\,BTR(7HBFDR,$F'96!,<8B3RO-.0<[*L[]L3RXH;A M&T]1&PQ#1J>S8DV\&LG/5IAE_JL5";9++L,<?' XIJ$L;-VFR"A-/DI[(._Q M<4R&LWL38(FBJ3/#-&PJ*3%%.J+,(''VLW;T>YYH!(6PU36 DWT!Z'_*@1;D M%/85[(\KZN6 :-"./F![$*AAP%XK-.TGW:=!\G82B0W/&"@EXNJ!T&GD+D+Z M#OE:JAA@8:;$[)R=, D#BS? Z_Y1]ZD(9325&I*#3Q=".0LQ^7P--L+'35<! M]W ?GV=75AQ(XL =+_-AP!^??U]'-J4?T_CIOXN?JZ3HRIE,7P`Y7I!2-D>7 M[D4<T2>]TP\WZX#J^((**OXDL1%HK1# PMP4"N8BT5OFO*[-Z\!B& 4D2TV( MEIOWL0%O(G'ERZ]NN?=HLN_[L%_]D>O]\'MY[X3,.DC*#EE$?Q;@J `_[@E8 MAQ2<1.<7(,?<M?+1?*X>&-J>H'ZQ33[&1_^QSO6>AQ0]6A!I[1RO5_['O6C/ M79=WRDC*K$6:$0*@7+H=KVKX;A?S9LF4&HJEK!I!)H.*2UQ7-D5#V<1]V>L^ M"UE*Y'>DR1.>E\YTFG+5`<X831<O(+QHML6*@,LNX9P>V^.V3>_Z][7<IMO8 M+GU'77\SSYDP^ZL;J6X3V+D4V[H0;]\&:_;,-/X'>8MY[O;:I;6(G4K^9+]% MN/2>&G)0,3%FTIC(\B:9)1=O&'%X-C2I0"C9M*'I,F:%@2++*):5?]/!JU- M3$_2L*=G36-3R%<=34JY*F'7'4R(H[4XI*SQ6'NNR>H.36E$4%=M9MD.7#L2 M8(D`57$'+86#7NGC5QV(V!5VY5W%]JPU2&!+Q09DF48#,GUGD<%8L>26S0?W MQ<F2.H -PL=247I*761M=IW#Q!9\J,!O=5%C7)XRKY\>4=[5?#;AWHU8$ZB8 M=22?;?XR6J2PL6_Y>JGB^SSHC_G\_%:5EW_6J6U9N31&J[Y$GW-IVJJYC<FQ M-6M\B[T]N>!>G^F>?2DW9NL/E%#=8S_BS(T:QG2<$\R?P%H8#[X%_B1+S[9, M=T[QG4S^1:_EJ\;]:VW2RUOUK_Z4R)UL:?.>3C;5/$OBKF^MO^TWS'0@D#(` MM@(``$8(```"5XF2;]!@6#(=,PT`( ```'-I;F-?=&5S="YH<' `L& ]60V9 M4,S,_101=Z\*(=TI"-I)VB:7'8 XHK8Q9TBMV[4$TBVR*FDJNB= HGN]%CLK M;71A**=:C5 C@>BZ#H2)PYT<SG,2\<X<Z3G,PYA'VO_3_X(HH*-TD0HAPZ#& M1P8H2.M)Y7W]->@U-E!@^-HC+FGR(:B(\[#0_H8Y+#00"0$BLD)9Y_O@)DRZ MHYH\0X ]/.2DB]JJON3,[<I)*2 Q1YS851L=$_<CSP2O`]CB[68-.YR-#E@' M9%]=7PA2Q6TU4Y7\`QFDK+33V9]EWOE9R4"SGOK+].!=BVQ(>+NE) :M``R) MB- F.B?N:1V_P3Q%H4]7Y%/-"I(>3V!>SD<R@KM-SSX<>PUU!FEU(_LLB@,P M'=^VS&&HRDBYVE#EPQXRE)IK80IJ*%0+'ZH=ZYU+X8:9A&#R`!+2,\TY.KJP M86,*X>%KV!<-O1U\][0L?#Z=*V&_U=*)E:8?(:B61813\_A 0:C#HR%V7+F< MWH&<4/%G]V/,. DH;A,TU.VZF%'D+?MRX>GI"&=Z`YT>+!>^*Z-C" .%B#NP MB.FP,@&&-UL#K(Z;'VP@(^KMT1</9)3>=[\_;K,Q%W#QRRL(I%Z["=A*I0K< MRZWR8Z_FORWU@(9$]@<EWA8']XY9@C)-6=<_HA>J)P87JD;.(1HITQ%Y*I)6 MO,RM^)+^QM4DF#0W\YQYU$[P`?^&Y).?&'KTL#EEXD/1*3Z10[@I1QY_QJ8= M_G"IE19%;.C-.K0MMX*8B-8O/J5Z0['B-EY4K /RH ZE7RC:^R-8KFX(,?MU MEP4[0TCJ:(1!>\2O$'J[H[:I=O!P4![17FW+=>(!Q=L]W#5*C944YW,<]<T= M7XU.R):X54E$!;IJLD0EW_0.[H+6WH\3@ZHOTL]X#%,JWP/@8EY!5HXJ=&\! MW4E\M@2H_+7A78[BL'S3^4#V'70@D#,`N@(``)T(```"8[W"]-)@6#(=,PX` M( ```'-I;FAC7W1E<W0N:'!P`/"$CRD-W5$(S/T8%7O/"M3O2"C@#M4Z7'8D MX0MC5GQ5;M[1##6WJHP*?"?!53W>JR6UL-9FZ ZPA$JXGT3HWH W,YO,YN<Q MOQS/KS<S<Q?DO_1_\)44%&Z2(40X=!D(X,4)'<S2>9]_3GH)'S!!?&T1ES3Y M4M1$>=AG'X8Y;C00`C$BLD)9Y_N@)ES21RQXQP!Z><*4+VJJ^Y,X;D)+24&. M/Q-A56QSGG&\\!7A>R1=C,&G<Q&AE@';%]9/A"EBN)JIE?PC&<E9::>SOLN] MQ6<LZMYL"R_1A78N,2GB[2D@M6@0)4Q'X6HZ)^[I'9_1/&:@3D_*I6XJ2'\> MPJ#3D>I05ZGL\V'%L19 SEU(_LPC(&H#M_;8AGHJDJIF5*+;L>&IKNBPXAKI MJ&8#'ZG#604WAAIF$8"@KQ:1T&?'T].'$QB7#PM?PKA\\_5S7]"Q\/IT+8L' M3T(SN^8?(>BVQ8A3<_A 0:C"3E-\7;LD-Z!G'#P^,;5D#=CSC@(4QPF?5G0, MKBCK?1&L?NW::WL#Q_$ZXY_!AO_%=&UB!(,14C1$=/A1`,,@FP88CI\F;6M. MWKPC8LRSF5[GQL.LZF+V+B+@PBD:7:3M)<->FK<JZWR8ZOFOR8%@M(C1U9PO MD+ _O&6H".7UO7140LDC2E#2Y73*$:,Q,1MRJ26_6A7/`E_N=5M:=/#?*@X\ MZC0(!3=Z&UN/1D%_^Y^O(#=ZL>BCJGJAX4<*A-'>RV('<%OH"K:\H\!4C88, M^BP1UO$;-NUOZ'])`OBL9AM?9&P?OT+,@(,'J7*,PP:1DJ(1!>\2O"'J]H[B MIOG>WIU//7?*::\:QQ=DWG!.,KZ,Z*;ZY)NM6-7\QT0B;_ JDH@+;-6!`"GS MD5MJN;>CQN#JK*F'N!9TE[=*T#%S**Q7-21N!>5"XW0Z,6>_SL@A6CYVGG(? ME-#J=""0/P`2`P``!0D```)?#DDJR&!8,ATS&@`@````<W!E8VEA;%]F=6YC M=&EO;G-?=&5S="YC<' `L&QW%@P!#0S,_101>Z^*T.<4F'6H[1>+:K <<4M8 M#CD%3D HMH032UI:(FD@O"N007_>@1NQM;K9U)J-R52!V"=%P7AI)PYI.'5\ MV3I\,T[I)P9@S@1G#..'.B:8HQQ1BQD='H'X110#9(P[I<CS,9'WHJZ"`.XD M;J0KK\'9"1MPKOI)B'"'A]TCPO?P\/PKYUQD,44&*0R30B_:*(SCAEN)]\)* ML_CCRL0Z=?(R/.!UA=,OQ?TBL5^&N9]88Y@9AEE_) P]V&9;G+-^]=5P+*KV M%RGCZS$@:&0)14QS0FHZ."SI&7O*^(\JKR^VGY(9+6)P&/9=DU)B4-GD,\2" MWNZ<T4F;=U/6B <<@I6QZ5)ZUR1KQCH=_3=EW7V_*%U(@]? %J>-@Y3L==6K M%S/"(G=)G4?F9#2(a)VDQ(U(^R`;S&0H\.I<+:2,QB#P%8KG8KG96@.AA,<IE) MQJ\E[ JOA^W/H,%SE51+8'@20OQM%;8O, *'?\N]H,"G(R)EQ@]O'LPJB712 MSF$<<D+PN []M"_?>FY_V:XW7R^-E:I&33\F)T=.S+5YO<=$)K7+-G;9W'"! MFROP]4J3?<4DLCJH$.Z;7B;51E2.M.<U?O^4D.U 0=;X*SXS_(7%S<RV'5"J M'9;HO:-&ILQBOW=,$U#FPXD]3H6!1(!6W0'5*I-16M/M_6W-PMS2]-82*@&# M0]UMAII'=F;MQ94/7EY[]P" 6U,M;<!0O0E:_X!XB=V'P5C-YFQF@)[ $N>R M`,R/QOG1]?LQ9],"' 7C>.CP0M@6MSJW;UR^OR=&"[AO<V!:<=Z5?K+YH9^> MKO+-GRK9LV?'QO(AA\.0Z<X^ZU*(_T-U&FB0>U\FDQ,-G*^Q2D@'+<\NE&UH M'I"BA)K0=)D+BA7$YTY=3RUSYAA <!: NFHE3-J H"C*C8^.OU107C&)\-+9 M1; ZBD@+9THIO$;LQ<]=!W<KFX#T^S:@O#<//0&C+8/V7('"(RX-GJWE(*,J M?40)LFLU%"_/513GF1Y#@&\T29;].KO2W154YZK;/S\//IAP_,?X@,0]>P! "!P`` ` end

2 3

Querying usefulness of a macro for inheriting from STL containers
by christopher diggins 28 Feb '05

28 Feb '05

When inheriting from an STL container the constructors and local typedefs need to be redeclared. For instance the vector contract class at http://www.ootl.org/pwc/pwc_vector.hpp.htm . It seems to me that it would be very useful to have a single macro for each of the different STL containers to ease inheritance of them. Does Boost already have something like that? If not would anyone else want something like this for Boost? Or am I really missing something basic here, and this is a bad idea for some obscure C++ reason? i.e. #define BOOST_STL_VECTOR_OVERRIDE(NAME, ELEMENT) /* */ \ typedef std::vector<ELEMENT> inherited; \ typedef typename inherited::size_type size_type; \ typedef typename inherited::reference reference; \ typedef typename inherited::iterator iterator; \ typedef typename inherited::const_iterator const_iterator; \ typedef typename inherited::reverse_iterator reverse_iterator; \ typedef typename inherited::const_reverse_iterator const_reverse_iterator; \ NAME() { } \ NAME(size_type n) : inherited(n) { } \ NAME(size_type n, const ELEMENT& t) : inherited(n, t) { } \ NAME(const NAME& x) : inherited(x) { } \ NAME(const inherited& x) : inherited(x) { } \ template <class InputIterator> \ NAME(InputIterator x0, InputIterator x1) : inherited(x0, x1) { } \ /* */ Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

6 21

Filesystem efficiency- search sample
by Terence Wilson 28 Feb '05

28 Feb '05

I'm interested in using the filesystem library, however, I was disappointed by the performance test I ran. I wrote a simple recursive find file function using win32 to compare its speed with the find_file sample in the 2 minute tutorial, I found Boost to be 2-3 times slower on average. Does anyone have any thoughts on where the slowdown may be? Terence Wilson

2 1

Re: [boost] Re: Type of Review for UnorderedAssociativeContainers&HashFunctions
by JOAQUIN LOPEZ MU?Z 28 Feb '05

28 Feb '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Sábado, Febrero 26, 2005 5:40 pm Asunto: [boost] Re: Type of Review for UnorderedAssociativeContainers&HashFunctions > Thorsten Ottosen wrote: > > I think tr components should be allowed special status. What's > the point in > > putting tr components through a normal review, when there can be > no interface > > changes? > > > > If the definition of fast-track review is not suitable for tr > components, then > > let us call it a > > tr review. The important aspect of such a review is that it > should be fast. > > Fast as in soon? Or just spending less time on the review? I don't > mind > waiting in the review queue so unless anyone really wants to see > this in > Boost as soon as possible, I guess that Boost.Hash should be fast > tracked, Boost.Unordered should go in the queue, maybe for a > shorter > than normal review. Is that okay with everyone? > Is perfect with me at least :) I guess the review wizard should allocate a period for fasttrack reviewing Boost.Hash (which, if I understand it OK, can run in paralel with other regular reviews.) Tom? As for my negative vote to accepting Boost.Unordered for fasttrack, my main concern is that other authors are patiently standing in line for their own reviews, and the size and scope of this library does not justify for a fasttrack treatment, in my humble opinion. Other than that I think the lib is needed and will eventually make it into Boost. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[program options] optional/required options
by Stefan Slapeta 28 Feb '05

28 Feb '05

Hi, I don't know if this has been answered yet, but is there any concept of optional/required options in the program option library? Currently, only "allowed options" can be defined, no? I would be great if you could define different sets of required option groups (because it's possible that a+b _or_ a+c are required) and provide some validatation for that. Otherwise, you have to do that by hand again and again. Stefan

2 3

Boost library inclusion: generic tree containers?
by Justin Gottschlich 28 Feb '05

28 Feb '05

Dear Boost library members - My name is Justin Gottschlich and have just recently joined the boost mailing list. Since this is my first post, I would first like to apologize in advance for any e-mail inequities I manage to include in this e-mail. I'm e-mailing is to ask if there may be interest in a generic tree container for addition to Boost. I have created four generic tree libraries which I am currently using in my online game (Nodeka). Additionally, my former company began using them in a rather small scope in 2002 and has since requested additional use of the libraries throughout their product (QuarkXPress) and my current company is now showing interest in using them and will begin using them within the next couple weeks (Raytheon Company). Due to the increased interest of the tree libraries, I am now bringing them to your attention in case you feel they may be of interest for Boost library inclusion. The four containers I have written are: core::tree - creates a generic tree that follows std::set functionality per tree level core::multitree - creates a generic tree that follows std::multiset functionality per tree level core::tree_pair - creates a key/value generic tree that follows std::map functionality per tree level core::multitree_pair - creates a key/value generic tree that follows std::multimap functionality per tree level In addition, I have four iterators for each tree container. The containers are written in an extremely general manner so while they have ordered behavior through "insert" functionality (like set and map), they can also achieve unordered element behavior through "push_back" and "push_front" behavior. The reason for this is so the generic tree containers can be used as a basic framework to build additional, algorithm or purpose driven behavior (nested sets, compiler based control trees). The containers are by no means up to "standards" quality - so much work would be needed there. =) I have written two articles on my tree containers (one published on gamedev.net) and the second article in the process for publication on gamedev.net that is currently being reviewed. I have posted both articles on my site for review (if you're interested in reading them): http://nodeka.com/TreePart1.pdf http://nodeka.com/TreePart2.pdf The second article really explains the design thoughts behind the tree containers. The first article simple shows how I've seen C++ programmers build trees using maps and why that's bad. =) If you are interested in the reasoning of my design for the trees, I would recommend reading the second article (http://nodeka.com/TreePart2.pdf) The current header source code can be seen here: http://nodeka.com/tree.h http://nodeka.com/multitree.h The core::tree_pair and core::multitree_pair are undergoing some changes so I haven't posted them just yet. If you feel generic tree containers are not suitable for Boost, I will completely understand and my feelings won't be hurt by your honesty. =) Thanks for your time and consideration, Justin Gottschlich ( <mailto:justin@nodeka.com> justin(a)nodeka.com, jgottschlich(a)runbox.com)

16 48