Re: [boost] Is there any interest in a library that provides container
In-Reply-To: <1130423747.22962.246152955@webmail.messagingengine.com> atompkins@fastmail.fm (Andy Tompkins) wrote (abridged):
I have also realized that (for my purposes) I don't require the ability to delete people from a pointer to its base class [code skipped]
You might consider having wrap_vector inherit privately from std::vector and adding using-declarations rather than forwarding functions. I don't think using composition gains much, given that you are going to inherit from wrap_vector anyway. Using-declarations would be less code, possibly a lower abstraction penalty and would avoid problems with tracking exactly the std vector declarations.
// overload wrap_vector member functions for different behavior
That's risky, because there is an implicit conversion from people to wrap_vector<person> and your overloads won't affect the wrap_vector versions. What I think you really want to do is prevent the derived to base conversion. It's a shame this doesn't work: #include <vector> struct Container : public std::vector<int> { typedef std::vector<int> base; private: operator base &(); operator const base &() const; }; void test() { Container *p1 = new Container; Container::base &p2 = *p1; // Shame this compiles. } Maybe it is worth floating in comp.std.c++. -- Dave Harris, Nottingham, UK.
On Thu, 27 Oct 2005 19:19 +0100 (BST), Dave Harris < brangdon@cix.compulink.co.uk> 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
participants (2)
-
brangdon＠cix.compulink.co.uk -
Matt Calabrese