Re: [boost] [serialization] concept requirements

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-22 00:48:47

"Robert Ramey" <ramey_at_[hidden]> writes:

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

It's not prohibited, but that isn't the way the library is designed to
be used.  In any case, deriving from multiarray<...> or
array_view<...> has little or nothing to do with concept checking.

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

  function_requires<MutableMultiArrayConcept<my_array_class,N> >();

seems pretty straightforward to me.

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

Maybe.

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

I don't believe that text appears anywhere.  The actual text is
missing a description for b in table 1
(http://www.boost.org/libs/multi_array/doc/reference.html#id832486).
It should read

   a, b   objects of type A

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

I don't know why that should surprise you.  It isn't possible to write
a standalone operator that will work with any two types modeling the
concept, and will always be found.  Given two arbitrary types, in
arbitrary namespaces, the operator== in

     a == b

has to come from one of those namespaces, or it has to be a member of
a.

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

No, that's not what concepts are about.  Concepts are about
typechecking and verifying documentation.

You can easily write a generic algorithm that would compare any two
models of MultiArray, but Concepts can only help you understand how to
do it correctly.  They won't be useful in your code, except as a fancy
kind of static assertion.  They don't provide functionality.

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

You're expecting the wrong things of concepts.

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

If they're all of that ilk, you should allow them to unstick, because
your expectations are misaligned with the intended purpose of the
technology.  You can't help but be disappointed.

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

That's probably true, but not at all for the reasons you think.  If
you want to understand the total potential of concepts you have to
read something like
http://www.generic-programming.org/software/ConceptGCC/... but that
describes extensions to the C++ language.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com