Template specialization for class != for subclass??

[daniel.w.gelder]

struct A
{
};

template <typename T>
struct X
{
void Method();
};

void X<A>::Method()
{
}

struct B : A
{
};

void main()
{
X<B> myX;
myX.Method();
}

This compiles, but produces a linker error in Codewarrior because
X<B>::Method() is undefined. B is an A, so why can't it just use the
X<A> method? It's not even ambiguous. Is there a workaround..?

Thanks in advance.
Dan

 

[Alf P. Steinbach]

* (e-mail address removed):

struct A
{
};

template <typename T>
struct X
{
void Method();
};

void X<A>::Method()
{
}

struct B : A
{
};

void main()

The standard only allows 'int' as result type for 'main'.

{
X<B> myX;
myX.Method();
}

This compiles, but produces a linker error in Codewarrior because
X<B>::Method() is undefined. B is an A, so why can't it just use the
X<A> method?

It's not even ambiguous. Is there a workaround..?

Depends what you're trying to achieve.

You might consider defining 'Method' generically for all template
argument types, or defining it in class 'A', or...

 

[daniel.w.gelder]

Actually I'm trying to make a class that has defines itself as a
subclass of whatever class you pass in. So X<A> is an X that overrides
A, X<B> overrides B, etc.

Obviously an X<A> is not an X<B>, yeah, but the stuff in X actually
never even touches A and B and the rest. X is a storage system that
wraps around anything. A and B is really the whole world, not just two
classes.

This works for anything or so it seems:

template <typename T>
void X<T>::Method()
{
}

Seems to bloat the code though...

 

[Alf P. Steinbach]

* (e-mail address removed):

Actually I'm trying to make a class that has defines itself as a
subclass of whatever class you pass in. So X<A> is an X that overrides
A, X<B> overrides B, etc.

This description isn't compatible with the code presented earlier,
which had no inheritance for template class X.

Obviously an X<A> is not an X<B>, yeah, but the stuff in X actually
never even touches A and B and the rest. X is a storage system that
wraps around anything. A and B is really the whole world, not just two
classes.

And this description, if I interpret it correctly as "A and B could be
any two classes where B is derived from A", is not compatible
with defining a specialization of X<A>::Method, because you then require
an infinite number of such specializations.

This works for anything or so it seems:

template <typename T>
void X<T>::Method()
{
}

Seems to bloat the code though...

That's a Quality of Implementation issue.

 

[daniel.w.gelder]

Well, if you want to know, here's *exactly* what I'm doing.

Oh god. It's just too hard to explain. Never mind.

Dan

 

[Rolf Magnus]

Well, if you want to know, here's *exactly* what I'm doing.

Oh god. It's just too hard to explain. Never mind.

If it's too hard to explain, it probably is a design error.

 

[Rolf Magnus]

Well, if you want to know, here's *exactly* what I'm doing.

Oh god. It's just too hard to explain. Never mind.

If it's too hard to explain, it's a bad idea. The "Zen of Python" is a nice
list of things you should consider when designing software. You get it if
you type "import this" in a python interpreter.

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!