Re: template member function specialisation of standard container functions
On 29/06/11 00:12, Ulrich Eckhardt wrote:
cpp4ever wrote:
With regard to your own container template class, if a template class of
a type, (class SomeObject), requires a lot of it's member functions
specialised, (>60% perhaps), then surely it would be better to implement
a template class specialisation.
I disagree, if you need to specialize large parts of a class in order to use
it with your type, then maybe you shouldn't use it. If for example you took
a vector<T> and hacked it via specializations to allow auto_ptr<baseclass>
as type, then the vector wouldn't be a vector anymore. In particular, it
rather obfuscates to the casual reader that this vector behaves very
differently from the one they already know.
I'm thinking it would be a better idea to define those class template
member functions that often need specialisation as virtual, (as well as
the destructor), and then achieve the same result via inheritance and
overriding.
I don't want to pay the price for that overhead when you're talking about
containers. I haven't found the need to override anything there. Concerning
a container that allows auto_ptr<baseclass>, this can easily be done using
aggregation instead of overriding or specialization. For this example, the
aggregated vector is a vector<baseclass*> while the wrapping code converts
the various function calls. Using e.g. Boost.Iterator you can even get the
STL iterator interface working with little effort.
In this case should the template class itself inherit a well
defined interface, (pure virtual base class)? This approach does appear
to be easier to implement/understand/extend than using class template
member function specialisations.
Thanks Daniel for your response, and like yourself I have never seen
this done for production code. This certainly suggests that although the
idea is possible, it is not a good solution for reasons I have given to
a better alternative solution idea in the previous paragraph.
I'm seriously wondering what you are doing. In particular, what should this
push_back() specialisation that you mentioned do differently than the
default? What is it you're trying to achieve?
Cheers!
Uli
Thanks for your feedback Ulrich. What you say makes good sense and only
adds to my concerns about the approach I've taken. The original reason
for trying this approach was the Qt GUI development of a tree view
implementation, so speed is not really a factor. Essentially Qt
implements the tree view using a generic abstract class interfaces for
the view and the underlying model. What I was trying to do was create a
consistent model using a template class for the rows displayed in the
tree view, as the data to be displayed varies depending on the row and
where it appears within the tree view. In this case the basic model
implementation needs to reflect the implementation requirements of a Qt
GUI tree view, which uses a set of generic methods to update the tree
view. As well as preserving relationships between different rows, which
determines which can be edited or deleted. On this last point I agree
that creating an aggregation class is a better solution than
specialisation of the container add/remove methods.
All feedback is appreciated, and I know I've more to learn
Cheers
cpp4ever
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]