Is there a serialization::is_archive<> ?
Hi all, while trying to add serialization support for fusion sequences I came across the need to figure out whether a given type actually is an archive. Is there a boost::serialization::is_archive<> metafunction available? And if not, what's the best way to implement this? Regards Hartmut
Hartmut Kaiser wrote:
Hi all,
while trying to add serialization support for fusion sequences I came across the need to figure out whether a given type actually is an archive. Is there a boost::serialization::is_archive<> metafunction available? And if not, what's the best way to implement this?
Hmmm - I chuckled when I read this. It seems that I would be asking you this question rather than the other way around. Giving it a tiny bit of thought leads me to wonder: First thought is one could use something like is_base_derived to verify that it derived from from one of the common base classes. This solution would probably be sufficient for most practical purposes. But, it seems to me that the real thing would be: models_archive_concept<T> Which is really piques my interest and curiousity. It would be a general thing like models_concept<T, C> where C is some sort of "conept type" Food for thought for those with time on thier hands. Robert Ramey
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert,
while trying to add serialization support for fusion sequences I came across the need to figure out whether a given type actually is an archive. Is there a boost::serialization::is_archive<> metafunction available? And if not, what's the best way to implement this?
Hmmm - I chuckled when I read this. It seems that I would be asking you this question rather than the other way around.
You're the serialization master, not me :-P
Giving it a tiny bit of thought leads me to wonder:
First thought is one could use something like is_base_derived to verify that it derived from from one of the common base classes. This solution would probably be sufficient for most practical purposes.
That would be sufficient for now I think. What are the base classes I could use to test against? Regards Hartmut
http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/class_diagram.ht... Hartmut Kaiser wrote:
Robert,
while trying to add serialization support for fusion sequences I came across the need to figure out whether a given type actually is an archive. Is there a boost::serialization::is_archive<> metafunction available? And if not, what's the best way to implement this?
Hmmm - I chuckled when I read this. It seems that I would be asking you this question rather than the other way around.
You're the serialization master, not me :-P
Giving it a tiny bit of thought leads me to wonder:
First thought is one could use something like is_base_derived to verify that it derived from from one of the common base classes. This solution would probably be sufficient for most practical purposes.
That would be sufficient for now I think. What are the base classes I could use to test against?
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert,
http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/class_diagr am.html
Thanks! Even if I would have preferred to get a slightly more verbose answer from you. Please keep in mind that I don't have _any_ clue about what class might be the best to use in this context. So I take it that the basic_iarchive and basic_oarchive classes are the ones I'm looking for. Regards Hartmut
Hartmut Kaiser wrote:
Robert,
while trying to add serialization support for fusion sequences I came across the need to figure out whether a given type actually is an archive. Is there a boost::serialization::is_archive<> metafunction available? And if not, what's the best way to implement this?
Hmmm - I chuckled when I read this. It seems that I would be asking you this question rather than the other way around.
You're the serialization master, not me :-P
Giving it a tiny bit of thought leads me to wonder:
First thought is one could use something like is_base_derived to verify that it derived from from one of the common base classes. This solution would probably be sufficient for most practical purposes.
That would be sufficient for now I think. What are the base classes I could use to test against?
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Tue May 20 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Hartmut Kaiser wrote:
Hi all,
while trying to add serialization support for fusion sequences I came across the need to figure out whether a given type actually is an archive. Is there a boost::serialization::is_archive<> metafunction available? And if not, what's the best way to implement this?
Hmmm - I chuckled when I read this. It seems that I would be asking you this question rather than the other way around.
Giving it a tiny bit of thought leads me to wonder:
First thought is one could use something like is_base_derived to verify that it derived from from one of the common base classes. This solution would probably be sufficient for most practical purposes.
But, it seems to me that the real thing would be:
models_archive_concept<T>
Which is really piques my interest and curiousity. It would be a general thing like
models_concept<T, C> where C is some sort of "conept type"
Food for thought for those with time on thier hands.
You can only implement the above for a very limited number of _syntactic_ concepts in C++03 and unintentional syntactic conformance can easily be catastrophically mistaken for actual semantic conformance (e.g. there are input iterators that have the syntactic properties of forward iterators, which causes crashes and worse in real STL code). In C++0x of course we have real concepts, but for reasons noted above explicitly-declared conformance plays an important role so I'm afraid that doesn't get you off the hook, Robert ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I thought about this a tiny bit more: using is_base_and_derived<T> is probably OK in practice. But it bugs me a little bit as it's not really correct. It presumes that an archive class is derived from the basic implementations in the library. But in fact, the archive concept is broader than that implementation. So, someone could make a new archive class from scratch. That archive class could even implement different semantics - e.g. copying pointed to data rather than resurrecting new pointers. etc. Someone might want to hijack the serialization interface for implementing a generic "deep copy" for memoization. I'm not sure this should be inhibited or even discouraged. This touches on the question of what it means - or should mean - to "model" a concept. which to my mind has always been less clear to me than it seems to be to everyone else. So a "more correct" with might be to use the existence of:: boost::archive::is_saving<A> and boost::archive::is_loading<A> As tags indicating that these are meant to be used as archives. Of course this would mean including a default definition in one's own program - but maybe that's OK. Or may be the serialization header should include a default definition returning mpl::false. Anyway, a pleasant speculation and diversion from my current stressful and frustrating task. Robert Ramey
models_concept<T, C> where C is some sort of "conept type"
Food for thought for those with time on thier hands.
You can only implement the above for a very limited number of _syntactic_ concepts in C++03 and unintentional syntactic conformance can easily be catastrophically mistaken for actual semantic conformance (e.g. there are input iterators that have the syntactic properties of forward iterators, which causes crashes and worse in real STL code).
In C++0x of course we have real concepts, but for reasons noted above explicitly-declared conformance plays an important role so I'm afraid that doesn't get you off the hook, Robert ;-)
participants (3)
-
David Abrahams -
Hartmut Kaiser -
Robert Ramey