From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-05 00:31:16
David Abrahams wrote:
> As I said, I understand the general intent. It's the specific meaning
> that's unclear. It's especally unclear because you say "must
> implement the following interface..." and then show one member
> function with an implementation. You could provide that
> implementation by using a CRTP base class.
OK - I see this now. In fact, in the archives provided, it is implemented
using the CRTP model. I concidered that as a feature of the implementation.
I think I can adjust this to remove the implementations. I see now that
they don't belong here and that it is confusing.
>> Note that his concept is different than others in the standard
>> library in that one of the requirements is that it be a class with
>> certain required member functions.
>> Most or all other concept definitions only specify
>> operations for which the type is valid. As far as I know this doesn't
>> include supporting specific member functions.
> Actually, no. All of the concepts in the Container hierarchy share
> that property.
Of course. And I did study the SGI documentation in that regard. Now that
I think about, I'm sure this is where I got the idea to do it this way.
> Well, CRTP might be a good option for you, especially considering that
> function implementation I mentioned in the first paragraph above.
As I said, Ive used CRTP in the implementation. But I could imagine someone
making an archive class that didn't use CRTP and still have the archive
function. So I see it as an implementation detail rather than part of the
> So the question is, does the user actually need to use default
> arguments where your interface description does, or would overloads
> work just as well? Since you don't have a description of how to
> interpret your prototype, the answer is unclear.
The only default argument is
register_type(T * t = NULL);
and its only there because many compilers don't accept the syntax:
Its optional to support compilers that do support the above syntax. So I
guess that should be explained.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk