- Boost - lists.boost.org

Named params library and BGL
by Vladimir Prus 19 Apr '04

19 Apr '04

I've just made an attempt to use the named parameters library (currently in review queue, and available at http://groups.yahoo.com/group/boost/files/named_params.zip) to simply properties in BGL. Currently, to initialize all properties one has to do: edge_descriptor e = add_edge(....); put(e, g, vertex_color, 10); put(e, g, vertex_name, "foo"); I hope that with the named parameters library it will be possible to do: add_edge(v1, v2, (vertex_color = 10, vertex_name = "foo"), g); I've tried to implement this idea, but run into the problems. First issue is documentation: it gives foo_impl(foo_keywords(a0)); as example, while the code uses: return f_impl(f_keywords()(t, name_)); Which has extra '()' after f_keywords. The second problem is that I need to create a type for 'keywords' (derived from 'keywords<...>' and use it for passing arguments). The docs suggest to create a number of forwarding functions, but given that a number of vertex properties can be rather large (and is actually unbounded), this does not seem good. So, now can do: vertex_property p = prop_keywords()(color = 10, name = "foo"); but I'd rather like: vertex_property p((color = 10, name = "foo")); So, the operator, will be overloaded to create something I can index with 'tag type' and get a value. In fact, this will allow to avoid declaring 'pop_keywords' -- since again, user can declare it's own keywords so it's not clear how to define that class. The example I've played with is at: http://zigzag.cs.msu.su:7813/p.cpp Comments are appreciated. - Volodya

4 9

RE: Boost Digest, Vol 700, Issue 1
by S G Ganesh 19 Apr '04

19 Apr '04

I am an engineer in HP's aCC compiler team. We are actively working on Boost defects and the internal developmental version of the compiler compiles many of the Boost libraries successfully. There is a compiler patch (for both PA and IPF) coming up by end of this month: if any of you are interested and have a support contract, you can register for beta testing. The current compiler status for aCC shows that the pass percentage is dismal 26%, but with this patch, it should be more than 70% (we are working on improving it further). Many libraries, such as regex, bind, any, thread already compile successfully with this patch compiler. Please note that the fixes are in the compiler without modifying the Boost sources; we came across a few defects in the Boost sources which we can share with you so that they can be fixed (or provide a workaround or #ifdefed). It would be great if we can work together to resolve any issues, which will be mutually beneficial. If you come across any defects in the compiler while compiling the Boost sources, you can file bug reports for the same. Any issues on developing with aC++ compiler will be immediately responded in cxx-dev(a)cup.hp.com newsgroup. -Ganesh S G Ganesh HP PA C++ Compiler Front-end Team Phone: +91-80-2205 1832 ------------------------------ Message: 15 Date: Sat, 17 Apr 2004 11:54:11 +0100 From: "John Maddock" <john(a)johnmaddock.co.uk> Subject: Re: [boost] boost on HP-UX 11i To: <boost(a)lists.boost.org> Message-ID: <06af01c4246a$58c62350$cbfc0352@fuji> Content-Type: text/plain; charset="iso-8859-1" > I recently downloaded boost libraries to use the smart_ptr libraries. It > appears to be working. But several other libraries, as shown by the > compiler report is not. I also noticed that last run date is 9 months > ago. Is anybody working on getting boost to work on aCC? I would be very > surprised if nobody has tried before since HP is a top-tier vendor, but > I couldn't find any useful information from the archives. If not, I > would like to take a stab at getting it to work. I have contact with HP > aCC techs to fix problems if it is a compiler problem. I'm particularly > interested in getting the libraries regex and spirit (for now, more > later) to work. I did a search on the boost archive and the last > reference to this subject was written back in August 14, 2003: I'd love to see regex working with aCC if it's humanly possible, if you want to mail me privately with any queries you may have that would be fine - especially if you have a working relationship with HP personnel - we've managed to persuade quite a few other vendors to work with us, and even to use Boost for their internal regression tests, HP is one of the notable exceptions so far :-| John.

2 1

serialization: review
by Thorsten Ottosen 19 Apr '04

19 Apr '04

