[boost] Re: Re: Re: Re:[fileststem]1.32:withserilization:visibility of m_path

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-09 12:34:14

"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:6.0.3.0.2.20041109120357.0258a188_at_mailhost.esva.net...
> At 11:30 PM 11/8/2004, Robert Ramey wrote:
>  >
>  >"Beman Dawes" <bdawes_at_[hidden]> wrote in message
>  >news:6.0.3.0.2.20041108214926.02e42130_at_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.
>

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