Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-22 15:39:31

Matthias Troyer wrote:
> On 22 Jul 2010, at 12:47, Robert Ramey wrote:
>>
>> Are you sure that there is no way around the mpi library requiring a
>> default constructor which
>> it should never invoke?  That makes the mpi library dependent on an
>> internal detail of the
>> the serialization library.  Is that the best/only way to handle this?
>
>
> The other compilers seem to optimize away the constructor of an
> unused argument, while the sun compiler seems to insist on
> instantiating it. We can redesign the MPI library to work around that
> breaking change in your library but I then wonder what you will break
> next.
>
> 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"

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

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

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.

So I'll leave it up to you a) or b)?

Robert Ramey