February 2005 - Boost - lists.preview.boost.org

[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

Welcome to Jeff Garland as a new Boost moderator!
by Beman Dawes 28 Feb '05

28 Feb '05

Jeff Garland is now a Boost moderator. Jeff is a Boost contributor (Date-Time library), runs the Wiki, and has been generally helping out for a long time. Adding an additional moderator gives us a bit more depth. Welcome to Jeff! --Beman

3 2

Re: Boost library inclusion: generic tree containers?
by Dan Rosen 28 Feb '05

28 Feb '05

Hi all, This is my first posting to the Boost mailing list, so apologies in advance for any gaffes. I wanted to jump into the fray a bit on the tree container discussion with a couple little thoughts I had on the topic. There's been some excellent points made, reviewing the thread thus far, about separating the concerns of tree structure from tree iteration. I agree that it's very appropriate to consider designing the fundamental structure and operations on a tree a distinct exercise from designing how the data might be accessed, traversed or mutated by standard algorithms. Talking first in terms of concepts such as TreeContainer, which behave similarly to (or refine) the existing standard library Container, seems like the right approach. But there has also been some mention of more refined concepts such as AVL Tree, Red-Black Tree, Splay Tree, BTree, etc. which have some intrinsic algorithmic properties that distinguish them from what I'd call a "basic" tree for lack of a better term. I believe that an AVL tree, for example, is not actually a refinement of the basic tree concept, because you can not treat an AVL tree polymorphically as a basic tree. Inserting into one of these types of specialized trees, for example, may invalidate iterators or violate other ordering assumptions that are safe to make in a basic tree. I'm picturing a particularly hairy instance where you have iterators marking a range in, say, a red-black tree, and you call std::transform() on that range in-place. In other words, I think the only tree structures that are appropriate to consider are the basic TreeContainer and strict refinements thereof. Taking my own argument to an extreme, I'm not even entirely convinced that binary or k-ary trees should be considered, since they aren't strictly substitutable for basic trees... That aside, the real idea I wanted to offer was this: If we want to provide the type of behavior that one of these various self-balancing search trees, etc. would offer (which I certainly think we should), it should take much the same form as the heap algorithms present in the standard library do today. The operations push_heap(), pop_heap(), make_heap(), sort_heap() and is_heap() operate with typical, characteristic cleverness on a sequential range of RandomAccessIterators, imposing an ordering more specific than that offered by the RandomAccessContainer storing the data. Similarly, operations such as is_k_ary_tree(int), is_avl_tree(), avl_balance(), etc. would serve to impose and maintain a useful, more specific structure on top of TreeContainer, and would avoid having to make a messy hierarchy of structural concepts. So, this is all just to say: if we adopt the approach of further separating the concern of specialized tree structures, then I believe the exercise of formulating good concepts for basic tree structures becomes simpler. Furthermore, I'm guessing that also makes things easier when we do get to the step of worrying about standard iterators and interoperability with standard library algorithms. Hope this is a useful contribution! Cheers, dr

2 1