Re: [boost] Is there any interest in a library that provides container

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-27 14:01:23

On Thu, 27 Oct 2005 19:19 +0100 (BST), Dave Harris <
brangdon_at_[hidden]> wrote:

> What I think you really want to do is prevent the derived to base
> conversion. It's a shame this doesn't work:
> private:
> operator base &();
> operator const base &() const;

That wouldn't really solve much. For one, pointers are still convertible and
other logical relationships still exist. The relationship between children
and base types is more complex than just simple implicit conversion of a
child object to a reference to a base. If anything, a way to get the desired
functionality would be to have an aggregate form of inheritance which
doesn't represent an IS-A relationship, yet which incorporates the public
interface of the base into the public interface of the child. I believe
eiffel supports such a relationship if I remember correctly, though I've
never personally used eiffel so I can't say for sure.

To be honest though, I don't see such a facility as being as useful as one
may initially think, though still useful none-the-less. For instance, if you
truly believe the relationship is not IS-A in this case, then some of the
nested types and member functions may not be a good idea to use since the
iterator types are now the same. Two completely distinct containers, in my
personal opinion, would have different iterator and const_iterator types for
proper type safety even though they may be able to be implemented internally
in the same manner, similar to some but not all of the reasons as to why
many vector implementations choose to use their own iterator and
const_iterator types as opposed to just using raw pointer types directly
(which are perfectly valid as vector iterator types).

Either way, I don't see such a form of aggregation as being a necessity to
the language, as the functionality already exists via private inheritance
and using-declarations. The language is complex enough as it is, especially
considering some of the very useful additions currently proposed. I'd rather
not see the language take in somewhat redundant functionality with limited
benefits over current alternatives.

--
-Matt Calabrese