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