Hi Robert, Here is my review of your library. a.. What is your evaluation of the design? Seems fine. I have a few issues though. Why isn't there a base class for all archieves? I think that would be useful with class hierachies...for example, I need to implement two function and cannot use & anymore. Consider this struct mammal : boost::noncopyable { private: friend class boost::serialization::access; virtual void do_serialize( boost::archive::text_oarchive& ar, unsigned version ) = 0; virtual void do_serialize( boost::archive::text_iarchive& ar, unsigned version ) = 0; template< class Archive > void serialize( Archive & ar, unsigned version ) { do_serialize( ar, version ); } public: virtual const std::string& name() const = 0; virtual unsigned age() const = 0; virtual ~mammal() {} }; Some way of supporting only one do_serialize() to preserve the order would be nice. a.. What is your evaluation of the implementation? There are some minor compiler problems and suggestions listed below. I can't figure out exactly how the library save/loads pointers when these cannot be allocated on the stack. a.. What is your evaluation of the documentation? I already gave some feedback on the introduction. In general it seems ok. I like the comparison with other lbraries. I miss more specific type requirements. For example, is it necessary to have a default constructor? Is it necessary to be stack-allocable? must the destructor be public? a.. What is your evaluation of the potential usefulness of the library? It's certainly useful. a.. Did you try to use the library? With what compiler? Did you have any problems? yes, see below. I can compile my code with vc71, gcc3.3 comeau 4.3.3. a.. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5 hours. It's neither a glance nor an in-depth study. I did try to extend the library to use my new smart containers; I was almost sucessful. a.. Are you knowledgeable about the problem domain? hm...no. a.. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion yes. But I think the pointer part of the library need to be given extra thought; I would like to see the focus shift from vector<T*> towards vector< shared_ptr<T> > and ptr_vector<T>. using T* array[sz] or vector<T*> is inherently unsafe if the pointers are heap-allocated. I tried to extend the library to support my smart containers, but I coulnd't figure out what I did wrong. I think I might have saved them correctly, but I cannot figure out to load them. However, I do think that is a problem that can be solved together with Robert. (Robert, you can find the ptr_vector in the sandbox. If you could cast a glance on the code and tell me how the body of load_collection should look like, it would be great.) freestanding libraries: Obvious candidates are (a) BOOST_STRONG_TYPEDEF (could maybe be part of utility) (b) dataflow_iterators best regards Thorsten ---------- Some general nitpicks/comments (with these comments my test works on vc71, como4.3.3, g++3.3.1: 1. have you planned to use concept checks 2. documentation: can the width of the html be made adaptive to the window width? The right window must be scrolled to see it's contents which is annoying. 3. const members uses a const-cast to re-init them. AFAICT, this is undefined behavior (cmp 7.1.5.1). I guess the need for serialization is just another reason for not having const members. 4. AFAICR, the use of placement new require proper alignment, so the object must eg. be heap-allocated. Is that guaranteed? 5. I think the exception code should be returned by a function: exception_code code() const; this is how eg. the regex_error exception in tr1 will do it. 6. remove trailing comma in archive_exception.hpp: "unregistered_cast // base - derived relationship not registered with" 7. archive/detail/basic_oarchive.hpp includes itself 8. is_abstract.hpp: there is something wierd about the is_abstact struct. I uncommented the first part to be able to compile. 9. serialization/serialization.hpp: why all the static casts? template<class Archive, class T> inline void serialize( Archive & ar, T & t, const BOOST_PFTO unsigned int file_version ){ access::serialize(ar, t, static_cast<const unsigned int>(file_version)); } AFAICT, they should be removed. Comeau has the follwing warning: type qualifier is meaningless on cast type 10. nvp.hpp: line 50: ar & t.value(); There is on t-parameter. 11. /archive/detail/oserializer.hpp", line 244: NULL reference is not allowed return * static_cast<const basic_pointer_oserializer *>(NULL); ^ This not yet legal C++ (but the committee is changing that) use a static member and return that instead. Also, why all the static_casts? 12. two-phase lookup problems: /boost/archive/basic_text_oarchive.hpp", line 65: error #20: identifier "This" is undefined archive::save(* This(), t); ^ Solution: prefix base class functions with this->. remark: why is this->This()->XX() necessary? this->xx() should do it. 13: archive/text_oarchive.hpp, similar lookup problems. this->newtoken(), this->delimiter = this->none; 14: /archive/detail/basic_iarchive.hpp", line 46: error #20: identifier "basic_iarchive_impl" is undefined boost::scoped_ptr<basic_iarchive_impl> pimpl; ^ solution: remember to forward declare basic_iarchieve_impl. Do the same for basic_oarchieve_impl. 15: /archive/detail/archive_pointer_iserializer.hpp", line 42: error #284: (+detail/iserializer.hpp", line 240:) NULL reference is not allowed return *static_cast<const basic_iserializer *>(NULL); ^ Solution: use a static member again. 16: two-phase lookup problems in archive/basic_text_iarchive.hpp", Solution: prefix by this->. 17. when you save_collection_impl.hpp (eg in vector.hpp) there is no need to specify template arguments again since they will be deduced. 18. implementation of save_collection(). you cannot use unsigned int count portably. Instead you should use the new collection traits (reviewed after this review) as follows: typename boost::size_type_of< Collection >::type count = size( s ); then the code will also work for iterator views and arrays. Similar comments apply to load_collection_impl.hpp 19. missing #include <boost/serialization/nvp.hpp> in serialization.hpp begin 666 smart_container.cpp M(VEN8VQU9&4@/&9S=')E86T^#0HC:6YC;'5D92 \<W1R:6YG/@T*(VEN8VQU M9&4@/&EO<W1R96%M/@T*(VEN8VQU9&4@/&)O;W-T+V%R8VAI=F4O=&5X=%]O M87)C:&EV92YH<' ^#0HC:6YC;'5D92 \8F]O<W0O87)C:&EV92]T97AT7VEA M<F-H:79E+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T:6]N+W-T M<FEN9RYH<' ^#0HC:6YC;'5D92 \8F]O<W0O<V5R:6%L:7IA=&EO;B]V97)S M:6]N+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T:6]N+W-P;&ET M7VUE;6)E<BYH<' ^#0HC:6YC;'5D92 \8F]O<W0O<V5R:6%L:7IA=&EO;B]V M96-T;W(N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+W-E<FEA;&EZ871I;VXO97AP M;W)T+FAP<#X-"B-I;F-L=61E(#QB;V]S="]P=')?8V]N=&%I;F5R+W!T<E]V M96-T;W(N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+V%S<VEG;B]S=&PN:'!P/@T* M(VEN8VQU9&4@/&)O;W-T+VYO;F-O<'EA8FQE+FAP<#X-"@T*+R\O+R\O+R\O M+R\O+R\O+R\O+R\O+R\O+R\O+PT*+R\@<'1R('9E8W1O<B!S97)I86QI>F%T M:6]N#0H-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T:6]N+V-O;&QE8W1I M;VYS7W-A=F5?:6UP+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T M:6]N+V-O;&QE8W1I;VYS7VQO861?:6UP+FAP<#X-"B-I;F-L=61E(#QB;V]S M="]S97)I86QI>F%T:6]N+W-P;&ET7V9R964N:'!P/@T*#0IT96UP;&%T93QC M;&%S<R!!<F-H:79E+"!C;&%S<R!5+"!C;&%S<R!!;&QO8V%T;W(^#0II;FQI M;F4@=F]I9"!S879E* T*(" @($%R8VAI=F4@)B!A<BP-"B @("!C;VYS="!B M;V]S=#HZ<'1R7W9E8W1O<CQ5+"!!;&QO8V%T;W(^("9T+ T*(" @('5N<VEG M;F5D(&EN="!F:6QE7W9E<G-I;VX-"BD-"GL-"B @("!B;V]S=#HZ<V5R:6%L M:7IA=&EO;CHZ<W1L.CIS879E7V-O;&QE8W1I;VXH(&%R+"!T("D[#0I]#0H- M"G1E;7!L871E/&-L87-S($%R8VAI=F4L(&-L87-S(%4L(&-L87-S($%L;&]C M871O<CX-"FEN;&EN92!V;VED(&QO860H#0H@(" @07)C:&EV92 F(&%R+ T* M(" @(&)O;W-T.CIP=')?=F5C=&]R/%4L($%L;&]C871O<CX@)G0L#0H@(" @ M=6YS:6=N960@:6YT(&9I;&5?=F5R<VEO;@T**0T*>PT*+RH@,2X@8V]M<&EL M97,L(&)U="!C<F%S:&5S#0H@(" @(" @('-T;#HZ;&]A9%]C;VQL96-T:6]N M/ T*(" @(" @("!!<F-H:79E+ T*(" @(" @("!B;V]S=#HZ<'1R7W9E8W1O M<CQ5+"!!;&QO8V%T;W(^+ T*(" @(" @("!S=&PZ.F%R8VAI=F5?:6YP=71? M<V5Q/$%R8VAI=F4L(&)O;W-T.CIP=')?=F5C=&]R/%4L($%L;&]C871O<CX@ M/BP-"B @(" @(" @<W1L.CIR97-E<G9E7VEM<#QB;V]S=#HZ<'1R7W9E8W1O M<CQ5+"!!;&QO8V%T;W(^(#X-"B @(" ^*&%R+"!T*3L-"B @(" J+PT*?0T* M#0HO+R!S<&QI="!N;VXM:6YT<G5S:79E('-E<FEA;&EZ871I;VX@9G5N8W1I M;VX@;65M8F5R(&EN=&\@<V5P87)A=&4-"B\O(&YO;B!I;G1R=7-I=F4@<V%V M92]L;V%D(&UE;6)E<B!F=6YC=&EO;G,-"G1E;7!L871E/&-L87-S($%R8VAI M=F4L(&-L87-S(%4L(&-L87-S($%L;&]C871O<CX-"FEN;&EN92!V;VED('-E M<FEA;&EZ92@-"B @("!!<F-H:79E("8@87(L#0H@(" @8F]O<W0Z.G!T<E]V M96-T;W(\52P@06QL;V-A=&]R/B F('0L#0H@(" @8V]N<W0@=6YS:6=N960@ M:6YT(&9I;&5?=F5R<VEO;@T**7L-"B @("!S<&QI=%]F<F5E*&%R+"!T+"!F M:6QE7W9E<G-I;VXI.PT*?0T*#0H-"B\O+R\O+R\O+R\O+R\O+R\O+PT*+R\@ M8VQA<W,@:&EE<F%C:'D-"@T*<W1R=6-T(&UA;6UA;" Z(&)O;W-T.CIN;VYC M;W!Y86)L90T*>PT*<')I=F%T93H-"B @(" -"B @("!F<FEE;F0@8VQA<W,@ M8F]O<W0Z.G-E<FEA;&EZ871I;VXZ.F%C8V5S<SL-"B @("!V:7)T=6%L('9O M:60@9&]?<V5R:6%L:7IE*"!B;V]S=#HZ87)C:&EV93HZ=&5X=%]O87)C:&EV M928@87(L('5N<VEG;F5D('9E<G-I;VX@*2 ](# [#0H@(" @=FER='5A;"!V M;VED(&1O7W-E<FEA;&EZ92@@8F]O<W0Z.F%R8VAI=F4Z.G1E>'1?:6%R8VAI M=F4F(&%R+"!U;G-I9VYE9"!V97)S:6]N("D@/2 P.PT*(" @( T*(" @('1E M;7!L871E/"!C;&%S<R!!<F-H:79E(#X-"B @("!V;VED('-E<FEA;&EZ92@@ M07)C:&EV92 F(&%R+"!U;G-I9VYE9"!V97)S:6]N("D-"B @("![#0H@(" @ M(" @(&1O7W-E<FEA;&EZ92@@87(L('9E<G-I;VX@*3L-"B @("!]#0H@(" @ M#0IP=6)L:6,Z#0H-"B @("!V:7)T=6%L(&-O;G-T('-T9#HZ<W1R:6YG)B!N M86UE*"D@8V]N<W0@/2 P.PT*(" @('9I<G1U86P@=6YS:6=N960@(" @(" @ M(" @(&%G92@I(&-O;G-T(" ](# [#0H@(" @(" @(" @#0H@(" @=FER='5A M;"!^;6%M;6%L*"D@>WT-"GT[#0H-"G-T9#HZ;W-T<F5A;28@;W!E<F%T;W(\ M/"@@<W1D.CIO<W1R96%M)B!O<RP@8V]N<W0@;6%M;6%L)B!M("D-"GL-"B @ M("!R971U<FX@;W,@/#P@(FYA;64@/2 B(#P\(&TN;F%M92@I(#P\("(@86=E M(#T@(B \/"!M+F%G92(a)I.R -"GT-"@T*<W1R=6-T(&%P92 Z('!U8FQI8R!M M86UM86P-"GL-"B @("!A<&4H*3L-"B @("!A<&4H(&-O;G-T('-T9#HZ<W1R M:6YG)B!N86UE+"!U;G-I9VYE9"!A9V4@*3L-"B @("!V:7)T=6%L(&-O;G-T M('-T9#HZ<W1R:6YG)B!N86UE*"D@8V]N<W0[#0H@(" @=FER='5A;"!U;G-I M9VYE9" @(" @(" @(" @86=E*"D@8V]N<W0[#0IP<FEV871E.@T*(" @('9I M<G1U86P@=F]I9"!D;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT M7V]A<F-H:79E)B!A<BP@=6YS:6=N960@=F5R<VEO;B I.PT*(" @('9I<G1U M86P@=F]I9"!D;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7VEA M<F-H:79E)B!A<BP@=6YS:6=N960@=F5R<VEO;B I.PT*(" @( T*(" @('-T M9#HZ<W1R:6YG(" @;F%M95\[#0H@(" @=6YS:6=N960@(" @("!A9V5?.PT* M?3L-"@T*<W1R=6-T('=H86QE(#H@<'5B;&EC(&UA;6UA; T*>PT*(" @('=H M86QE*"D[#0H@(" @=VAA;&4H(&-O;G-T('-T9#HZ<W1R:6YG)B!N86UE+"!U M;G-I9VYE9"!A9V4@*3L-"B @("!V:7)T=6%L(&-O;G-T('-T9#HZ<W1R:6YG M)B!N86UE*"D@8V]N<W0[#0H@(" @=FER='5A;"!U;G-I9VYE9" @(" @(" @ M(" @86=E*"D@8V]N<W0[#0IP<FEV871E.@T*(" @('9I<G1U86P@=F]I9"!D M;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7V]A<F-H:79E)B!A M<BP@=6YS:6=N960@=F5R<VEO;B I.PT*(" @('9I<G1U86P@=F]I9"!D;U]S M97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7VEA<F-H:79E)B!A<BP@ M=6YS:6=N960@=F5R<VEO;B I.PT*(" @( T*(" @('-T9#HZ<W1R:6YG(" @ M;F%M95\[#0H@(" @=6YS:6=N960@(" @("!A9V5?.PT*?3L-"@T*0D]/4U1? M0TQ!4U-?15A03U)47T=5240H(&%P92P@(F%P92(@*0T*0D]/4U1?0TQ!4U-? M15A03U)47T=5240H('=H86QE+" B=VAA;&4B("D-"@T*+R\O+R\O+R\O+R\O M+R\O+R\-"B\O(&]R9&5R:6YG<PT*#0IS=')U8W0@:6Y?;F%M95]O<F1E<@T* M>PT*(" @(&)O;VP@;W!E<F%T;W(H*2@@8V]N<W0@;6%M;6%L)B!L+"!C;VYS M="!M86UM86PF('(@*0T*(" @('L-"B @(" @(" @<F5T=7)N(&PN;F%M92@I M(#P@<BYN86UE*"D[#0H@(" @?0T*?3L-"@T*+R\O+R\O+R\O+R\O+R\O+R\- M"B\O('1E<W0-"@T*:6YT(&UA:6XH*0T*>PT*(" @('1R>0T*(" @('L-"@T* M(" @(" @("!U<VEN9R!N86UE<W!A8V4@8F]O<W0Z.F%S<VEG;FUE;G0[#0H@ M(" @(" @( T*(" @(" @("!B;V]S=#HZ<'1R7W9E8W1O<CQM86UM86P^('9E M8SL-"B @(" @(" @+R\@87-S:6=N('!O<W-I8FEL:71Y.B!O;F4@;75S="!B M92!A8FQE('1O('-P96-I9GD@=&AE('1Y<&4@=&\@8V]N<W1R=6-T#0H@(" @ M(" @("\O(&5G#0H@(" @(" @("\O('!T<E]A<W-I9VX\87!E/B@@=F5C("DH M(E@B+"!Y("D[(&%S<VEG;CQA<&4^*"!V96,@*2 ](&YE=R!!<&4H(")8(BP@ M>2 I.R -"B @(" @(" @+R\@<'1R7V%S<VEG;CQW:&%L93XH('9E8R I*")8 M(BP@>2 I.R -"B @(" @(" @=F5C("L](&YE=R!A<&4H(")&<F%N:R(L(#$R M("DL(&YE=R!A<&4H(")"971T>2(L(#D@*2P@;F5W('=H86QE*" B2F]N87,B M+" S," I+"!N97<@=VAA;&4H(")'97)D82(L(#(T("D[#0H@(" @(" @("\O M=F5C+G-O<G0H(&EN7VYA;65?;W)D97(H*2 I.PT*(" @(" @(" -"B @(" @ M(" @<W1D.CIO9G-T<F5A;2!O9G,H(")M86UM86QS+F1A="(@*3L-"B @(" @ M(" @8F]O<W0Z.F%R8VAI=F4Z.G1E>'1?;V%R8VAI=F4@;W5T7W1E>'0H(&]F M<R I.PT*(" @(" @("!O=71?=&5X=" \/"!V96,[#0H@(" @(" @(&]F<RYC M;&]S92(a)I.PT*(" @(" @("!S=&0Z.FEF<W1R96%M(&EF<R@@(FUA;6UA;',N M9&%T(B I.PT*(" @(" @("!B;V]S=#HZ87)C:&EV93HZ=&5X=%]I87)C:&EV M92!I;E]T97AT*"!I9G,@*3L-"B @(" @(" @8F]O<W0Z.G!T<E]V96-T;W(\ M;6%M;6%L/B!C;W!Y.PT*(" @(" @("!I;E]T97AT(#X^(&-O<'D[#0H@(" @ M(" @( T*(" @(" @("!F;W(H('-I>F5?="!I(#T@,#L@:2 \('9E8RYS:7IE M*"D[("LK:2 I#0H@(" @(" @(" @("!S=&0Z.F-O=70@/#P@=F5C6VE=(#P\ M(&-O<'E;:5T@/#P@)UQN)SL-"B @("!]#0H@(" @8V%T8V@H('-T9#HZ97AC M97!T:6]N)B!E("D-"B @("![#0H@(" @(" @('-T9#HZ8V]U=" \/"!E+G=H M870H*3L@#0H@(" @?0T*?0T*#0HO+R\O+R\O+R\O+R\O+R\O+R\O+R\O#0HO M+R!I;7!L96UE;G1A=&EO;B!A<&4-"@T*87!E.CIA<&4H*0T*>PT*?0T*#0IA M<&4Z.F%P92@@8V]N<W0@<W1D.CIS=')I;F<F(&YA;64L('5N<VEG;F5D(&%G M92 I(#H@;F%M95\H(&YA;64@*2P@86=E7R@@86=E("D-"GL-"GT-"B @(" - M"F-O;G-T('-T9#HZ<W1R:6YG)B!A<&4Z.FYA;64H*2!C;VYS= T*>PT*(" @ M(')E='5R;B!N86UE7SL-"GT-"B @(" -"G5N<VEG;F5D(&%P93HZ86=E*"D@ M8V]N<W0-"GL-"B @("!R971U<FX@86=E7SL-"GT-"B @(" -"G9O:60@87!E M.CID;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7V]A<F-H:79E M)B!A<BP@=6YS:6=N960@=F5R<VEO;B I#0I[#0H@(" @87(@/#P@;F%M95\@ M/#P@86=E7SL-"GT-"@T*=F]I9"!A<&4Z.F1O7W-E<FEA;&EZ92@@8F]O<W0Z M.F%R8VAI=F4Z.G1E>'1?:6%R8VAI=F4F(&%R+"!U;G-I9VYE9"!V97)S:6]N M("D-"GL-"B @("!A<B ^/B!N86UE7R ^/B!A9V5?.PT*?0T*#0HO+R\O+R\O M+R\O+R\O+R\O+R\O+R\O+R\O#0HO+R!I;7!L96UE;G1A=&EO;B!W:&%L90T* M#0IW:&%L93HZ=VAA;&4H*0T*>PT*?0T*#0IW:&%L93HZ=VAA;&4H(&-O;G-T M('-T9#HZ<W1R:6YG)B!N86UE+"!U;G-I9VYE9"!A9V4@*2 Z(&YA;65?*"!N M86UE("DL(&%G95\H(&%G92 I#0I[#0I]#0H@(" @#0IC;VYS="!S=&0Z.G-T M<FEN9R8(a)=VAA;&4Z.FYA;64H*2!C;VYS= T*>PT*(" @(')E='5R;B!N86UE M7SL-"GT-"B @(" -"G5N<VEG;F5D('=H86QE.CIA9V4H*2!C;VYS= T*>PT* M(" @(')E='5R;B!A9V5?.PT*?0T*(" @( T*=F]I9"!W:&%L93HZ9&]?<V5R M:6%L:7IE*"!B;V]S=#HZ87)C:&EV93HZ=&5X=%]O87)C:&EV928@87(L('5N M<VEG;F5D('9E<G-I;VX@*0T*>PT*(" @(&%R(#P\(&%G95\@/#P@;F%M95\[ M#0I]#0H-"G9O:60@=VAA;&4Z.F1O7W-E<FEA;&EZ92@@8F]O<W0Z.F%R8VAI M=F4Z.G1E>'1?:6%R8VAI=F4F(&%R+"!U;G-I9VYE9"!V97)S:6]N("D-"GL- A"B @("!A<B ^/B!A9V5?(#X^(&YA;65?.R -"GT-"@T* ` end

