Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-06 07:11:41

On Mon, Oct 06, 2003 at 07:36:22AM -0400, David Abrahams wrote:
> Pavol Droba <droba_at_[hidden]> writes:


> > 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.
Sorry for missunderstanding. I wasn't arguing for the monilitic
implementation, I was merely trying to point out that container
traits (in one implementation, or another) should follow the container concept.
And that it is very true, that uncontrolled extensions could
provide more chaos then usefulness.



Boost list run by bdawes at, gregod at, cpdaniel at, john at