Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: David Abrahams (dave_at_[hidden])
Date: 2010-07-28 09:14:49

At Tue, 27 Jul 2010 15:31:50 -0400, David Abrahams wrote, and Robert
Ramey snipped:

> > And what is your definition of Serializable (precisely, please)?

So could you please answer that question?

At Tue, 27 Jul 2010 13:02:29 -0800,
Robert Ramey wrote:
> 
> 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.  

Then it wouldn't work fine.  It's neither a primitive nor does it have
a serialize function.  You wrote:

  I believe that any type implicitly convertible to a c++ primitive
  type (type and reference) is a serializable type.

and X contradicts that.  We can go around and around on this until
your definition of Serializable is solid, and I'm even willing to do
so if that's what it takes to help you get this right.

> 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.

Doesn't surprise me.

> 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.  

Then you didn't look very hard.

> (I took a special look at the iterators library!).

The iterators library does in fact use it (though probably not
everywhere it should).  The Graph library uses it all over the place.

> 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.  

There may have been, among people that didn't understand the library,
but I think I pretty clearly stated at the time that you can't get
SFINAE to do what this library needs to do.  SFINAE is all about not
causing compilation errors, while BCCL is about intentionally causing
them.

> 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.

The same basic technology has been in libstdc++ (the standard library
that ships with GCC) for years and years, so I think you're mistaken.

> > 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.

I didn't say anything about getters and setters.  I said “the
interface that gets and sets their values.”  An interface that sets
the value might be the assignment operator.  An interface that gets
the value might be a conversion to int.

> >  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.

I think this is exactly the issue that Matthias faced.  If you don't
specify how to create a value of any given primitive type, how is he
supposed to deserialize it?

Is anyone else implementing archives other than you?  If not, he's the
only serious consumer you have of the archive concept.  As the person
in control of both sides of that contract, you're not going to notice
these kinds of problems if you don't have solid concept definitions
and concept checking in place, because you are free to
(unintentionally) make changes that subtly alter the contract.

This comes down to one thing: you need to decide what your public APIs
are, and you need to have tests for all of them that don't make any
assumptions beyond what's specified in the API.  Maybe it would be
easier to achieve if someone else were writing the tests.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com