Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-22 19:03:58

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.

> 
>> Thus, the types you use to
>> serialize version information, etc. and the list of "primitive types"
>> which any archive has to explicitly support belong to the public
>> interface of your library. It would be good if you could add
>> information to the documentation that states this list of types and
>> the concepts they satisfy.
> 
>> 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,

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

> 
> If it makes everyone feel better I take full responsability for this
> problem and accept the entire blame for this problem.
> 
> Now the point that interests me:
> 
> It's become clear that the question boils down to:
> 
> a) make the indicated default constructors public
> or
> b) tweak the MPI code so it doesn't instantitiate code it doesn't use.
> 
> I can do a) and it's not too hard, but it opens me up to this kind
> of problem happening again and makes it easier for errors to creep in.
> 
> You can do b).  I have no idea how hard it is.  If it's easy and it
> resolves a valid warning and also eliminates non-sensical code (returning
> a reference to an object which has disappeared off the stack). 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.

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

Matthias