Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-27 17:02:29

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