[fileststem]1.32: with serilization: visibility of m_path
Hi In order to serialize a derivative class of boost/filesystem/path, one cannot access the base class member m_path without changing its visibility from private to protected: I would suggest to change the visibility of this m_path member from private: to protected, or to add an implicit definition of the serialize method into the class boost::filesystem::path. #include <boost/filesystem/path.hpp> namespace boost { namespace serialization { class access; }} class OSD : public boost::filesystem::path { private: friend class boost::serialization::access; friend std::ostream & operator<<(std::ostream &os, const OSD&); template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & m_path; } }; Regards Francis ANDRE
At 04:13 AM 11/8/2004, Francis ANDRE wrote:
Hi
In order to serialize a derivative class of boost/filesystem/path, one cannot access the base class member m_path without changing its visibility from private to protected:
I would suggest to change the visibility of this m_path member from private: to protected, or to add an implicit definition of the serialize method into the class boost::filesystem::path.
#include <boost/filesystem/path.hpp> namespace boost { namespace serialization { class access; }}
class OSD : public boost::filesystem::path { private: friend class boost::serialization::access; friend std::ostream & operator<<(std::ostream &os, const OSD&); template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & m_path; } };
I don't particularly like either of those solutions. * Changing m_path from private to protected effectively adds m_path to the class interface, yet m_path is an implementation artifact that might not be present at all in a different implementation. * Adding a dependency to the serialization library isn't a good idea either. No matter how nice boost.serialization is, some boost.filesystem users will not wish to use it, and will not want the dependency. Class path already has a member, path::string(), which in the current implementation returns a reference to m_path, and in any implementation must return the equivalent of a const reference to m_path. Going the other way, the append function can be used to import a serialized string. I'm not familiar with how boost.serialization works, but wouldn't you be better off to use those already public functions for serialization? If not, I'm willing to make m_path protected, but would like to explore other approaches to the serialization problem first. Thanks, --Beman
On Mon, 08 Nov 2004 11:07:16 -0500, Beman Dawes wrote
* Adding a dependency to the serialization library isn't a good idea either. No matter how nice boost.serialization is, some boost.filesystem users will not wish to use it, and will not want the dependency.
Since the needed code for serialization is basically a template function the dependency can be limited to those using serialization by having a new header for serialization code. So in date-time we have something like: #include <boost/date_time/posix_time/time_serialize.hpp> Filesystem could do something similar.
Class path already has a member, path::string(), which in the current implementation returns a reference to m_path, and in any implementation must return the equivalent of a const reference to m_path. Going the other way, the append function can be used to import a serialized string. I'm not familiar with how boost.serialization works, but wouldn't you be better off to use those already public functions for serialization?
If not, I'm willing to make m_path protected, but would like to explore other approaches to the serialization problem first.
I think you could easily write your serialization functions to just use the string() interface. Jeff
On Mon, 08 Nov 2004 11:07:16 -0500, Beman Dawes wrote
* Adding a dependency to the serialization library isn't a good idea either. No matter how nice boost.serialization is, some boost.filesystem users will not wish to use it, and will not want the dependency.
Since the needed code for serialization is basically a template function
dependency can be limited to those using serialization by having a new
for serialization code. So in date-time we have something like:
#include <boost/date_time/posix_time/time_serialize.hpp>
Filesystem could do something similar.
Class path already has a member, path::string(), which in the current implementation returns a reference to m_path, and in any implementation must return the equivalent of a const reference to m_path. Going the other way, the append function can be used to import a serialized string. I'm not familiar with how boost.serialization works, but wouldn't you be better off to use those already public functions for serialization?
If not, I'm willing to make m_path protected, but would like to explore other approaches to the serialization problem first.
I think you could easily write your serialization functions to just use
Note that making one's code "serialization friendly" does not require inclusion of a header from the serialization library. In most cases it should be sufficient to include namespace boost { namespace serialization { class access; } } and friend class boost::serialization::access; in each class definition. I don't think that's a huge burden. Every week I get an email - how about adding serialization to this or that class. It would be better if sometime in the future we could agree on some sort of policy or practice to include this whereever appropriate. So far it hasn't been a big thing - but I'm thinking that when 1.32 gets released this may start to become a bigger issue. Robert Ramey "Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:20041108171108.M66733@crystalclearsoftware.com... the header the
string() interface.
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Robert Ramey" wrote:
Every week I get an email - how about adding serialization to this or that class. ... So far it hasn't been a big thing - but I'm thinking that when 1.32 gets released this may start to become a bigger issue.
Link to FAQ before each email link in docs? /Pavel
At 12:48 PM 11/8/2004, Robert Ramey wrote:
Note that making one's code "serialization friendly" does not require inclusion of a header from the serialization library.
In most cases it should be sufficient to include namespace boost { namespace serialization { class access; } } and
friend class boost::serialization::access;
in each class definition.
I don't think that's a huge burden.
No, that doesn't seem like a huge burden. Let me see if I understand the issues correctly: * As it stands now, boost::filesystem::path can be serialized by derivation, as Francis Andre suggested. Easy to do, but a bit messy to my taste. * But by adding the two lines of code above, boost::filesystem::path becomes serialization friendly without further ado. And granting friendship does not create a dependency on the serialization library, so the cost is strictly limited. Unless someone indicates I'm misunderstanding something, I'll go ahead and add the two lines of code, but I think it is too late for 1.32.0. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20041108152707.0221cec0@mailhost.esva.net...
At 12:48 PM 11/8/2004, Robert Ramey wrote:
Note that making one's code "serialization friendly" does not require inclusion of a header from the serialization library.
In most cases it should be sufficient to include namespace boost { namespace serialization { class access; } } and
friend class boost::serialization::access;
in each class definition.
I don't think that's a huge burden.
No, that doesn't seem like a huge burden.
Let me see if I understand the issues correctly:
* As it stands now, boost::filesystem::path can be serialized by derivation, as Francis Andre suggested. Easy to do, but a bit messy to my taste.
Personally I have no problem with this solution. It never occurred to me that I could get around the "private" in this way. I'm not convinced that all compilers would support it. The beauty of this is that it wouldn't require that other library authors be convinced to change their code.
* But by adding the two lines of code above, boost::filesystem::path becomes serialization friendly without further ado. And granting friendship does not create a dependency on the serialization library, so the cost is strictly limited.
Unless someone indicates I'm misunderstanding something, I'll go ahead and add the two lines of code, but I think it is too late for 1.32.0.
I think 1.32.0 should be released without any further changes or delay of any sort. Rather than adding any code anywhere - I would prefer to see this considered at a more leisurely pace. I would like to see some consensus reached after a number of people have looked at the various alternatives.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 05:01 PM 11/8/2004, Robert Ramey wrote:
... I think 1.32.0 should be released without any further changes or delay of any sort.
Rather than adding any code anywhere - I would prefer to see this considered at a more leisurely pace. I would like to see some consensus reached after a number of people have looked at the various alternatives.
Makes sense. As someone else suggested, we really ought to have a Boost-wide set of recommendations first. --Beman
Beman Dawes wrote:
At 05:01 PM 11/8/2004, Robert Ramey wrote:
... I think 1.32.0 should be released without any further changes or delay of any sort.
Rather than adding any code anywhere - I would prefer to see this considered at a more leisurely pace. I would like to see some consensus reached after a number of people have looked at the various alternatives.
Makes sense. As someone else suggested, we really ought to have a Boost-wide set of recommendations first.
To tackle the question of serialization, one first needs to decide whether the library is an interface description and a proof of concept implementation, or an "ordinary" library that will never have alternate implementations. In short, std:: or just boost::. An "std::" library (tuple, shared_ptr, filesystem?) needs to specify its external representation as part of the interface. This is mandated by the fact that users will - very likely - serialize its classes under implementation A and deserialize them under implementation B. This must work. A "just boost::" library may have an opaque external representation that is an implementation detail. What this all boils down to: - for an "std::" library, it probably should be possible to write a non-intrusive serializer; - a "just boost::" library can just dump its private members directly to the archive. Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr. And getting back to our filesystem example, if the interface states that the external representation of a fs::path is the std::string returned by string(), then the library should provide support for just that, but in the meantime, it should be possible for the end user to non-intrusively serialize a fs::path by defining an appropriate serialize(Archive&, fs::path&, unsigned long) overload.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@pdimov2...
Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr.
And getting back to our filesystem example, if the interface states that
external representation of a fs::path is the std::string returned by string(), then the library should provide support for just that, but in
In general, serialization for any class is specific to that class implementation. I don't think makes sense to require that a serializtion implementation be independent of the particular class implementtion. To do so will often result in a less than optimal implementation. the the
meantime, it should be possible for the end user to non-intrusively serialize a fs::path by defining an appropriate serialize(Archive&, fs::path&, unsigned long) overload.
By requiring that fs::path expose enough of its state to be serializable. This can be done either with an appropriate friend declaration or by making somethings public. Robert Ramey
At 08:09 PM 11/8/2004, Robert Ramey wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@pdimov2...
Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr.
In general, serialization for any class is specific to that class implementation. I don't think makes sense to require that a serializtion implementation be independent
the particular class implementtion. To do so will often result in a less than optimal implementation.
And getting back to our filesystem example, if the interface states
of that
external representation of a fs::path is the std::string returned by string(), then the library should provide support for just that, but in
the the
meantime, it should be possible for the end user to non-intrusively serialize a fs::path by defining an appropriate serialize(Archive&, fs::path&, unsigned long) overload.
By requiring that fs::path expose enough of its state to be serializable. This can be done either with an appropriate friend declaration or by making somethings public.
The key point is that fs::path makes its state public not by having public data members, but by having a public member function (string()) which returns enough information to reconstruct the actual internal state. There are at least two possible useful internal implementations of fs::path that I can think of. One is the current implementation, which holds internal state in a std::string. The other implementation would be to hold state as a std::vector of std::strings, where each string is one path element. This implementation would actually speed the decomposition functions and iteration over the elements. It might be particularly appropriate on an operating system like VMS where the O/S's path syntax is quite different from the portable syntax. Again in the case where the O/S's native path syntax is quite different from the portable syntax, an implementation might also choose to keep an additional internal string which contained the path in the native format. But regardless of which internal implementation is used, the path can always be completely represented by the string returned by fs::path::string(), and so that allows serialization to be completely independent of the internal implementation. The path can always be reconstructed by a constructor given the string. So the use case Peter mentioned where path implementation A is serialized out to disk, and then reloaded later into path implementation B should always work. --Beman
Robert Ramey wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@pdimov2...
Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr.
In general, serialization for any class is specific to that class implementation.
No, this is not true in general. It depends on whether (a) you want the external representation of the class to represent its logical state, and (b) whether it is possible for the user to obtain this logical state and reconstruct a new object based on it. To take a classic example, if you have a class point2 that exposes x() and y(), it can be serialized in a (x y) format, regardless of its physical representation that can be (r phi), for instance. I'd say that many of the general library classes fall in this category.
I don't think makes sense to require that a serializtion implementation be independent of the particular class implementtion.
It doesn't make sense if you have control over the class in question. However would you consider a scenario where a std::vector<int> written out by a program compiled with STL A cannot be read by a program compiled with STL B? A recompiled version of the same program with the newer version of the compiler? Now replace std::vector<int> with std::tr1::shared_ptr<X>. BTW there's one more problem with trying to serialize shared_ptr using the physical state; weak_ptr deserialization cannot work reliably. That's because it is possible to write the weak_ptr before the corresponding shared_ptr. Then no matter what you do on reading, either the object will be immediately destroyed after being created (there are no shared_ptrs to it, only a weak_ptr), or it will leak. Correct deserialization of shared_ptr/weak_ptr requires keeping a container of shared_ptr<void> that holds the objects alive during the deserialization process. The problem I've not been able to solve so far is where to keep it without making shared_ptr special WRT the archives. :-)
Peter Dimov wrote:
Correct deserialization of shared_ptr/weak_ptr requires keeping a container of shared_ptr<void> that holds the objects alive during the deserialization process.
Indeed.
The problem I've not been able to solve so far is where to keep it without making shared_ptr special WRT the archives. :-)
At work, we're using a modified version of boost::serialization where we've added a shared_ptr registry (the container to keep the pointed- to objects alive) as a kind of user data to the archives. So this could be a way, which would, however, require users to explicitly associate the shared_ptr registry with archives that have to deserialize shared_ptrs/weak_ptrs. We haven't found this to be much of a problem, though. In general, I propose adding some sort of user data mechanism to archives. Our system is quite complex and we use boost::serialization exclusively to serialize all the classes. Sometimes it is necessary to store certain state during serialization/deserialization that is associated with archives and that can be accessed from within serialization code. This is especially true for objects that depend on each other and have more complex relationships, such as shared_ptr and weak_ptr. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at
martin.ecker@tab.at wrote:
Peter Dimov wrote:
The problem I've not been able to solve so far is where to keep it without making shared_ptr special WRT the archives. :-)
At work, we're using a modified version of boost::serialization where we've added a shared_ptr registry (the container to keep the pointed- to objects alive) as a kind of user data to the archives. So this could be a way, which would, however, require users to explicitly associate the shared_ptr registry with archives that have to deserialize shared_ptrs/weak_ptrs. We haven't found this to be much of a problem, though.
I'm using something similar (not with boost::serialization, though). But this requires that all archives know about the special case of shared_ptr.
In general, I propose adding some sort of user data mechanism to archives.
What do you suggest along those lines?
Peter Dimov wrote:
In general, I propose adding some sort of user data mechanism to archives.
What do you suggest along those lines?
We have found it necessary to associate user data with archives in certain circumstances. In our case, I have simply added a boost::any as member data to every archive (by introducing a base class for all archives, since currently input and output archives do not have a common base class). Some classes in our system require that this boost::any contain specific state objects that are then accessed in serialization code. One example is the shared_ptr registry we're using, but we also have other objects that we store as user data in archives. For example, one part of our system uses a 3rd party library that has its own serialization system. In order to integrate it with our system that uses boost::serialization, we have to associate user data with a boost::serialization archive that contains a serialization stream of the 3rd party library. Now, if during the deserialization of our objects we encounter a pointer to a 3rd party library object, we trigger the 3rd party library's serialization system directly from our serialization code. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at
martin.ecker@tab.at wrote:
Peter Dimov wrote:
In general, I propose adding some sort of user data mechanism to archives.
What do you suggest along those lines?
We have found it necessary to associate user data with archives in certain circumstances. In our case, I have simply added a boost::any as member data to every archive (by introducing a base class for all archives, since currently input and output archives do not have a common base class).
This isn't good enough for me... sorry. I don't want to force archives to inherit from a common base class, and a single boost::any doesn't seem enough. What if you need to serialize two classes, each requiring a registry?
At 06:39 PM 11/8/2004, Peter Dimov wrote:
Beman Dawes wrote:
At 05:01 PM 11/8/2004, Robert Ramey wrote:
... I think 1.32.0 should be released without any further changes or delay of any sort.
Rather than adding any code anywhere - I would prefer to see this considered at a more leisurely pace. I would like to see some consensus reached after a number of people have looked at the various alternatives.
Makes sense. As someone else suggested, we really ought to have a Boost-wide set of recommendations first.
To tackle the question of serialization, one first needs to decide whether the library is an interface description and a proof of concept implementation, or an "ordinary" library that will never have alternate implementations. In short, std:: or just boost::.
An "std::" library (tuple, shared_ptr, filesystem?) needs to specify its external representation as part of the interface. This is mandated by the
fact that users will - very likely - serialize its classes under implementation A and deserialize them under implementation B. This must work.
A "just boost::" library may have an opaque external representation that is an implementation detail.
What this all boils down to:
- for an "std::" library, it probably should be possible to write a non-intrusive serializer;
- a "just boost::" library can just dump its private members directly to the archive.
Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr.
And getting back to our filesystem example, if the interface states
That all makes a great deal of sense to me. that >the external representation of a fs::path is the std::string returned by
string(), then the library should provide support for just that...
The docs don't currently say that explicitly, but it is certainly true. In the internationalized version I'm working on now, there will also be some path traits data that is part of the internal state, and that will be exposed by an appropriate get function. The ability to serialize based on either the actual internal physical representation (for "just boost" libraries) or on a logical representation provided by member functions (for "std" libraries) is really cool, IMO. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20041108214926.02e42130@mailhost.esva.net...
The ability to serialize based on either the actual internal physical representation (for "just boost" libraries) or on a logical representation provided by member functions (for "std" libraries) is really cool, IMO.
perhaps, but I don't know that one can know that it will always be possible Robert Ramey
At 11:30 PM 11/8/2004, Robert Ramey wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20041108214926.02e42130@mailhost.esva.net...
The ability to serialize based on either the actual internal physical representation (for "just boost" libraries) or on a logical representation provided by member functions (for "std" libraries) is really cool, IMO.
perhaps, but I don't know that one can know that it will always be
possible I guess it wouldn't be possible if there were important state information that is not directory exposed or reconstructible. But I'm not sure how common that is. Not very common in "std" libraries, I would guess. --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20041109120357.0258a188@mailhost.esva.net...
At 11:30 PM 11/8/2004, Robert Ramey wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:6.0.3.0.2.20041108214926.02e42130@mailhost.esva.net...
The ability to serialize based on either the actual internal physical representation (for "just boost" libraries) or on a logical representation provided by member functions (for "std" libraries) is really cool,
perhaps, but I don't know that one can know that it will always be
IMO. possible
I guess it wouldn't be possible if there were important state information that is not directory exposed or reconstructible. But I'm not sure how common that is. Not very common in "std" libraries, I would guess.
It turned out I was able to implement serialization for all the stl containers depending upon only the public interface. This is similar to your case. The funny part is that it never occurred to me that this was key to portability. I wasn't able to do this with shared_ptr and its becoming apparent that its not going to be obvious on how to do it. Robert Ramey
Robert Ramey wrote:
I wasn't able to do this with shared_ptr and its becoming apparent that its not going to be obvious on how to do it.
Serializing a shared_ptr is both trivial and very difficult. Reminds me of the difference between a magazine article and a real production-level implementation. But it doesn't need any access to the physical representation, at least conceptually. I don't have much time in the moment, so I'll just offer the example below. More, including deserialization, later. #include <boost/shared_ptr.hpp> #include <boost/weak_ptr.hpp> #include <iostream> #include <vector> #include <map> #include <string> std::map< boost::shared_ptr<void>, int > wpmap; void write( std::ostream & os, int const & v ) { os << v << ' '; } void write( std::ostream & os, std::string const & v ) { os << v << ' '; } template<class T> void write( std::ostream & os, boost::shared_ptr<T> const & pt ) { if( pt ) { int pid = wpmap[ pt ]; if( pid != 0 ) { write( os, pid ); } else { pid = wpmap.size(); wpmap[ pt ] = pid; write( os, pid ); write( os, *pt ); } } else { write( os, 0 ); } } template<class T> void write( std::ostream & os, boost::weak_ptr<T> const & pt ) { write( os, pt.lock() ); } template<class T> void write( std::ostream & os, std::vector<T> const & v ) { write( os, (int)v.size() ); for( size_t i = 0; i < v.size(); ++i ) { write( os, v[i] ); } } int main() { std::vector< boost::shared_ptr<std::string> > v1; std::vector< boost::weak_ptr<std::string> > v2; v1.push_back( boost::shared_ptr<std::string>(new std::string("S1")) ); v1.push_back( v1[0] ); v1.push_back( boost::shared_ptr<std::string>(new std::string("S2")) ); v1.push_back( v1[0] ); v1.push_back( boost::shared_ptr<std::string>(new std::string("S3")) ); v1.push_back( v1[0] ); v1.push_back( v1[2] ); v2.push_back( v1[0] ); v2.push_back( v1[0] ); v2.push_back( v1[2] ); write( std::cout, v2 ); write( std::cout, v1 ); }
"Peter Dimov" <pdimov@mmltd.net> writes:
std::map< boost::shared_ptr<void>, int > wpmap;
void write( std::ostream & os, int const & v ) { os << v << ' '; }
void write( std::ostream & os, std::string const & v ) { os << v << ' '; }
template<class T> void write( std::ostream & os, boost::shared_ptr<T> const & pt ) { if( pt ) { int pid = wpmap[ pt ];
if( pid != 0 ) { write( os, pid ); } else { pid = wpmap.size();
I could be wrong, but don't you need to add 1 here? wpmap starts out empty, after all.
wpmap[ pt ] = pid; write( os, pid ); write( os, *pt ); } } else { write( os, 0 ); } }
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
template<class T> void write( std::ostream & os, boost::shared_ptr<T> const & pt ) { if( pt ) { int pid = wpmap[ pt ];
if( pid != 0 ) { write( os, pid ); } else { pid = wpmap.size();
I could be wrong, but don't you need to add 1 here? wpmap starts out empty, after all.
It's a complete and working program, just run it. ;-) wpmap[pt] has already added the element. map::find-based code needs +1.
I've had a little more opportunity to digest this post and now appreciate it more. Some comments below. "Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@pdimov2...
An "std::" library (tuple, shared_ptr, filesystem?) needs to specify its external representation as part of the interface. This is mandated by the fact that users will - very likely - serialize its classes under implementation A and deserialize them under implementation B. This must work.
A "just boost::" library may have an opaque external representation that is an implementation detail.
What this all boils down to:
- for an "std::" library, it probably should be possible to write a non-intrusive serializer;
- a "just boost::" library can just dump its private members directly to
OK - I see this now. the
archive.
OK - agreed
Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr.
And getting back to our filesystem example, if the interface states that
external representation of a fs::path is the std::string returned by string(), then the library should provide support for just that, but in
rather than "suboptimal" - I would characterise it as a "just boost" shared_ptr implementation. Actually I only recently became aware that shared_ptr interface might be part of the standard library. I would hope that such an interface has functionality exposed to permit it's serialization to depend solely upon its interface. I don't know what this would entail. the the
meantime, it should be possible for the end user to non-intrusively serialize a fs::path by defining an appropriate serialize(Archive&, fs::path&, unsigned long) overload.
Apparently, it has done just that. Robert Ramey
"Peter Dimov" <pdimov@mmltd.net> wrote
An "std::" library (tuple, shared_ptr, filesystem?) needs to specify its external representation as part of the interface. This is mandated by the fact that users will - very likely - serialize its classes under implementation A and deserialize them under implementation B. This must work. [snip] What this all boils down to:
- for an "std::" library, it probably should be possible to write a non-intrusive serializer;
I understand the point you're making, but I'm not sure I agree...yet. To dictate the serialization layout might coerce a particular implementation. In the case of boost::filesystem, there is a convenient string format that can be used as the serialized form that can be reparsed into any implementation. Does that hold for any serializable std:: library component? With std::complex, you can choose to serialize as either polar or cartesian coordinates and either implementation can interpret the other. The public interface of std::map exposes all of the key/value pairs in the map, so writing the key/value pairs when serializing is enough to recreate a map. Thus far, your statement holds, but I haven't thought about every serializable object in std::, so there may yet be problems. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Class path already has a member, path::string(), which in the current implementation returns a reference to m_path, and in any implementation I have change the derived class to:
class OSD : public boost::filesystem::path { private: friend class boost::serialization::access; friend std::ostream & operator<<(std::ostream &os, const OSD&); template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & boost::filesystem::path::string(); } }; And it works!! While I am using frequently boost::filesystem::path::string() , I did not even try to use it in that case before, because I was certain to get a compile error on the statement: ar & boost::filesystem::path::string(); as boost::filesystem::path::string() is a const member returning a const std::string& reference So, forget my request .. sorry... Francis
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Beman Dawes -
David Abrahams -
Francis ANDRE -
Jeff Garland -
martin.ecker＠tab.at -
Pavel Vozenilek -
Peter Dimov -
Rob Stewart -
Robert Ramey