Re: [boost] Re: Re: Re: [multi_index] announce: serialization support
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> Fecha: Jueves, Diciembre 2, 2004 0:36 am Asunto: [boost] Re: Re: Re: [multi_index] announce: serialization support
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:206712203b1d.203b1d206712@tid.es...
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> Fecha: Miércoles, Diciembre 1, 2004 10:15 pm Asunto: [boost] Re: Re: [multi_index] announce: serialization support [snip]
If you guarentee that the container itself is always serialized before your indices, then de-serialization of the indices would automatically be reduced to providing the original (tracked) pointer. In such a case, I would think the whole isse would never appear and that the implementation would be very straight forward.
I think this is not correct (but I'd like to be proven wrong, that'd mean I could simplify my code.) Consider this:
struct foo { std::list<std::string> cont; std::string* pos; // pos points to an element of cont
private: friend class boost::serialization::access;
template<class Archive> void serialize(Archive & ar, const unsigned int) { ar&cont; // before pos, as you suggest ar&pos; } };
My thesis is that loading a foo will get it wrong --pos won't be pointing to an element of cont, but rather to some random address in stack memory. I'll check it out on my compiler tomorrow, but I was already through this when designing multi_index serialization. See my point now? Am I missing something?
Hmmm - let me consider this. My view is based on the test test_list_ptrwhich serializes a list of pointers. In this case each list element is tracked because its a pointer. when a pointer is de-serialized a secondtime, tracking assures that the pointer is reloaded.
In your case - std::string is tracked on output. When it its serialized a second time, only the object ID is written out. So when it is read back in the second time, the serialization system recognizes that its a copy and just reloads it.
This only gotcha is that most primitive types are not tracked by default.and std::string has been assigned a serialization trait of "primitive" that means don't track. So I believe that this would work for non- primitivetypes.
Oh, I choose std::string cause I thought it was tracked by default, my point was meant to hold for trackable types. So, replace std::string wit the user-defined type of your choice and I still maintain that serialization of foo will go wrong. So that we don't keep discussing on thin air, please allow me to get back to you tomorrow with a complete, compiled example of what I mean. If in the meantime you do the check yourself please tell me what you come up with. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:2096fa209c83.209c832096fa@tid.es...
If in the meantime you do the check yourself please tell me what you come up with.
Attached please find an updated version of test_list_ptrs.cpp which illustrates my point. A couple of notes: a) elminate the BOOST_SERIALIZATION_IMPLEMENT - its part of the next version. b) free_a_ptr is setup to be a copy of the first element of the list of pointers. c) this verifies that memory tracking takes care of everything necessary. Note that this example doesn't address this issue of what happens if the collection consisted of primitives (or string) which are not tracked by default. That question is separate from the current issue. Robert Ramey begin 666 test_list_ptrs.cpp M+R\O+R\O+R\O,2\O+R\O+R\O+S(O+R\O+R\O+R\S+R\O+R\O+R\O-"\O+R\O M+R\O+S4O+R\O+R\O+R\V+R\O+R\O+R\O-R\O+R\O+R\O+S@-"B\O('1E<W1? M;&ES="YC<' -"@T*+R\@*$,I($-O<'ER:6=H=" R,# R(%)O8F5R="!286UE M>2 M(&AT=' Z+R]W=W<N<G)S9"YC;VT@+B -"B\O(%5S92P@;6]D:69I8V%T M:6]N(&%N9"!D:7-T<FEB=71I;VX@:7,@<W5B:F5C="!T;R!T:&4@0F]O<W0@ M4V]F='=A<F4-"B\O($QI8V5N<V4L(%9E<G-I;VX@,2XP+B H4V5E(&%C8V]M M<&%N>6EN9R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T#0HO+R!H M='1P.B\O=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0I#0H-"B\O('-H M;W5L9"!P87-S(&-O;7!I;&%T:6]N(&%N9"!E>&5C=71I;VX-"@T*(VEN8VQU M9&4@/&9S=')E86T^#0H-"B-I;F-L=61E(#QC<W1D:6\^("\O(')E;6]V90T* M(VEN8VQU9&4@/&)O;W-T+V-O;F9I9RYH<' ^#0HC:68@9&5F:6YE9"A"3T]3 M5%].3U]35$1#7TY!34534$%#12D-"FYA;65S<&%C92!S=&1[( T*(" @('5S M:6YG(#HZ<F5M;W9E.PT*?0T*(V5N9&EF#0H-"B-I;F-L=61E(#QB;V]S="]T M>7!E7W1R86ET<R]I<U]P;VEN=&5R+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S M=&%T:6-?87-S97)T+FAP<#X-"B-I;F-L=61E(#QB;V]S="]C:&5C:V5D7V1E M;&5T92YH<' ^#0H-"B-I;F-L=61E(#QB;V]S="]A<F-H:79E+V%R8VAI=F5? M97AC97!T:6]N+FAP<#X-"B-I;F-L=61E(")T97-T7W1O;VQS+FAP<"(-"@T* M(VEN8VQU9&4@/&)O;W-T+W-E<FEA;&EZ871I;VXO;&ES="YH<' ^#0HC:69D M968@0D]/4U1?2$%37U-,25-4#0HC:6YC;'5D92 \8F]O<W0O<V5R:6%L:7IA M=&EO;B]S;&ES="YH<' ^#0HC96YD:68-"B-I;F-L=61E(#QB;V]S="]S97)I M86QI>F%T:6]N+VYV<"YH<' ^#0H-"B-I;F-L=61E(")!+FAP<"(-"@T*+R\@ M:6YC;'5D92!D969A=6QT('-E<FEA;&EZ871I;VX@9&5F:6YI=&EO;G,-"D)/ M3U-47U-%4DE!3$E:051)3TY?24U03$5-14Y4#0H-"G1E;7!L871E/&-L87-S M(%0^#0IS=')U8W0@<'1R7V5Q=6%L7W1O(#H@<'5B;&EC('-T9#HZ8FEN87)Y M7V9U;F-T:6]N/%0L(%0L(&)O;VP^( T*>PT*(" @($)/3U-47U-4051)0U]! M4U-%4E0H.CIB;V]S=#HZ:7-?<&]I;G1E<CQ4/CHZ=F%L=64I.PT*(" @(&)O M;VP@;W!E<F%T;W(H*2A4(&-O;G-T(%],969T+"!4(&-O;G-T(%]2:6=H="D@ M8V]N<W0-"B @("![#0H@(" @(" @(&EF*$Y53$P@/3T@7TQE9G0@)B8@3E5, M3" ]/2!?4FEG:'0I#0H@(" @(" @(" @("!R971U<FX@=')U93L-"B @(" @ M(" @:68H='EP96ED*"I?3&5F="D@(3T@='EP96ED*"I?4FEG:'0I*0T*(" @ M(" @(" @(" @<F5T=7)N(&9A;'-E.PT*(" @(" @("!R971U<FX@*E],969T M(#T]("I?4FEG:'0[#0H@(" @?0T*?3L-"@T*:6YT('1E<W1?;6%I;B@@:6YT M("\J(&%R9V,@*B\L(&-H87(J("\J(&%R9W8@*B];72 I#0I[#0H@(" @8V]N M<W0@8VAA<B J('1E<W1F:6QE(#T@8F]O<W0Z.F%R8VAI=F4Z.G1M<&YA;2A. M54Q,*3L-"B @("!"3T]35%]215%525)%*$Y53$P@(3T@=&5S=&9I;&4I.PT* M#0H@(" @<W1D.CIL:7-T/$$@*CX@86QI<W0[#0H@(" @02 J(&9R965?85]P M='([#0H@(" @>R @( T*(" @(" @("!T97-T7V]S=')E86T@;W,H=&5S=&9I M;&4L(%1%4U1?4U1214%-7T9,04=3*3L-"B @(" @(" @=&5S=%]O87)C:&EV M92!O82AO<RD[#0H@(" @(" @(&9R965?85]P='(@/2!N97<@03L-"B @(" @ M(" @86QI<W0N<'5S:%]B86-K*&9R965?85]P='(I.PT*(" @(" @("!A;&ES M="YP=7-H7V)A8VLH;F5W($$I.PT*(" @(" @(" O+R!V97)I9GD@=&AA="!F M:7)S="!E;&5M96YT(&ES('1H92!S86UE(&%S('1H92!F<F5E('!O:6YT97(- M"B @(" @(" @0D]/4U1?0TA%0TLH*"IA;&ES="YB96=I;B@I*2 ]/2!F<F5E M7V%?<'1R*3L-"B @(" @(" @;V$@/#P@8F]O<W0Z.G-E<FEA;&EZ871I;VXZ M.FUA:V5?;G9P*")A;&ES="(L(&%L:7-T*3L-"B @(" @(" @;V$@/#P@8F]O M<W0Z.G-E<FEA;&EZ871I;VXZ.FUA:V5?;G9P*")F<F5E7V%?<'1R(BP@9G)E M95]A7W!T<BD[#0H@(" @?0T*(" @('-T9#HZ;&ES=#Q!("H^(&%L:7-T,3L- M"B @("!!("H@9G)E95]A7W!T<C$[#0H@(" @>PT*(" @(" @("!T97-T7VES M=')E86T@:7,H=&5S=&9I;&4L(%1%4U1?4U1214%-7T9,04=3*3L-"B @(" @ M(" @=&5S=%]I87)C:&EV92!I82AI<RD[#0H@(" @(" @(&EA(#X^(&)O;W-T M.CIS97)I86QI>F%T:6]N.CIM86ME7VYV<"@B86QI<W0B+"!A;&ES=#$I.PT* M(" @(" @("!I82 ^/B!B;V]S=#HZ<V5R:6%L:7IA=&EO;CHZ;6%K95]N=G H M(F9R965?85]P='(B+"!F<F5E7V%?<'1R,2D[#0H@(" @?0T*(" @($)/3U-4 M7T-(14-+* T*(" @(" @("!A;&ES="YS:7IE*"D@/3T@86QI<W0Q+G-I>F4H M*2 -"B @(" @(" @)B8@<W1D.CIE<75A;"AA;&ES="YB96=I;B@I+&%L:7-T M+F5N9"@I+&%L:7-T,2YB96=I;B@I+'!T<E]E<75A;%]T;SQ!("H^*"DI#0H@ M(" @*3L-"B @(" O+R!V97)I9GD@=&AA="!F:7)S="!E;&5M96YT(&ES('1H M92!S86UE(&%S('1H92!F<F5E('!O:6YT97(-"B @("!"3T]35%]#2$5#2R@H M*F%L:7-T,2YB96=I;B@I*2 ]/2!F<F5E7V%?<'1R,2D[#0H-"B @("!S=&0Z M.F9O<E]E86-H* T*(" @(" @("!A;&ES="YB96=I;B@I+" -"B @(" @(" @ M86QI<W0N96YD*"DL( T*(" @(" @("!B;V]S=#HZ8VAE8VME9%]D96QE=&5R M/$$^*"D-"B @(" I.PT*(" @('-T9#HZ9F]R7V5A8V@H#0H@(" @(" @(&%L M:7-T,2YB96=I;B@I+" -"B @(" @(" @86QI<W0Q+F5N9"@I+" -"B @(" @ M(" @8F]O<W0Z.F-H96-K961?9&5L971E<CQ!/B@I#0H@(" @*3L-"B @(" - M"B @(" C:69D968@0D]/4U1?2$%37U-,25-4#0H@(" @<W1D.CIL:7-T/$$@ M*CX@87-L:7-T.PT*(" @(&%S;&ES="YP=7-H7V)A8VLH;F5W($$I.PT*(" @ M(&%S;&ES="YP=7-H7V)A8VLH;F5W($$I.PT*(" @('L@(" -"B @(" @(" @ M=&5S=%]O<W1R96%M(&]S*'1E<W1F:6QE+"!415-47U-44D5!35]&3$%'4RD[ M#0H@(" @(" @('1E<W1?;V%R8VAI=F4@;V$H;W,I.PT*(" @(" @("!A<VQI M<W0N<'5S:%]B86-K*&YE=R!!*3L-"B @(" @(" @87-L:7-T+G!U<VA?8F%C M:RAN97<@02D[#0H@(" @(" @(&]A(#P\(&)O;W-T.CIS97)I86QI>F%T:6]N M.CIM86ME7VYV<"@B87-L:7-T(BP@87-L:7-T*3L-"B @("!]#0H@(" @<W1D M.CIL:7-T/$$@*CX@87-L:7-T,3M[#0H@(" @(" @('1E<W1?:7-T<F5A;2!I M<RAT97-T9FEL92P@5$535%]35%)%04U?1DQ!1U,I.PT*(" @(" @("!T97-T M7VEA<F-H:79E(&EA*&ES*3L-"B @(" @(" @:6$@/CX@8F]O<W0Z.G-E<FEA M;&EZ871I;VXZ.FUA:V5?;G9P*")A<VQI<W0B+"!A<VQI<W0Q*3L-"B @("!] M#0H@(" @0D]/4U1?0TA%0TLH87-L:7-T+G-I>F4H*2 ]/2!A<VQI<W0Q+G-I M>F4H*2 F)@T*(" @(" @("!S=&0Z.F5Q=6%L*&%S;&ES="YB96=I;B@I+&%S M;&ES="YE;F0H*2QA<VQI<W0Q+F)E9VEN*"DL<'1R7V5Q=6%L7W1O/$$@*CXH M*2D-"B @(" I.PT*(" @('-T9#HZ9F]R7V5A8V@H#0H@(" @(" @(&%S;&ES M="YB96=I;B@I+" -"B @(" @(" @87-L:7-T+F5N9"@I+" -"B @(" @(" @ M8F]O<W0Z.F-H96-K961?9&5L971E<CQ!/B@I#0H@(" @*3L-"B @("!S=&0Z M.F9O<E]E86-H* T*(" @(" @("!A<VQI<W0Q+F)E9VEN*"DL( T*(" @(" @ M("!A<VQI<W0Q+F5N9"@I+" -"B @(" @(" @8F]O<W0Z.F-H96-K961?9&5L M971E<CQ!/B@I#0H@(" @*3L@( T*(" @("-E;F1I9@T*(" @('-T9#HZ<F5M M;W9E*'1E<W1F:6QE*3L-"B @("!R971U<FX@8F]O<W0Z.F5X:71?<W5C8V5S 1<SL-"GT-"@T*+R\@14]�H` ` end
Hi Robert, Robert Ramey ha escrito:
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:2096fa209c83.209c832096fa@tid.es...
If in the meantime you do the check yourself please tell me what you come up with.
Attached please find an updated version of test_list_ptrs.cpp which illustrates my point. A couple of notes:
a) elminate the BOOST_SERIALIZATION_IMPLEMENT - its part of the next version. b) free_a_ptr is setup to be a copy of the first element of the list of pointers.
This does not reflect the situation I'm talking about. The problem shows when the pointer points to an element of the container. Here, free_a_ptr is merely a copy of the container element (i.e. both pointers point to an external object.) Please compile and run the attached sample. You'll agree with me that the expected output of the program is cont.begin(): 1 pos points to: 1 cont.begin(): 1 pos points to: 1 Yet, in my MSVC++ 6.0 compiler I get the following: cont.begin(): 1 pos points to: 1 cont.begin(): 1 pos points to: 1243388 illustrating that the pointer is not correctly deserialized.
Note that this example doesn't address this issue of what happens if the collection consisted of primitives (or string) which are not tracked by default. That question is separate from the current issue.
Yes, that's a different issue. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41AEC3AE.21D594CB@tid.es...
cont.begin(): 1 pos points to: 1 cont.begin(): 1 pos points to: 1243388
illustrating that the pointer is not correctly deserialized.
OK, I see it now. I tweaked your example a little but it still fails. In my view - it should work. The fact that it doesn't reflects an implementation issue with the serialization library with respect to its implemenatation for standard containers. Your original observation that the container de-serialization doesn't do inplace construction is the source of the difficulty. My interest would be to see this re-considered to see if its possible to use in-place construction - similar to the way its done for most other pointer like objects. Somehow it doesn't seem that this should be all that hard. However, I did consider it but didn't do it that way - I forget why. I suspect that the current system turned out to tbe easiest and I didn't seen anything wrong with it - until now. I'll look into this. Robert Ramey
Robert Ramey ha escrito:
"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41AEC3AE.21D594CB@tid.es...
cont.begin(): 1 pos points to: 1 cont.begin(): 1 pos points to: 1243388
illustrating that the pointer is not correctly deserialized.
OK, I see it now.
I tweaked your example a little but it still fails.
In my view - it should work. The fact that it doesn't reflects an implementation issue with the serialization library with respect to its implemenatation for standard containers.
Your original observation that the container de-serialization doesn't do inplace construction is the source of the difficulty. My interest would be to see this re-considered to see if its possible to use in-place construction - similar to the way its done for most other pointer like objects. Somehow it doesn't seem that this should be all that hard.
I'm pretty sure it is in fact impossible with the current functionality offered by Boost.Serialization. I'm saying this after thinking about the issue for a good couple of weeks while designing multi_index serialization. The problem could be solved for std::lists: // load en alement into the list l.push_back(element_type()); ar>>&li.back(); but this approach cannot be applied to associative containers like sets: one cannot just preinsert the element before loading the value, cause insertion *depends* on the value. It's a chicken and egg situation. IMHO this problem necessitates some facility to let the user fine-control tracking, in the spirit of the two features I proposed a few posts ago: * reposition a track address * make_external for allowing tracking to an object which is not serialized itself. I can elaborate on how this could solve the problem, if you'd like. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41AF68C7.B68D7CF4@tid.es...
Your original observation that the container de-serialization doesn't do inplace construction is the source of the difficulty. My interest would be to see this re-considered to see if its possible to use in-place construction - similar to the way its done for most other pointer like objects. Somehow it doesn't seem that this should be all that hard.
I'm pretty sure it is in fact impossible with the current functionality offered by Boost.Serialization. I'm saying this after thinking about the issue for a good couple of weeks while designing multi_index serialization. The problem could be solved for std::lists:
// load en alement into the list l.push_back(element_type()); ar>>&li.back();
I remember now, this created problems for types without default constructors.
but this approach cannot be applied to associative containers like sets: one cannot just preinsert the element before loading the value, cause insertion *depends* on the value. It's a chicken and egg situation.
IMHO this problem necessitates some facility to let the user fine-control tracking, in the spirit of the two features I proposed a few posts ago:
OK - I'm convinced. I'm not motivated to change anything yet, but I can see the problem.
* reposition a track address * make_external for allowing tracking to an object which is not serialized itself.
I can elaborate on how this could solve the problem, if you'd like. feel free. Robert Ramey
participants (3)
-
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Robert Ramey