- Boost - lists.boost.org

RE: [boost] Proxy indirect container adaptor: 4 claims
by Yitzhak Sapir 26 Feb '04

26 Feb '04

> -----Original Message----- > From: christian.engstrom(a)glindra.org > [mailto:christian.engstrom@glindra.org] > Sent: Thursday, February 26, 2004 4:40 PM > To: boost(a)lists.boost.org > Subject: [boost] Proxy indirect container adaptor: 4 claims > > --Is there a way to define a package for indirect containers, so that > one can take a program that uses a direct container, and > convert it to > using an indirect container just by changing the definition of the > container type? You could define a container adaptor that takes a container, and modifies the begin()/end() iterators to return indirect iterators to the original begin()/end(). Then instead of: typedef some_container container_type; you would have: typedef adaptor<some_container> container_type; > --Would it be any useful to be able to switch containers like that? > > The problem here is of course that "usefulness" is very much > in the eye > of the beholder, so all that I can say with certainty is that I > personally would find it quite useful, and that I don't see why other > people as well shouldn't sometimes find themselves in situations when > they would want to change container types easily. After all, > isn't one > of the great benefits of the STL containers that they have > (reasonably) > uniform interfaces, so that it's easy to switch between the different > container types, often by just changing a typedef? You might want to read "Beware the Illusion of container-independent code", by Scott Meyers in his book: http://www.awprofessional.com/isapi/content/images/0201749629/items/item2-2… The full book is at: http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407…

1 0

Re: Very odd Comeau C++ behavior
by Comeau Computing 26 Feb '04

26 Feb '04

Just a follow up that in addition to the work around previously sent below, there is now a patch that fixes the underlying problem. Holler if you need a revised compiler. - Greg At 08:40 PM 1/26/2004 +0200, Peter Dimov wrote: >While implementing operator== for boost::mem_fn, I found that the following >program, which I expected to print '1' six times, mysteriously outputs 1 0 1 >1 0 1 under Comeau C++, causing all mem_fn equality tests to fail: > >#include <iostream> > >struct X >{ > int mf0_1() { return 0; } > int mf0_2() { return 0; } >}; > >struct mf0 >{ > typedef int (X::*F) (); > F f_; > > explicit mf0(F f): f_(f) {} > > bool operator==(mf0 const & rhs) const > { > return f_ == rhs.f_; Thanks for the report, it appears you've uncovered a problem. It's being looked into further. For now, this should work: return f_ == rhs.f_ ? true : false; > } > > bool operator!=(mf0 const & rhs) const > { > return f_ != rhs.f_; As well as here: return f_ != rhs.f_ ? true : false; > } >}; > >int main() >{ > std::cout << ( &X::mf0_1 == &X::mf0_1 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) == mf0(&X::mf0_1) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ == mf0(&X::mf0_1).f_ ) << std::endl; > > std::cout << "--\n"; > > std::cout << ( &X::mf0_1 != &X::mf0_2 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) != mf0(&X::mf0_2) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ != mf0(&X::mf0_2).f_ ) << std::endl; >} > >Output: > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>como >testbed.cpp >Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86 >Copyright 1988-2002 Comeau Computing. All rights reserved. >MODE:strict errors C++ > > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>aout.exe >1 >0 >1 >-- >1 >0 >1 > >Is this a known issue with Comeau C++ 4.3? Or is there something wrong with >the code? ------- Comeau C/C++ 4.3.3: Offering core language support for C++03 Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau(a)comeaucomputing.com http://www.comeaucomputing.com

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] [snip] > > Sorry, during shortening my previous mail before posting, > one sentence > > got lost :) I was suggesting to add is_iterator, > > If you can figure out how to do that, you will be a hero to many. [snip] One way would be to check if the required iterator_traits are defined for the type, i.e. iterator_traits<T>::difference_type etc, using BOOST_MPL_HAS_XXX_TRAIT_DEF. Too fragile? Bjorn

2 1