1 0

filesystem::change_extension doc error (1_31_0)
by Jeff Flinn 19 Apr '04

19 Apr '04

In http://www.boost.org/libs/filesystem/doc/convenience.htm#extension under the heading change_extension appears: path basename( const path & ph, const std::string & new_extension ); which should read: path change_extension( const path & ph, const std::string & new_extension ); Jeff F

2 1

Boost views library
by Vladimir Prus 19 Apr '04

19 Apr '04

Hi Roland, [I'm sending this message both to the list and to you personally in case you don't read the list regularly]. I'm wondering what's the status of your "views" library, which is now in Boost sandbox? I'm rather interested to use it and see in in Boost, and I have some questions: 1. Do you plan to work on it anytime soon and push it to review? 2. It (specifically filter_iterator) does not work for me (see the attached compile log). Is there any change you'll fix the problems? Will it be OK if I fix the problems? 3. I would have expected that there is some common 'view' class which provides definitions for typedefs and functions like 'empty' and that individual views only define methods which really differ, like begin/end. Was this design ever considered. 4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like: for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....); Is it possible add such functions? - Volodya

2 6

[Serialization] Formal Review
by Matthew Vogt 19 Apr '04

19 Apr '04

Formal review points: * What is your evaluation of the design? The design is rather complex - it certainly allows great flexibility, at the cost of ready comprehensibility. I realise that the complexity has accrued as a result of the library's extensive 'generalisation' phase; it would be nice to see a brief 'design and evolution' section in the documents. It's a little hard to comment on the design without having participated in the first review; I hope other reviewers can address this. * What is your evaluation of the implementation? The implementation seems quite clean, and well ordered. I think the comments in the code need a review pass, since they are occasionally out-of-sync with the code they comment upon. Also, it would be nice to see a bit more commentary on the purpose of the various classes that make up the implementation, which aren't covered by the documentation. The library includes part of the code as '.ipp' files, for inclusion into user '.cpp' files. This is not a common practise in boost libraries; perhaps it needs to be documented somewhere in the Boost:More Information section. * What is your evaluation of the documentation? The documentation is excellent. The layout is ideal, progressing through tutorial, reference and implementation sections. I think the documentation addresses extending the library with serialization of external types better than it addresses extending the library with new archives (although, this is probably a biased view :) ) I think the 'Advice' section is redundant; these points should be moved to the relevant reference section instead. * What is your evaluation of the potential usefulness of the library? I think the library is potentially of very wide applicability, due largely to its extensibility in the separate domains of types and archives. * Did you try to use the library? With what compiler? Yes, with GCC 3.2.2, without problems. * How much effort did you put into your evaluation? I read the documentation closely, investigated portions of the implementation, and tried to extend the library with types and archives. * Are you knowledgeable about the problem domain? Yes, and no; the library's applicability is broad, so few people will have extensive knowledge of the whole problem domain. I am more familiar with serialization for marshalling than for persistence, or for interoperability. * Do you think the library should be accepted as a Boost library? Yes. I can't think of any major issues that would force further re-design in the library, although new implementation detail issues are surely likely; I think it should be accepted now. Addressing Jeff's questions: 1) This is a large, complex, and important library. Please don't wait till the end of the review period to start your review -- there is no additional room in the review schedule to extend the review period. This is a brief review; please ask if you would like detail on any response. 2) I am particularly interested in hearing from parties that have tried to extend the library by adding serialization for a new type or by building a new type of archive. The ability to easily extend the library for new types and novel types of archives is critical for this library. As mentioned earlier, I think that the documentation covers the handling of types better than extension with archives. The section 'New Archives' needs to address the difference between overriding 'save' and 'save_override', and 'operator>>'. Also, discussion of the archive's preamble, and how to disable or modify it seems to be necessary. That said, the library seems not to limit anything an archive implementor may want to do. My only remaining concern is regarding controlling access to indiviual overloads of 'save' or 'load'. This seems to break down, due to the fact that all accesses are from the 'access' class. 3) If you reviewed the library during the first review, I would like your evaluation of whether the new version of the library addresses your original concerns. Also, if this is a re-review I would appreciate if you could send me a weblink from the mail archive to your original review posting(s). Not me. 4) Finally, I would like reviewers to indicate parts of the library that might become standalone boost libraries. While this will have little bearing on the acceptance / rejection of the library it might allow a reduction in the size of the library. Some sections of code are definitely candidates for extraction from the serialization library, largely identified by Robert in the 'Miscellaneous' section of the documentation. The strong typedef and state_saver utilities could be extracted, perhaps to the utility library. Perhaps the extended type info infrastructure is useful outside the library. The dataflow iterators are very interesting, but I'm not sure how they interact with the iterator adaptors library, or with sandbox views library. The unicode conversion code is certainly useful, but I imagine it might be better to leave it as an implementation detail of serialization, until someone volunteers to investigate a complete solution for this issue. The code dealing with XML formatting and escaping is in a similar situation. Thanks Robert, for your efforts Matt

