From: Robert Ramey (ramey_at_[hidden])
Date: 2008-05-21 12:01:50
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::
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
Anyway, a pleasant speculation and diversion from my
current stressful and frustrating task.
>> 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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk