|
Boost : |
From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-04 10:34:25
On Fri, Oct 03, 2003 at 06:56:02PM -0400, David Abrahams wrote:
> Pavol Droba <droba_at_[hidden]> writes:
>
> > Given this structure, "new" interface is just a part of layer
> > 2. This is the presentation layer, but it should be documented
> > so. Core should be always the layer 1 ( and the "old" interface
> > ). It is very importatn due to extensibility reasons.
>
> You've got it upside-down, if you care about compile-time efficiency.
> Using any one of the nested declarations of the "old" interface causes
> them all to be instantiated. If you *must* maintain the "old"
> interface (and I still don't see a good reason for it) it should be
> built on top of the "new" one.
>
>From my exprience, a user of container_traits don't usualy use just one part
of the interface. Type resolution would have to be replicated for each trait.
This would lead to a quite complicated code. Or will end up with something
very similar to the current design. ( i.e. common core part used by all traits ).
Maybe I'm missing something, so please provide some explanation or example,
how to handle this problem in some better way.
There is another reason, why keep the interface in current state.
container_traits follow the same purpose as iterator_traits for the context of
containers. It makes sense to keep them in sync. If there were reasons to
define iterator_traits in the way the are, the same reasons apply for
container traits.
Pavol.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk