- Boost-users - lists.preview.boost.org

special_functions_test
by Gennadiy Rozental 24 Feb '05

24 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

1 1

Assignment library and G++
by Josue Gomes 24 Feb '05

24 Feb '05

Hi, Take this code: #include <boost/assign/std.hpp> #include <boost/assign/list_of.hpp> #include <boost/assign/list_inserter.hpp> #include <map> #include <iostream> #include <string> using namespace std; using namespace boost::assign; const unsigned long USER = 0x0001; const unsigned long ADMINISTRATOR = 0x0004; const unsigned long ALL = USER + ADMINISTRATOR; typedef map<string, long> item_permissions_t; typedef map<string, item_permissions_t> module_permissions_t; int main() { map<string, module_permissions_t> permission_table = map_list_of ("Module1", map_list_of ("Item1", map_list_of ("Feature1", ALL) ("Feature2", ADMINISTRATOR) ) ("Item2", map_list_of ("Feature1", ALL) ("Feature2", ALL) ("Feature3", ADMINISTRATOR) ("Feature4", ADMINISTRATOR) ) ); cout << "modules: " << permission_table.size() << "\n"; cout << "items of module 'Module1': " << permission_table["Module1"].size() << "\n"; cout << "features of item 'Item2' of module 'Module1': " << permission_table["Module1"]["Item2"].size() << "\n"; cout << "permissions of feature 'Feature4' of item 'Item2' of " "module 'Module1': " << permission_table["Module1"]["Item2"]["Feature4"] << "\n"; } It compiles fine with VC 7.1. However g++ 3.3 and 3.4 (both on Linux) refuse to compile it. See the error message (excerpt): sample.cpp:36: instantiated from here /usr/include/c++/3.4/bits/stl_pair.h:90: error: call of overloaded `map(const boost::assign_detail::generic_list<std::pair<const char*, boost::assign_detail::generic_list<std::pair<const char*, long unsigned int> > > >&)' is ambiguous /usr/include/c++/3.4/bits/stl_map.h:166: note: candidates are: std::map<_Key, _Tp, _Compare, _Alloc>::map(const std::map<_Key, _Tp, _Compare, _Alloc>&) [with _Key = std::string, _Tp = item_permissions_t, _Compare = std::less<std::string>, _Alloc = std::allocator<std::pair<const std::string, item_permissions_t> >] /usr/include/c++/3.4/bits/stl_map.h:156: note: std::map<_Key, _Tp, _Compare, _Alloc>::map(const _Compare&, const typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::allocator_type&) [with _Key = std::string, _Tp = item_permissions_t, _Compare = std::less<std::string>, _Alloc = std::allocator<std::pair<const std::string, item_permissions_t> >] the command line is: g++-3.4 -I ../boost_1_32_0/ sample.cpp -o sample Any ideas of what is going on here? Regards, Josue Gomes

2 1

[serialization] editor archive
by Martin Slater 24 Feb '05

24 Feb '05

Hi, I've been using serialization for a while and am extremely happy with it, now I would like to utilise it to automatically populate an editor with object data. Basically I intend to write a new archive type that will serialise to / from an editor interface using the type info of each serialised item to attach suitable editor components. Has anyone done anything like this or have any ideas of problems I may run up against? cheers martin

3 4

object with external linkage in boost/tuple/detail/tuple_basic.hpp
by Michael Benfield 24 Feb '05

24 Feb '05

When I #include<boost/tuple/tuple.hpp> in multiple files and compile them with the Digital Mars compiler, its linker complains about multiple definitions of an object called ignore. The problem is in the file boost/tuple/detail/tuple_basic.hpp, which has this line: detail::swallow_assign const ignore = detail::swallow_assign(); This works when I compile with gcc or the Microsoft compiler, but it shouldn't be there, should it? I thought the only things with external linkage that should go in headers are special cases like inline functions. If I'm wrong and this is a bug in the Digital Mars compiler or linker let me know and I will go report it. Thanks, Mike Benfield

1 0

enable_if for function templates
by Agoston Bejo 23 Feb '05

23 Feb '05

Hi all, I am trying to enable only two version of a function. The caller may choose one of the two versions by specifying a template parameter. I've got two versions for the problem, both of them failing the same way. -------------------------- Version A): integral template parameter -------------------------- #include <iostream> #include <boost/utility/enable_if.hpp> #include <boost/type_traits.hpp> using namespace std; using namespace boost; template<unsigned int N, typename T> enable_if_c<N==1> f(T t) { cout << 1 << endl; } template<unsigned int N, typename T> enable_if_c<N==2> f(T t) { cout << 2 << endl; } int _tmain(int argc, _TCHAR* argv[]) { f<1>(10); // ERROR f<2>(5.5); // ERROR f<3>(7); // ERROR return 0; --- The error message on all 3 lines is: error C2668: 'f' : ambiguous call to overloaded function The compiler's "explanation" for the first one: (for the other two it is much the same except the type) could be 'boost::enable_if_c<B,T> f<1,int>(int)' with [ B=false, T=void ] or 'boost::enable_if_c<B,T> f<1,int>(int)' with [ B=true, T=void ] while trying to match the argument list '(int)' -------------------------- Version B) : type template parameter -------------------------- #include <iostream> #include <boost/utility/enable_if.hpp> #include <boost/type_traits.hpp> using namespace std; using namespace boost; struct A1 {}; struct A2 {}; template<typename U, typename T> enable_if< is_same<U, A1> > g(T t) { cout << 1 << endl; } template<typename U, typename T> enable_if< is_same<U, A2> > g(T t) { cout << 2 << endl; } int _tmain(int argc, _TCHAR* argv[]) { g<A1>(10); // ERROR g<A2>(5.5); // ERROR g<int>(7); // ERROR return 0; } ---- Error messages: error C2668: 'g' : ambiguous call to overloaded function (for all three of them) "Explanation" sample: could be 'boost::enable_if<Cond,T> g<A1,int>(int)' with [ Cond=boost::is_same<A1,A2>, T=void ] or 'boost::enable_if<Cond,T> g<A1,int>(int)' with [ Cond=boost::is_same<A1,A1>, T=void ] while trying to match the argument list '(int)' ----------------- enable_if should actually prevent the compiler from trying to compile the 'false' version, shouldn't it? Thx, Agoston

3 2

[optional] comments about none_t
by Yuval Ronen 23 Feb '05

23 Feb '05