Re: boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: Kevlin Henney [mailto:kevlin@curbralan.com] > I have yet to see a convincing reason to make it explicit. Autoboxing > has been a part of boost::any's design from day 1, which > existed before > Boost -- and, indeed, the "autoboxing" terminology. Supporting such > conversions was intentional. There is no more reason to make the > converting constructor of boost::any explicit than there is > to make the > converting constructor of std::string explicit, or the conversion from > int to long explicit, or the conversion from T * to void *, or indeed > any other widening conversion. Perhaps you could add this design decision as a FAQ in the documentation for any? Something like this (assuming a faq.xml among the any docs): <qandaentry> <question><para>Why isn't the parameterized constructor for <classname>boost::any</classname> explicit?</para></question> <answer> <para>The most important reason is that <classname>boost::any</classname> favors the convenience of implicit widening conversions over the additional safety of an explicit constructor. This design decision is fundamental for <code><classname alt="boost::any">any</classname></code>, so making the constructor explicit would require very convincing reasons. </para> <para>One useful idiom when the implicit construction of <code><classname alt="boost::any">any</classname></code> is considered a problem is to always pass <classname>boost::any</classname> by reference rather than by reference to <code>const</code>, or by value. This avoids implicit conversions of arguments to functions accepting <classname>boost::any</classname>. For example, the following example shows how to disable autoboxing for calls to the function <code>sample</code>: </para> <programlisting name="any.faq.pass_by_reference">void sample(boost::any& a) {} int main() { boost::any a(5); sample(a); // This works sample(5); // This won't compile }</programlisting> </answer> </qandaentry> If you like it, I'll update the docs. Bjorn

1 0

[utility] question on prior(x,n)
by Daniel Frey 26 Feb '04

26 Feb '04

Consider: // A strange way to retrieve my_container.begin(): boost::prior( my_container.end(), my_container.size() ); Is that legal? The second template parameter of boost::prior is deduced to an unsigned(!) type, which IMHO means that -n is undefined, right? Do we need to fix this? Maybe: template <class T> T prior(T x, typename T::difference_type n) { std::advance(x, -n); return x; } or shall we document that it's illegal/undefined to call boost::prior() with an unsigned second parameter? Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey(a)aixigo.de, web: http://www.aixigo.de

5 17

small addition to functional
by John Torjo 26 Feb '04

26 Feb '04

Hi all, I think since member functions can be wrapped up as functors, why not same for member data? Therefore, I think this could be a useful addition to functional: // wraps a member data into a functor // // very useful with boost::bind template<class type, class member_type> class mem_data_t { typedef member_type type::*data; public: // FIXME allow also having non-const result-type typedef const member_type & result_type; mem_data_t( data d) : m_data(d) {} const member_type & operator()( const type & val) const { return val.*m_data; } member_type & operator()( type & val) const { return val.*m_data; } private: data m_data; }; template<class type, class member_type> mem_data_t<type,member_type> mem_data(member_type type::*data) { return mem_data_t<type,member_type>(data); } It can be improved, but roughly, that's it. What do you think? Best, John

1 1

RE: [Boost-users] Re: about license
by Darryl Green 26 Feb '04

26 Feb '04

Cross posted from boost-users... > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Wednesday, 25 February 2004 11:43 AM > Marleny Rafferty <marleny(a)rafferty.net> writes: > > > Hi- > > > > I am considering using boost in my applications, but I have > a question > > about the boost license at > http://www.boost.org/LICENSE_1_0.txt . It > > says (edited) > "Permission is hereby granted, free of charge, to ... > > use [and] reproduce ... the Software". > > > > It also says that any derivative works must also have the > same license > > grant. > > > > If my application uses boost libraries unchanged, is it considered a > > derivative work? > > Yes. Really? The ligitimacy of this stance seems questionable (but ianal etc). Further I did not see it as being part of the objectives for the license. Quite the opposite in fact. > > > If so, does that mean that if I distribute my compiled software, I > > must allow free of charge use and distribution? > > No, the license gives an explicit exemption for compiled code > (emphasis mine): [let me just re-insert some additioanl context here] ! The copyright notices in the Software and this entire statement ! ... ! must be included in all copies of the Software, in whole or in part, and > > all derivative works of the Software, UNLESS SUCH COPIES OR DERIVATIVE > WORKS ARE SOLELY IN THE FORM OF MACHINE-EXECUTABLE OBJECT > CODE GENERATED BY > A SOURCE LANGUAGE PROCESSOR. > I took this to mean that nobody can delete/change the copyright/license in the sources if they copy or produce a derivative work but that there is no need to include the license in a binary distribution. It did not occur to me that leaving the license in place somehow forms a viral attachment to other source in a source distribution. It potentially makes this license incompatible with the intent of other (open and closed) source licenses eg. // some_gpled_source_file.cpp // this file is distributed under the gpl // changed some stuff so we use boost libs #include <some_boost_lib> // oops - now it is some boost/gpl hybrid?????? I thought avoiding this sort of thing was precisely why the boost license was developed. I also thought this interpretation of "derived work" was somewhat contentious anyway. In a commercial context, this interpretation appears to make this license hopeless - anyone obtaining a copy of source code which uses boost (which you appear to be claiming is automatically a derivative work), appears to be free to do what they like with it. It is hardly reasonable that this occur if a company distributes source code with some particular intent/license for its use. That is even without considering the issue of copies obtained without the company/authors permission, whether the copy was obtained accidentally or criminally, and then redistributed. I'm keen to stop people copying my commercial executables, but I'm a lot more keen to stop them running off with the source code! A bit of digging through the archives finds http://aspn.activestate.com/ASPN/Mail/Message/boost/1686928 Which seems to explain why I thought the intent was what I understood it to be. Whatever the conclusion I think this needs to be in the FAQ. Regards Darryl Green. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

Small update to bibliography
by Fredrik Blomqvist 26 Feb '04

26 Feb '04

Hi, This patch adds a couple of references to the bibliography. // Fredrik Blomqvist begin 666 bibliography.patch M26YD97@Z(&UO<F4O8FEB;&EO9W)A<'DN:'1M; T*/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/0T*4D-3(&9I;&4Z("]C=G-R;V]T+V)O;W-T+V)O;W-T+VUO<F4O M8FEB;&EO9W)A<'DN:'1M;"QV#0IR971R:65V:6YG(')E=FES:6]N(#$N- T* M9&EF9B M=2 M<C$N-"!B:6)L:6]G<F%P>2YH=&UL#0HM+2T@;6]R92]B:6)L M:6]G<F%P>2YH=&UL"3(R($IA;B R,# T(#$Y.C,V.C$X("TP,# P"3$N- T* M*RLK(&UO<F4O8FEB;&EO9W)A<'DN:'1M; DQ,"!&96(@,C P-" Q.3HT-SHP M.2 M,# P, T*0$ @+3(V,2PV("LR-C$L,3(@0$ -"B )"0D)/"]T9#X-"B ) M"0D\+W1R/@T*( D)"3Q44CX-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A;&EG M;CTB;&5F="(@=VED=&@](C$V)2(^/&(^6SQA(&YA;64](D)U<FYA<%\P,B(^ M0G5R;F%P(# R/"]A/ET\+V(^/"]41#X-"BL)"0D)/%1$('9!;&EG;CTB=&]P M(B!A;&EG;CTB;&5F="(@=VED=&@](C@T)2(^4W1E=F5N(%(N($)U<FYA<"P@ M/&D^0F]O<W0Z.F%N>3PO:3XL( T**PD)"0D)2W5R;S5H:6XL($UA>2 Q+" R M,# R+B \02!H<F5F/2)H='1P.B\O=W=W+FMU<F\U:&EN+F]R9R]S=&]R>2\R M,# R+S4O,2\Q-#(S,C$O.34Q,R(^#0HK"0D)"0D)=W=W+FMU<F\U:&EN+F]R M9R]S=&]R>2\R,# R+S4O,2\Q-#(S,C$O.34Q,SPO03X\+U1$/@T**PD)"3PO M5%(^#0HK"0D)/%12/@T*( D)"0D\5$0@=D%L:6=N/2)T;W B(&%L:6=N/2)L M969T(B!W:61T:#TB,38E(CX\8CY;/&$@;F%M93TB0V%R8F]N7S R(CY#87)B M;VX@,#(\+V$^73PO8CX\+U1$/@T*( D)"0D\5$0@=D%L:6=N/2)T;W B(&%L M:6=N/2)L969T(B!W:61T:#TB.#0E(CY$879I9"!3/RP@/&D^0F]O<W0@.B!4 M:&4@:&%N9'D@;&EB<F%R>2!O9B -"B )"0D)"0EH86YD>2!L:6)R87)I97,\ M+VD^+B!+=7)O-6AI;BP@2G5L>2 Q."P@,C P,BX@/$$@:')E9CTB:'1T<#HO M+W=W=RYK=7)O-6AI;BYO<F<O<W1O<GDO,C P,B\W+S$X+S,S,3,O,#$T,CDB M/@T*0$ @+3(X,"PV("LR.#8L,34@0$ -"B )"0D)"0EW:71H('1H92!";V]S M="!'<F%P:"!,:6)R87)Y/"]I/BX@26YF;W)M250L($UA<F-H(#$L(#(P,#(N M(#Q!(&AR968](FAT=' Z+R]T:6YY=7)L+F-O;2\R-F1W:B(^#0H@"0D)"0D) M=&EN>75R;"YC;VTO,C9D=VH\+T$^/"]41#X-"B )"0D\+U12/@T**PD)"3Q4 M4CX-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A;&EG;CTB;&5F="(@=VED=&@] M(C$V)2(^/&(^6SQA(&YA;64](DQI<V-H;F5R7S S(CY,:7-C:&YE<B P,SPO M83Y=/"]B/CPO5$0^#0HK"0D)"3Q41"!V06QI9VX](G1O<"(@86QI9VX](FQE M9G0B('=I9'1H/2(X-"4B/@T**PD)"0D)/% ^4F%Y($QI<V-H;F5R+" \:3Y# M*RLZ($)E>6]N9"!T:&4@4W1A;F1A<F0@3&EB<F%R>3PO:3XN($\G4F5I;&QY M($YE='=O<FLL($UA>2 V+" -"BL)"0D)"0DR,# S+B \02!H<F5F/2)H='1P M.B\O=W=W+F]R96EL;'EN970N8V]M+VQP="]A+S,V.#,B/G=W=RYO<F5I;&QY M;F5T+F-O;2]L<'0O82\S-C@S/"]!/CPO4#X-"BL)"0D)"3Q0/DUE;G1I;VYS M(#Q#3T1%/G1U<&QE<RP@<VAA<F5D7W!T<BP@;&%M8F1A+"!S<&ER:70\+T-/ M1$4^+@T**PD)"0D)/"]0/@T**PD)"0D\+U1$/@T**PD)"3PO5%(^#0H@"0D\ M+W1A8FQE/@T*( D)/&@R/DAO=R!T;R \82!N86UE/2)U<&1A=&4B/G5P9&%T M93PO83X@=&AI<R!P86=E/"]H,CX-"B )"3QP/E!L96%S92!H96QP('5S(&ME M97 @=&AI<R!P86=E('5P9&%T960@+2!U<V5R<R!C86X@<&]S="!N97<@8VET M871I;VYS('1O('1H92 -"D! ("TS,#0L,3 @*S,Q.2PQ,"! 0 T*( D)/&@R M/CQA(&YA;64](D%C:VYO=VQE9&=E;65N=',B/D%C:VYO=VQE9&=E;65N=',\ M+V$^/"]H,CX-"B @(" @(" @(#QP/D9R961R:6L@0FQO;7%V:7-T('!R;W9I M9&5D(&UA;GD@;V8@=&AE(&EN:71I86P@8VET871I;VYS+CPO<#X-"B )"3QH M<CX-"BT)"3QP/E)E=FES960@,C$@2F%N=6%R>2 R,# T/"$M+7=E8F)O="!B M;W0](E1I;65S=&%M<"(@96YD<W!A;B!I+6-H96-K<W5M/2(S,C(W-R(@+2T^ M/"]P/@T**PD)/' ^4F5V:7-E9" Q,"!&96)R=6%R>2 R,# T/"$M+7=E8F)O M="!B;W0](E1I;65S=&%M<"(@96YD<W!A;B!I+6-H96-K<W5M/2(S,C(W-R(@ M+2T^/"]P/@T*( D)/' ^J2!#;W!Y<FEG:'0@0F5M86X@1&%W97,@,C P,SPO M<#X-"B )"3QP/E5S92P@;6]D:69I8V%T:6]N+"!A;F0@9&ES=')I8G5T:6]N M(&%R92!S=6)J96-T('1O('1H92!";V]S="!3;V9T=V%R92!,:6-E;G-E+" - M"B )"0E697)S:6]N(#$N,"X@*%-E92!A8V-O;7!A;GEI;F<@9FEL92 \02!H M<F5F/2(N+B],24-%3E-%7S%?,"YT>'0B/DQ)0T5.4T5?,5\P+G1X=#PO03X- M"B )"0EO<B!C;W!Y(&%T(#QA(&AR968](FAT=' Z+R]W=W<N8F]O<W0N;W)G M+TQ)0T5.4T5?,5\P+G1X="(^=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT M>'0\+V$^*3PO<#X-"B )/"]B;V1Y/@T*+3PO:'1M;#X-"EP@3F\@;F5W;&EN <92!A="!E;F0@;V8@9FEL90T**SPO:'1M;#X-"@`` ` end

2 2

Host IP changing Thursday
by Beman Dawes 26 Feb '04

26 Feb '04

The system administrators at Indiana University are planning to change the Boost mailing lists to a new host IP address Thursday. Although the changeover itself will happen very quickly, it will take some time for the DNS change to propagate. Boost's DNS usually specifies 6 hour refreshes and 12 hour "Time to Live". We will cut that to 1 hour each from now until it is clear the change is working well. So you should see no more than a two hour outage. The last time we did something like this it went pretty smoothly, but a few people had trouble with cached copies of the IP address for a few days. Anyhow, be aware that change is coming Thursday, and that mailing list response time will be longer than usual during the changeover. Thanks, --Beman

1 0

Informal review for RTL
by Arkadiy Vertleyb 26 Feb '04

26 Feb '04

Dear Boosters, We would like to ask for an informal review of our Relational Template Library (RTL). In particular we would like to find out whether you think that: 1) relational algebra is a useful instrument for C++ programmers; 2) The solution based on template meta-programming is suitable for such library; 3) RTL itself is a good start, and, with some changes and corrections, can expect to eventially become part of Boost (if not -- why?). Another question we woulld like to ask is which areas do you think might benefit from such library, like, maybe, games, firewalls, etc. The library has been tested with VC7.1 and GCC 3.3. It is located at: http://groups.yahoo.com/group/boost/files/tables.zip Thanks, Arkadiy _________________________________________________________________ Dream of owning a home? Find out how in the First-time Home Buying Guide. http://special.msn.com/home/firsthome.armx

5 6