Re: [boost] [serialization] No Reply?
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> Fecha: Martes, Septiembre 13, 2005 6:10 pm Asunto: Re: [boost] [serialization] No Reply?
This is quite interesting to me. Its going to take a little time to consider with the attention it deserves.
Robert Ramey
JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Lunes, Septiembre 12, 2005 11:06 pm Asunto: Re: [boost] [serialization] No Reply?
* You should find some way to describe what it means for an input and an output archive to be compatible. Try to do that as formally as possible. You may have to rely on the fuzzy C++ notion of "equivalence," but I wouldn't blame you for that.
IMHO, there's no need to go fuzzy or rely on an undefined notion of "equivalence" between a serialized object and its restored copy. One can define these concepts with much precision in an "operational semantics" way, much as, for instance, semantics of logic languages is formally defined:
* A type T is serializable if the expressions oar<<ct; iar>>t; are valid, where ct is of type const T& and t is of type T&, oar is an output archive and iar is an input archive.
The above doesn't seem right to me. I don't see its necessary here an it makes the concept of serializable and archive circular. I believe that the inductive definition below - and currently in the document (more or less) defines the concept of serializable well enough.
Hmm... yep, rethinking it, this is superfluous (yet not circular AFAICS): the validity of these expressions is guaranteed by the archive concept as you explain in your docs. Serializability has to be defined in terms of the presence of the serialize function/memfun, as you're doing now. I think there's some weak points in my proposal having to do with the relationship between "archive association" and "restored copy" --for instance, a dummy archive wih accepts iar>>t for every t and simply does nothing would be, according to the definitions, associated with any output archive, and this is clearly not what we want. I've got this thing going round my head, allow me to come back to you in a few days. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
JOAQUIN LOPEZ MU?Z wrote:
I think there's some weak points in my proposal having to do with the relationship between "archive association" and "restored copy" --for instance, a dummy archive wih accepts iar>>t for every t and simply does nothing would be, according to the definitions, associated with any output archive, and this is clearly not what we want. I've got this thing going round my head, allow me to come back to you in a few days.
There are a couple of things that I would think should be permitted by the definition which might not be apparent. An archive which would be used for logging. I toyed with this but it turned out not to be trivial as I had anticipated. Basically I enviaged an archive that would would not do any tracking regardless of any serialization traits. This would be usable for things like transaction commit/rollback. Its still speculative but I don't see that the Archive Concept as envisioned prohibits it. Also for debug logging perhaps. Finally an application for write only memory !!!. Since Archive is dependent upon Serializable, I'm wondering if the sequence of these two sections in the documentation shouldn't be switched. Hmmmm. Anyway, thanks for looking into this. Take your time. I'm still thinking about two-phase lookup Robert Ramey
participants (2)
-
JOAQUIN LOPEZ MU?Z -
Robert Ramey