|
Boost : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2002-12-17 20:24:44
From: Matthias Troyer <troyer_at_[hidden]>
>I would like to make a comment here: our aim was just to achieve
>portability between all different UNIX variants. We have about ten
>different UNIX architectures around, but actually no Windows machines.
>Thus, for our purposes XDR provides a perfect and portable binary
>format which we have ben using without problems for more than eight
>years.
is it possible to snag the xdr source code from FreeBSD unix so it can
be compiled for windows? I believe that the license would be boost friendly
I would love to include an xdr portable binary implementation but I think that
its appeal would be much diminished if itcouldn't be used by windows.
After all, its whole motivation would be is archive portability.
I believe that this addition would make it portable to all platforms
in common usage today (including Apple - based on freeBSD?).
>>> 5) "Versioning": [snip]
>I was more concerned with runtime overhead, but this needs to be timed.
the version is read and stored the first time a class is used. From then
on it is available when references so I doubt there would be any
detectable implact. Of course, I never have any objection to someone
running such a test if there is any doubt about the issue.
>I think we have one more disadvantage:
>e) will not be able to deal with polymorphic objects, since there are
>no virtual template functions
the virtual functions eliminated would be those currently in *archive.
user classes would be the same. Bascially instead of inheriting from
basic_[i|o] archives would be specialization of something like
class biarchive
{
biarchive & operator <<(int i)
...
}
then save/load would look like
template<class Archive>
void save(Archive &ar, T& t)
{
ar << member1;
...
}
So it would be quite similar in concept. I'm rather reluctant to delve into
this too much as it gets me into the position of comparing something that
is fully developed and working with something that is only an idea. Also
I can't ignore that I already invested much work implementing the first approach.
However I also can't ignore that addresses the two main complaints about
the submitted library. Users that want special functions added to the archive
to do things like fast arrays and/or XML tags can have them. Of course then
end up coupling the UDT serialization to a particular kind of archive. This
breaks a valuable feature of the library - independence of the archve
and UDT serialization. This feature makes the library easier to use and
understand in my opinion.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk