Re: [boost] [Serialization] Formal Review
Matthew Vogt wrote: * What is your evaluation of the documentation? ...
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 :) )
True. I didn't anticipate this much interest in making new archive classes. Also making a new archive class is harder than specifying a new serialization so I spent less effort on explaining it.
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.
I would be curious to see a specific example of this. 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.
I would love to see separate discussion of this (on a separate thread please). This area overlaps with iteratator adaptors and views an maybe collection traits and who know what else. This is something I've always wanted and now I (almost) have it. My current implementation (not yet uploaded) is much improved but has the same interface and intention.
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.
I would love to see someone take this out. Ron Garcia wrote this and it worked to my satisfaction. I had problems making a good test and with portability to other compilers/libraries. Maybe Ron or someone else wants to move this to somewhere else. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes: Robert, please use proper quotation. I can't tell who's saying what here. Thanks, Dave
I would be curious to see a specific example of this.
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.
I would love to see separate discussion of this (on a separate thread please). This area overlaps with iteratator adaptors and views an maybe collection traits and who know what else. This is something I've always wanted and now I (almost) have it. My current implementation (not yet uploaded) is much improved but has the same interface and intention.
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.
I would love to see someone take this out. Ron Garcia wrote this and it worked to my satisfaction. I had problems making a good test and with portability to other compilers/libraries. Maybe Ron or someone else wants to move this to somewhere else.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Robert Ramey <ramey <at> rrsd.com> writes:
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.
I would be curious to see a specific example of this.
I have a case where I want to do this with the marshalling archives, but they are a bit heavy for discussion, so I'll try to come back to this with a simpler demonstration case. (For David: the following is repeating the earlier post,attributed by initials - that was my fault for not quoting Jeff properly) JG: 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. MV: 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. RR: I would love to see separate discussion of this (on a separate thread please). This area overlaps with iteratator adaptors and views an maybe collection traits and who know what else. This is something I've always wanted and now I (almost) have it. My current implementation (not yet uploaded) is much improved but has the same interface and intention. MV: 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. RR: I would love to see someone take this out. Ron Garcia wrote this and it worked to my satisfaction. I had problems making a good test and with portability to other compilers/libraries. Maybe Ron or someone else wants to move this to somewhere else.
participants (3)
-
David Abrahams -
Matthew Vogt -
Robert Ramey