David Abrahams wrote:
Hi Robert,
Once again I find myself confounded by the true concept requirements for archives. Once upon a time, the truth-as-we-knew-it was that the following (copied from the library docs) was part of the input archive requirements.
All input archives should be derived from the following template:
template<class Archive> detail::common_iarchive;
The above state isn't correct - as you've discovered. it seems to me that it should say something like" "archives included as part of the library have been derived from the following template: template<class Archive> detail::common_iarchive; In order to factor out common code to fewer modules."
But, as I just discovered: polymorphic_iarchive doesn't meet those requirements.
Note that polymorphic_?archive is an abstract base class. Hence, it cannot perform the operations required by the archive concept. So I would say only a derivation from polymorphic_?archive can fulfill the archive concept. All derivations from polymorphic_?archive included with the library do in fact also derive from common_?archive. Actually, the application of "Concepts" in the context of an abstract base class is a little ambiguous to me. I would have to think about it.
Since you have struggled with how to write the concept requirements for archives, I have a brilliant suggestion: create concept checking classes and archetypes using Boost.ConceptCheck, and use those to formulate and validate your concepts. Then you can simply copy the concept checking classes into your documentation and add a description of semantic constraints. You can't go wrong if you do that; the compiler will check your work for you, and make sure your code is consistent with your documentation.
This is an idea that has occurred to me before - actually during our memorable discussion regarding documentation of the serialization library. Actually until that time I had only the barest notion of the utility and usage of the the "Concepts" concept. When I looked at it more carefully, I saw the utility of building and maintain the concept classes during library development. This would help a lot in maintaining a consistent view, avoid dead ends, etc, etc. And of course it would help the documentation. I resolved to look into it when I had some time. 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. 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. Oh and there were some compiler dependent quirks. All in all it seemed that the concept checking classes were added on at the end to satisfy some documentation requirement. They weren't really used as far as I could tell. So, all in all, I was very disappointed. My general impression was - great concept - but not quite ready for "the rest of us"(r). I do see much merit in the idea of developing the library, concepts and documentation skeleton in parallel. When I made the serialization documentation, I followed the boost pages regarding how to make boost documentation and they didn't (don't) mention anything about concepts and how to use them. What is really needed is a tutorial/example on making a very small boost library which would show how this is done. Starting with a small idea and showing how each change ripples through the library, concepts, skeletal documenation, compile - only tests - for testing the concepts, and runtime tests - for programming errors.
[I have recently upgraded the ConceptCheck library to allow some nicer but as-yet-undocumented syntax. When (if?) you decide to do this, I'll give you the quick skinny]
By the time I get to something like this, I would expect that the required information will have migrated into boost documentation. Robert Ramey