1 0

VC8!!!
by firingme 19 Apr '04

19 Apr '04

Welcome to use Microsoft Visual C++ 8.0 tools. Setting environment for using Microsoft Visual C++ tools. E:\VC8>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.30703.05 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ]

6 5

Re: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 19 Apr '04

19 Apr '04

Matthew Vogt writes: > Actually, XDR and CDR are of secondary interest for me; For me too, but these have be much requested and finishing these off in a polished way will be significant contribution to the library for many users. > I'm interested in > being able to save to proprietary formats (which often means that the > applications involved never got around to specifying a standard > format...). There must be thousands of ad-hoc binary formats in use > today. Hmmm - I'm a little wary of this. Though I'm not sure I know what you mean. Some persons interested in the library have hoped it can be used to generate some specific format. But that format doesn't accommodated all the information required to rebuild and arbitrary C++ data structure so in order to do one ends up coupling the serialization of classes to the archive format - just exactly what the serialization library is designed to avoid. Actually, My current thinking is to add a section to the documentation ( I love my documentation ! Many people have contributed to it by careful reading and criticism) which suggests a transition path from a proprietary format to usage of the serialization library. This transition would be basically a) make a program which loads all your "old" data in the "old" way. b) serialize the structures. So I'm skeptical of trying to adjust to "old" proprietary formats with the serialization library. >> 1) I wonder why you derived ordered_oarchive from >> basic_binary_oprimitive<Archive, OStream> > I'm using the save_binary / load_binary functions from > basic_binary_oprimitive > and basic_binary_iprimitive. Maybe we'll consider factoring this out into a standalone function. We'll keep and eye on this for now. In fact, if the salient feature of XDR is Endian awarness, alignment etc. I'm wondering if some of the functionality of your classes shouldn't be moved into your own version of load_binary thereby making inheriting the native one unnecessary. > 2) there's some stuff in boost that addresses alignment in a guaranteed? > Portable manner that may relevant here. Sse #include > <boost/aligned_storage.hpp> . BTW - the best way to make your code portable > without cluttering up with #ifdef etc... is to use more boost stuff - let > other people clutter up their code with #ifdef all over the place. > Yes, but the aligned_storage template helps with platform-specific > alignment within the machine. I don't see how it helps with > platform-independent alignment within the content of the archive... OK - I would like to see that made a little more transparent and better explained with comments. It's an important part of the issues being addressed. > 3) I'm curious about the override for the saving of vector. ... > I need to override the serialization of vector, because the vector must be > serialized with a known policy to yield a required layout in the archive. > The fact that this serialization happens (at this point in time) to be > exactly the same as the default implementation is not relevant - that can > be changed at any time, but the CDR, XDR and other binary formats must > not change. I'm still not convinced - its seems to me that it shouldn't need to be overridden for XDR and CDR which is what these classes do. What about list, deque, set, etc. [ Points 4-6 conceded ] >> 7) I'm just a little queasy about using the term marshalling. In fact >> any of the archive implementations could be used for marshalling - not >> just a binary one (XML is the favorite flavor of the month). So I >> think it's sort of misleading. > Yes, I see what you're saying. I'll have a think about this - but the > term 'marshalling' is not particularly prevalent in the code. Even if > the term does have broad application, I think I am using it in the > traditional sense. Your library does marshalling ( as understand the term is usually used ). My complaint is that its too modest. Your library does more than that. When I started this library there was strong usage of the term "persistence" which lead to the misconception that the library had nothing to do with "marshalling". I see serialization as use in a number of things - persistence, marshalling and who knows what else? (e.g. generating a crc on the whole data state of the program to detected changes). That's why I went to much effort to avoid this characterization of the library. Your addition will gain strength from leveraging on this and by fitting in with the established pattern will be found easier to use. This will make it more successful. Also by following such a pattern it will almost entirely eliminate the need for special documentation. > 8) in my native binary archive, I used a template parameter for the stream > class. As it stands, I don't test or use the corresponding archive for wide > character streams because the WEOF would need special treatment. I haven't > spent any time on this. Perhaps you've addressed this in some way. > No, I was hoping you'd have it all sorted out - I've never used a stream > specialised with anything but char. In fact, it doesn't really make sense > to me, to produce binary output as anything but a byte stream - I was just > following your lead, really :) That's basically why I haven't spent any time on it. I made it templated on the stream class basically motivated by symmetry with the other archives. It should be finished by addressing the WEOF/EOF issue and using a code convert facet which turns the wchar_t interface into a byte stream. This way it would be useful to programs which are built around wchar_t rather than char. I suspect more programs in the future will do this. Its not very hard, but not of urgent interest. BTW - this might be better reason to derive from basic_binary_oprimitive. Robert Ramey