Hi. I checked out the optional library and found it to be of great value. I have, however, a few small suggested improvements (and no, I'm not talking about the pointer/container/discriminated-union semantics debate; I read this discussion in the mail archives and I also saw the resulted library and I'm very happy with what came of it). I'm talking about the detail::none_t part. Should it really be in the detail namespace? Isn't that a little weird? The detail namespace should be "forbidden area" for the users, yet here they are offered to write code like my_optional = boost::detail::none_t(); One might argue that there's the 'none' global variable which will make the code look like my_optional = boost::none; which looks much better. I agree that it looks much better, but it still doesn't make the previous way of thinking (crating a temporary none_t instance) illegal or unsupported. It is unsupported now. And while we're at the global none variable, I have to say that the reason I first tried the temporary-none_t-instance way, is that I didn't know of 'none'. The documentation is very poor on this subject. It's only mentioned in one place in a short, unexplained sentence, and it's in the "Detailed Semantics" section which no one ever bothers to read anyway. In addition to improving the docs, I'd say that it's even better to include the boost/none.hpp header with optional.hpp so it could be easily found and reached. As I understood, the reason why this is not done now, is because some compilers (such as Borland's) have troubles with initialized data and pre-compiled headers. If this is truely the case, then I think it's easily solved. Include as follows: #ifndef BOOST_OPTIONAL_DISCLUDE_NONE #include <boost/none.hpp> #endif while the BOOST_OPTIONAL_DISCLUDE_NONE flag can be set either by the user, or automatically if a troublesome compiler is detected. If Boost.Config could automatically detect and set a BOOST_NO_INITIALIZED_DATA flag, then the optional library is left with fairly simple code. To summarize, I suggest: 1. Lift none_t from detail to boost. 2. Improve docs wrt 'none' global instance. 3. Include none.hpp with optional unless the user/compiler dislikes it. Makes any sense? Yuval

3 5

using boost::format with STLPort
by Alexey Bakhvalov 23 Feb '05

23 Feb '05

Hello, I have a problem when I try to include "boost/format.hpp" from Boost 1.32 in a project that uses STLPort library. I am using MSVC 7.1 and the compiler prints the following error: \boost\format\format_implementation.hpp(216) : error C2244: 'boost::basic_format<Ch,Tr,Alloc>::size' : unable to match function definition to an existing declaration \boost\format\format_class.hpp(58) : see declaration of 'boost::basic_format<Ch,Tr,Alloc>::size' definition 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' existing declarations 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' If I switch back to Boost 1.31 or don't use STLPort then the problem goes away. I just wonder what can be the cause of such strange error because I can't see any difference between function's definition and declaration. Also I use many other Boost libraries and don't have this problem with either of them.

3 2

lapack bindings compiled fail with Visual C++ 7.1
by HHSU 23 Feb '05

23 Feb '05

Hi, I used VC7.1 and Boost_1.32_0 to compiled the SVD test file ( ublas_gesvd.cc) which download from http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/nume… I get the following error and warring messages: d:\upload\test\ublas_gesvd.cpp(61) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\ublas\traits.hpp(941) : warning C4267: 'argument' : conversion from 'size_t' to 'const unsigned int', possible loss of data c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\ublas\matrix_expression.hpp(4462) : see reference to class template instantiation 'boost::numeric::ublas::promote_traits<X,Y>' being compiled with [ X=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>::size_type, Y=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>::size_type ] d:\upload\test\ublas_gesvd.cpp(84) : see reference to class template instantiation 'boost::numeric::ublas::matrix_matrix_binary<E1,E2,F>' being compiled with [ E1=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>, E2=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>, F=boost::numeric::ublas::matrix_matrix_prod<real_t,real_t,boost::numeric::ublas::matrix_matrix_binary_traits<real_t,boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>,real_t,boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>>::promote_type> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\bindings\lapack\gesvd.hpp(281) : error C3861: 'assert': identifier not found, even with argument-dependent lookup d:\upload\test\ublas_gesvd.cpp(69) : see reference to function template instantiation 'int boost::numeric::bindings::lapack::gesvd<m_t,v_t,m_t,m_t,std::vector<_Ty>>(const char,const char,MatrA &,VecS &,MatrU &,MatrV &,VecW &)' being compiled with [ _Ty=real_t, MatrA=m_t, VecS=v_t, MatrU=m_t, MatrV=m_t, VecW=std::vector<real_t> ] What I am missing or doing wrong ? Bert.

1 1

boost::format bug?
by Orhun Birsoy 23 Feb '05

23 Feb '05

Hi, I am getting boost::io::too_many_args exceptions for the following line. cout << format(" %1% %3% \n") % 1 % 2 % 3 % 4 % 5; but not for this one cout << format(" %1% %5% \n") % 1 % 2 % 3 % 4 % 5; If the last argument is used in the format, I do not get the exception. Is this a bug? Thanks. Orhun Birsoy -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

[lexical_cast]: Converting a formatted string
by maha.ramanan＠philips.com 23 Feb '05

23 Feb '05

Hi, I am quite new to the iostreams and lexical cast and hence bear with me of any lack of knowledge. I am using the lexical cast in the following manner: unsigned int data_value = boost::lexical_cast<unsigned int>("0xFF"); The above comes out with a runtime bad_lexical_cast error. I understood, by default, the streams (stringstream used by lexical cast) should be able to automatically identify the radix of the input and convert it automatically. Is my above undestanding correct? Is lexical_cast meant to be used in this situation? Thanks for your help? Ram ======================================================================================= Mahadevan Ramanan Design Technology Centre DTG - Philips Semiconductors Milbrook Industrial Estate Tel: +44 (0) 23 8031 2540 Southampton, Hants SO15 0DJ Fax: +44 (0) 23 8031 2642 UK ====================================================================================== The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

1 0