David Abrahams wrote:
At Tue, 27 Jul 2010 11:58:19 -0800, 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.
As written this would work fine. Since it is not a primitive, the default serialization would be to insist upon the existence of a serialize function. So this would only be a problem if the type is marked with the serialization trait "primitive". It so happens it's not very common to do so. Of course if this WAS marked primitive then there would be a compile time error due to the ambiguity. Actually, the convertability isn't stated in the documenation or concept. It's just what when I made the archive models, convertibility reduced/eliminated most of the code. I just plowed on and finished the job. So I suppose the concept as stated isn't accurate. I did in fact look into using the concept library. I had a few problems understanding it. To get a better idea I looked for other boost libraries which used it and didn't find any. (I took a special look at the iterators library!). At the time the c++0x was going to include concepts so it was more interesting to wait. Concept Traits was abandoned for this reason. There was a lot of discussion about using SFNAE to re-write it. So there were lots and lots of reasons to not invest the required effort. I do see the appeal of such a thing - especially in conjunction with making the documentation but it always seemed that it wasn't quite ready for prime time.
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.
I haven't need getters/setters for any serialized types. In fact the whole code base only has maybe two.
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.
I don't think this is an issue - at least its never come up as one. Robert Ramey