3 5

[Boost-bugs] [ boost-Bugs-937606 ] filesystem::directory_iterator returns incorrect listing
by SourceForge.net 19 Apr '04

19 Apr '04

Bugs item #937606, was opened at 2004-04-19 14:04 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=937606&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Roewen (s-a-t-a-n) Assigned to: Nobody/Anonymous (nobody) Summary: filesystem::directory_iterator returns incorrect listing Initial Comment: directory_iterator doesn't work correctly under debian linux (sarge/testing). Returns an invalid iterator value, which can cause a segmentation-fault, and drops the last item from the resulting listing. path dir = "my_dir"; if ( exists(dir) || !is_directory(dir) ) return; directory_iterator itr(dir), end; while ( itr != end ) { const path &p = *itr++; //-- do something with it } When I had a directory with only one file, no actual filenames were returned. When calling methods such as leaf() on const path &p, it would cause a seg-fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=937606&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 19 Apr '04

19 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Jueves, Abril 15, 2004 7:50 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal > How about just allowing any MPL sequence to specify the indices? mpl_index_list does precisely this. Check the MPL part in the advanced topics section of the docs. > > Also, it would be a nice syntactic convenience to allow the main > container template to accept a "variable" number of parameters, > and then > allow the indices to be specified as parameters directly to the main > container template. > Pardon? Do you mean something like multi_index_container < employee, ordered_unique<...>, unordered_unique<...> > without the index_list<> nesting? This cannot be done, as multi_index_container accepts an additional argument, the allocator class. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 7