Re: template member function specialisation of standard container functions
On 29/06/11 00:15, Matthias Hofmann wrote:
"cpp4ever" <n2xssvv.g02gfr12930@ntlworld.com> schrieb im Newsbeitrag
news:VuaOp.15475$m22.11284@newsfe05.ams2...
Hmmmm, I think the standard does not mean that member function
specialisation of a standard class cannot actually be done, rather that
to do so could invalidate the operation of the standard class making
it's behaviour undefined.
The behaviour of your code is undefined if the standard says so. In this
case, it does not make any sense arguing how and why exactly your program
is
going down the drain, if it does. From the moment you set foot in
undefined
behaviour land, anything can happen, including that your program behaves
just as expected, which is the worst case, because then you don't notice
that your code is wrong. It's a common mistake to bother one's head about
what the compiler will do in a situation that is not supposed to happen,
rather than learning to avoid such code.
Regardless of this, I agree with the standard
and hence it should not be attempted.
If you disagreed with the standard, your code would be likely to be
anything
but C++.
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.
If I understand you correctly, you mean something like this:
#include <list>
template <typename T>
class MyContainer
{
std::list<T> m_list;
public:
// Polymorphic deletion
// requires an accessible
// virtual destructor.
virtual ~MyContainer() {}
virtual void push_back( const T& x )
{ m_list.push_back( x ); }
};
class MySpecialContainer : public MyContainer<int>
{
public:
virtual void push_back( const int& x )
{
// Do something special for integers here.
}
};
In this case should the template class itself inherit a well
defined interface, (pure virtual base class)?
What is a "well defined interface" to you? A poorly defined interface does
not sound like anything you want to work with.
This approach does appear
to be easier to implement/understand/extend than using class template
member function specialisations.
This approach appears rather awkward to me. Besides, it won't work for
classes from the C++ Standard Library because you cannot redefine their
members functions to be virtual.
All further thoughts and ideas on this are appreciated, even if it is a
somewhat esoteric part of the capability of C++.
There is nothing esoteric about templates and specializations. They belong
to the core and most powerful features of C++.
Thank you for your response Matthias. What you say is good sense, and I
found the implementation becoming awkward. Further to the feedback, I am
grateful to receive, I'm still interested in creating my own container
template. But the management of the relationships between different data
in different containers still needs to be done. It appears to me that
using class aggregate objects within the containers is a better solution
to this last problem, rather than a lot of container template
specialisations. The main reason for this is it's a more elegant/simple
solution, and this is important when code needs to be maintained.
Matthias, true, there is nothing esoteric about templates and
specializations, but outside of template libraries like STL and Boost I
rarely see it being used.
As ever, there is always 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! ]