Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-22 20:42:48

Matthias Troyer wrote:
> On 22 Jul 2010, at 13:39, Robert Ramey wrote:
>>>
>>> I totally disagree with your statements that we depend on internal
>>> details of Boost.Serialization. Boost.Serialization does publish an
>>> (incomplete!) archive concept and you did intend that others can
>>> extend it with new archive classes.
>>
>> The published archive concept specifes the concepts that must
>> be fullfilled by any serializable types.  The serialization
>> library includes examples of archives which depend upon only
>> on the documented concepts.
>>
>> The documentated archive concepts don't prevent other archive
>> classes from including more functionality.  Indeed, facilities such
>> as serialization of pointers through a base class, etc demand it.
>> And it's true that I haven't discouraged leveraging on these
>> "extended archives"
>
> I'm talking about the requirements on a minimal archive. Those are
> not fully documented.

Hmmm that would be news to me.  I compiled trivial archive from
the documentation with serialization code.  And trivial archive
is model of minimal archive.  That is I believe that serializing
any types to a trivial archive will compile without error.
If there is a serializable type which trivial archive fails
to work with, I would be interested in hearing about it.

>>> In the absence of that information I can
>>> validly assume that the public members of the version_type, etc. is
>>> what I can use and which will not change.
>>
>> hmmm - of course you can assume that - but I can't guarentee it.
>
> Then we need a list of concepts for these types that you do
> guarantee, or your next change might again break code,

These are the one's in the archive concept.

>>> The moment you allow new  archive classes to be written, the
>>> version_type, etc. is no longer an  internal detail!
>>
>> hmmm - one could just as well say that once one depends upon
>> undefined behavior, you can't guarentee that the code will not
>> break.

> So you are saying that implementing new archives basically depends on
> undefined behavior and you cannot guarantee that it will not break in
> the next release? It would be better to publicly defines the concepts
> for an archive and for the primitive types if you do not want us to
> take the current public interface of those classes as the implicit
> concepts.

The archives included with the package - binary_archive in this
case have implementation features beyond what is required
to satisfy the archive concept.  In this case there is a type
used called version_type.  Actually - until now, version_type
wasn't part of the binary_archive at all - it was just one
more serializable type.  So any dependency on some feature
of version_type wasn't really a dependency on the archive
class at all but on one of the types that is used to implement
binary_archive.

MPI serialization leverages on the implemention of binary_archive.
This makes a lot of sense of course.  But it means that time
to time this situation will occur.  The only way to avoid this
is for mpi serialization to depend only on the archive
concept as described in the documenation and modeled
by trivial archive or never change the implemenation of
binary_archive again.

>> Note
>> that if get_mpi_type() was actually called and the result used it
>> would result in a program crash. I would prefer that this be done.

> Actually not, this warning seems spurious. And indeed the function
> get_mpi_type() *is* called all the time.

but the result isn't used. if it were it would crash the program.
Returning a reference to a value on the stack and then truncating
the stack with a return invalidates the result.  The warning is
correct and useful in my opinoin

>> So I'll leave it up to you a) or b)?
>
> b) might break other compilers and will thus take longer to test. I
> think that it will be easier to do a) which should not break the
> other compilers but get the Sun compiler to work.

OK - I'll make the default constructors visible.

Robert Ramey