Re: [boost] [serialization] concept requirements

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-21 23:53:34

David Abrahams wrote:
\
> Okay.  Or maybe that implementation detail of the library doesn't need
> to be documented at all.

It's in a section of the manual titled "Implementation" which is designed
to help those who want to make their own archive implementations. Of
course they should be able to start from scratch but this section is
for those who want to leverage on what's already been don.

>> That opportunity presented itself when I had occasion to use the
>> multi-array library.  I tried to use the concepts included to check
>> my code deriving from this class which didn't work out for me.
>
> Which class were you deriving from?

multi_array and array_view

> IIUC the MultiArray library doesn't have any classes meant to be
> derived from in it,

Hmmm, the class was there, there was no prohibition in either the
code nor in the documentation indicated that it was not to be
derived from.  My interest was adding information regarding
each row/column which would be carried along as the
matrices were sliced and diced.  I verified that my derived classes
did in fact model the multi_array concept.  I tried to
verify this with the included concepts - but couldn't make
it work.  So gave up on the concepts and just used the code.

>and until very very recently there was no way to
> use derivation with the concept checking library either, so what
> you're saying doesn't make much sense.

well maybe that was my problem.

>> Then I dug deeper and found that although the concepts were
>> included, the code was written in terms of specific classes rather
>> than templates which used type arguments checked with the concepts.
>
> That doesn't square with what I'm seeing in the multi_array code.  For
> example, in multi_array.hpp:
>
>
>  template <class ExtentList>
>  explicit multi_array(ExtentList const& extents,
>                       const general_storage_order<NumDims>& so) :
>    super_type((T*)initial_base_,extents,so) {
>    boost::function_requires<
>      detail::multi_array::CollectionConcept<ExtentList> >();
>    allocate_space();
>  }

>
> How do you think they're supposed to be "used?"
>
well what I'm seeing is the operation

a == b is a valid operaton where a and be are models of multi_array.

A plain reading of the concept documentation suggests that this
is a valid operaton for any pair of types modeling the multi_array
concept. However when you actually try it - it only works when a and
b are the same type.  I went back to the documentation and
could see that my plain reading was not the only way to
interprete the documentation.  And looking at the code you
find that a==b is defined as member function for each class.
Rather than as a stand alone operator which will work with
any pair of types modeling multi_array concept.  In my view
the appeal of the the concept concept would be to permit
that that a==b be implemented as a template with
for any type A and B modeling multi_array concept.  That would
have been less code to write and would have resulted
in something much closer to what a user of this library
expects to see.  That is what I mean when I say that
the Concept isn't used.  The a==b operation was what
I needed when I wanted to compare a view slice from one
multi_array with another full multi_array - a very reasonable
expectation it seems to me.  That's just one example
the currently sticks in my mind - there are others.

> Well, that's a great idea, actually.  But seriously, you don't need
> that much hand-holding.  Who is likely to go to the trouble to write
> that, when
> http://www.boost.org/libs/concept_check/using_concept_check.htm is
> already *extremely* generous and easy on the reader?

Actually a pretty good start.  But as I've said, I think total potential of
the concept concept can't be appreciated from the documentation.

Robert Ramey