I just looked over this library (since Robert Ramey mentioned part of it as a solution to a different problem). I'm wondering how (future) Boost library code should implement serialization. Right now, the Serialization library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code? If the latter is the answer, then does: class my_type { friend class ::boost::serialization::access; //... }; need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]? Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info". And I think some of the demo programs could use a sprinkling of "std::auto_ptr". [1] I know there's at least one wacky friend combination that'll interpret a template function as a non-template function instead if you don't take proper precautions. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
I just looked over this library (since Robert Ramey mentioned part of it as a solution to a different problem). I'm wondering how (future) Boost library code should implement serialization. Right now, the Serialization library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code?
Right now the code is in the library that is maintained by the persone who wrote. After doing the whole STL, I'm trying to stay away from the serialization code writing business. I've made some exceptions such as shared_ptr for reasons that aren't interesting here. In general the long term approach has to be that authors of individual libraries add serialization to their own libraries. This has worked out well for date-time, multi-index and perhaps others.
If the latter is the answer, then does:
class my_type { friend class ::boost::serialization::access; //... };
need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]?
If I understand this correctly, the friend declaration could be restricted to a couple of functions. But compilers are all over the place as to they way they handle this and the above is easy to remember and seems to work well. Of course, you're free to use a more elaborate one for your own classes.
Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info".
It the current version of the manual I see: Miscelenaeous extended_type_info Motivation Runtime Interface Requirements Models void_cast utf8_code_cvt BOOST_STRONG_TYPE state_saver Datafow Iterators smart_cast BOOST_STATIC_WARNING Rationale That is, void_cast is not show as part of extended_type_info. And I think some of the demo programs could
use a sprinkling of "std::auto_ptr".
LOL - and perhaps a little bit more. When the test system introduced automatic memory leak detection, I noticed for the first time that lots of the demos and tests had memory leaks. It doesn't affect the validity of the demos and tests but it does look a little sloppy. I'm reluctant to fix this as I'm concerned about complicating the demos and diminishing their tutorial value and about complicating the tests. Maybe someday. Robert Ramey
On Tue, Aug 23, 2005 at 08:44:15AM -0700, Robert Ramey wrote:
Daryle Walker wrote:
Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info".
It the current version of the manual I see:
Miscelenaeous extended_type_info Motivation Runtime Interface Requirements Models void_cast utf8_code_cvt BOOST_STRONG_TYPE state_saver Datafow Iterators smart_cast BOOST_STATIC_WARNING Rationale
That is, void_cast is not show as part of extended_type_info.
I am sorry, but with Konqueror 3.4.2 and Firefox 1.0.6 on a Linux machine void_cast through BOOST_STATIC_WARNING appear all one level *under* extended_type_info. I am going to attach screenshots which exhibit the problem. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
OK - I'll check it out. Robert Ramey Christoph Ludwig wrote:
On Tue, Aug 23, 2005 at 08:44:15AM -0700, Robert Ramey wrote:
Daryle Walker wrote:
Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info".
It the current version of the manual I see:
Miscelenaeous extended_type_info Motivation Runtime Interface Requirements Models void_cast utf8_code_cvt BOOST_STRONG_TYPE state_saver Datafow Iterators smart_cast BOOST_STATIC_WARNING Rationale
That is, void_cast is not show as part of extended_type_info.
I am sorry, but with Konqueror 3.4.2 and Firefox 1.0.6 on a Linux machine void_cast through BOOST_STATIC_WARNING appear all one level *under* extended_type_info. I am going to attach screenshots which exhibit the problem.
Regards
Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 8/23/05 11:44 AM, "Robert Ramey" <ramey@rrsd.com> wrote:
Daryle Walker wrote: [SNIP]
If the latter is the answer, then does:
class my_type { friend class ::boost::serialization::access; //... };
need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]?
If I understand this correctly, the friend declaration could be restricted to a couple of functions. But compilers are all over the place as to they way they handle this and the above is easy to remember and seems to work well. Of course, you're free to use a more elaborate one for your own classes. [TRUNCATE]
No, you misunderstood. I didn't mean to ask what I should be friendly to, but can I reference "access" without preamble. (I guess you meant that I could restrict friendliness to some member functions of "access".) Could I do: // This is the first line of the file class my_type { friend class ::boost::serialization::access; //... }; or do I need to do: // This is the first line of the file #include <boost/serialization_fwd.hpp> // I'm guessing the name class my_type { friend class ::boost::serialization::access; //... }; or: // This is the first line of the file #include <boost/serialization/access.hpp> // I'm guessing the name class my_type { friend class ::boost::serialization::access; //... }; ? It's actually more of a "rules of C++" question; the section on friends in the standard isn't too clear here. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
// This is the first line of the file
#include <boost/serialization/access.hpp> // I'm guessing the name
class my_type { friend class ::boost::serialization::access; //... };
This is what I intended to be used. It never occurred to me to use anything else. Not that that means anything in particular.
? It's actually more of a "rules of C++" question; the section on friends in the standard isn't too clear here.
I'll buy tthat Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes:
When the test system introduced automatic memory leak detection, I noticed for the first time that lots of the demos and tests had memory leaks. It doesn't affect the validity of the demos and tests but it does look a little sloppy. I'm reluctant to fix this as I'm concerned about complicating the demos and diminishing their tutorial value and about complicating the tests.
IMO that's unacceptable for Boost. A naive user who follows a Boost example like a recipe could introduce errors into his organization's codebase. Who do you think the deveopment team manager will blame when he finds out the error was present in our example? Do you think they'll continue to have confidence in the quality of the Boost libraries they're using? I don't. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
When the test system introduced automatic memory leak detection, I noticed for the first time that lots of the demos and tests had memory leaks. It doesn't affect the validity of the demos and tests but it does look a little sloppy. I'm reluctant to fix this as I'm concerned about complicating the demos and diminishing their tutorial value and about complicating the tests.
IMO that's unacceptable for Boost. A naive user who follows a Boost example like a recipe could introduce errors into his organization's codebase. Who do you think the deveopment team manager will blame when he finds out the error was present in our example? Do you think they'll continue to have confidence in the quality of the Boost libraries they're using? I don't.
I'd like to register another strong agreement with this opinion. Additionally, if making the example clean and safe really does complicate the code, then there are serious problems with the smart pointers (and/or other features) used to make it clean. jon
library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code?
If the latter is the answer, then does:
class my_type { friend class ::boost::serialization::access; //... };
I just ran into this again when I needed to serialize a boost::dynamic_bitset and with porting our codebase over to use 1.33 bringing across the modification I made to boost::filesystem::path for serialization. If there is a chance that these will get incorporated into cvs I will go to the effort of writing and configuring test cases for them and submit them (I did submit sode and tests a long time ago for filesystem::path but unfortuantly they never made it in so I'm reluctant to do more unless there is willing by the library authors to have them). It seems there should be a concerted effort to get all of boost being able to serialise out of the box as it leaves the library as a whole feeling somewhat disjointed. I may have some free time in the near future so I could be persuaded to go through implementing / incorpating existing patches for serialisation for other boost libraries. cheers Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.15/80 - Release Date: 23/08/2005
This raises the question of what to do in the following circumstances. a) person X requires serialization for library Y b) It doesn't currently exist and the current library maintainer has not made it. b) so he writes it and likes it. c) he wants to submit it to boost Questions that arise: a) His addition will included a header - where should it go. i) My current preference is boost/Y/serialization.hpp ii) On the otherhand, the ones I personally did - shared_ptr and some others have been put into boost/serialization/Y.hpp. This also applies to the STL serialization - since there is not boost/stll/... in any case. b) He should include tests. But where should he put them? The current situation mirror that of the above. The current method of making the library maintainer responsable for making tests pass wouldn't attribute the responsablity to the appropriate party c) Is any documentation necessary? - where should it go? d) Should such a contribution be subject to some sort of review. This last is interesting to me. In the past I received an implementation of serialization for boost::variant. This is something I always wanted so I included it. Then tests showed that the implementation wouldn't work for borland, msvc 6.x and maybe others. The there was the "requirement, that the implementation depend only on the public interface. The maintainer of boost::variant didn't participate. The final implementation wasn't quite as efficient as I would have liked but I didn't want to start a drum beat to tweak boost::variant. Adjusting the implementation to be as widely applicable as other serialization implementation - ie older compilers - turned out to be more time than I anticipated. So I would like to see some "fixed points" be enforced - that is, that it meets the requirements that other serialization implementations in the library maintain. Basically serialization for a library Y sort of lies in the intersection of the serialization library and library Y. Robert Ramey Martin Slater wrote:
library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code?
If the latter is the answer, then does:
class my_type { friend class ::boost::serialization::access; //... };
I just ran into this again when I needed to serialize a boost::dynamic_bitset and with porting our codebase over to use 1.33 bringing across the modification I made to boost::filesystem::path for serialization. If there is a chance that these will get incorporated into cvs I will go to the effort of writing and configuring test cases for them and submit them (I did submit sode and tests a long time ago for filesystem::path but unfortuantly they never made it in so I'm reluctant to do more unless there is willing by the library authors to have them). It seems there should be a concerted effort to get all of boost being able to serialise out of the box as it leaves the library as a whole feeling somewhat disjointed. I may have some free time in the near future so I could be persuaded to go through implementing / incorpating existing patches for serialisation for other boost libraries.
cheers
Martin
i) My current preference is boost/Y/serialization.hpp ii) On the otherhand, the ones I personally did - shared_ptr and some others have been put into boost/serialization/Y.hpp. This also applies to the STL serialization - since there is not boost/stll/... in any case. b) He should include tests. But where should he put them? The current situation mirror that of the above. The current method of making the library maintainer responsable for making tests pass wouldn't attribute the responsablity to the appropriate party
This is only applicable where serialization can be implemented efficently from the public interface. With boost::dynamic_bitset in particular it's much more efficient to implement internally otherwise you need to iterate over the elements into a temporary structure , serialize it then reverse on load, whereas internally it is just a vector + used count. In these cases then it must(?) be the library maintainer thats responsible for acceptance. Anything else should probably be reviewed and accepted / rejected by you as that is where the complaints will be undoubtbly directed in case of problems;)
c) Is any documentation necessary? - where should it go?
My vote would be with the applicable library. cheers Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.17/84 - Release Date: 29/08/2005
On Tue, 30 Aug 2005 19:40:29 +1000, Martin Slater wrote
i) My current preference is boost/Y/serialization.hpp ii) On the otherhand, the ones I personally did - shared_ptr and some others have been put into boost/serialization/Y.hpp. This also applies to the STL serialization - since there is not boost/stll/... in any case. b) He should include tests. But where should he put them? The current situation mirror that of the above. The current method of making the library maintainer responsable for making tests pass wouldn't attribute the responsablity to the appropriate party
This is only applicable where serialization can be implemented efficently from the public interface. With boost::dynamic_bitset in particular it's much more efficient to implement internally otherwise you need to iterate over the elements into a temporary structure , serialize it then reverse on load, whereas internally it is just a vector + used count. In these cases then it must(?) be the library maintainer thats responsible for acceptance. Anything else should probably be reviewed and accepted / rejected by you as that is where the complaints will be undoubtbly directed in case of problems;)
My suggestion, at the end of the review, was that serialization code for other boost types should go in the library that provides the type and not in serialization itself. This means that serialization can be extracted from Boost without dragging in dependencies on date-time, multi-index, etc, etc. That is, serialization doesn't wind up with links to all the rest of boost. Instead it is the other way around. And users can easily avoid the serialization dependency by not including serialization headers for the specific library...
c) Is any documentation necessary? - where should it go?
My vote would be with the applicable library.
Also what we decided before. For example: http://www.boost.org/doc/html/date_time/serialization.html Jeff
participants (7)
-
Christoph Ludwig -
Daryle Walker -
David Abrahams -
Jeff Garland -
Jonathan Wakely -
Martin Slater -
Robert Ramey