At Tue, 27 Jul 2010 11:58:19 -0800, Robert Ramey wrote:
David Abrahams wrote:
At Tue, 27 Jul 2010 09:19:53 -0800, Robert Ramey wrote:
First of all - these are serializable types by virtue of the fact that they are convertible to integers and references to integers.
If you are claiming that convertibility to integers and references to integers is enough to satisfy your Serializable concept, I can almost **guarantee** you that the concept is ill-defined, and that using the Boost Concept Check Library properly would prove it.
Hmm - that is in fact my claim. In fact I believe that any type implicitly convertible to a c++ primitive type (type and reference) is a serializable type.
An archive class is required to be able to serialize all serializable types - so any archive class has to be able to serialize all c++ primitives.
And what is your definition of Serializable (precisely, please)?
So what am I missing here.
try this example, and see how well your library deals with it. struct X { operator short() const { return 0; } operator short&() const { return 0; } operator long() const { return 0; } operator long&() const { return 0; } }; in concept requirements the use of convertibility almost always causes problems.
BTW - I just checked the documentation and althoutgh the above is what I meant - it doesn't quite say this. I can easily fix that.
For what it's worth, based on these discussions (and not a recent look at your docs, admittedly) I _think_ I can identify at least one problem with your specification and your idea of what is a proper implementation detail. Please tell me if I'm wrong: You require archives to handle all primitive types, yet there is a large class of such types for which you say the interface that creates instances, and gets and sets their values, is a private implementation detail. If I have that right, it means there's no reliable way to get their bits into an archive so they can be deserialized with the same values they went in with. -- Dave Abrahams BoostPro Computing http://www.boostpro.com