|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-06 06:36:22
Pavol Droba <droba_at_[hidden]> writes:
> On Mon, Oct 06, 2003 at 01:06:17AM -0400, Brian McNamara wrote:
>
> [snip]
>
>> The point is, IMO, for concepts to be useful, they must be reified, and
>> concept requirements must all be located together in one place.
>> (Regardless of whether people agree with this view, my experience is that
>> concept-reification is an inevitable part of every template library's
>> evolution. It's gonna happen eventually, so when standardizing efforts
>> start to happen (like the root of this whole container_traits thread),
>> you might as well go ahead and do it "right".)
>
> I completely agree. One thing that get lost in this discussion was
> the purpose of container traits. Container traits make and
> abstraction over container concept (std.23.1). Adding addtional
> traits should be done only in regards to this concept. For instance
> insert_invalidates_iterators should go under sequence traits.
>
> Do I miss something again?
Yes. First of all, the Container concept has already been defined by
the standard, but even if you want to define your own, you can't keep
changing it every time you discover a new trait you might like to
explore.
Second, even if we use Brian's scheme, nesting all of these things
still has an efficiency impact, even though they're templates.
Furthermore it requires the syntactically heavy template keyword in
dependent contexts.
The insistence that everything needs to be grouped together is the
same as insisting that all concept requirements on regular classes
must be expressed as member functions and not as free functions.
But we've learned the lessons surrounding this issue too many times
for me to waste any more keystrokes on it. As I mentioned earlier, if
I haven't convinced you by now, I don't expect I will. If this thing
ever comes to formal review with the grouped implementation, I think
you can guess how I'll vote. I'll be satisfied with that as my final
expression of my opinion about it, and with whatever the group's
decision may turn out to be.
And now, on to other threads...
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk