template for class method problem

[Larry Beck]

Below is a problem I am having with templates. I am trying to use a
template to avoid having multiple class methods that differ only in the
return type of the pointer. I have tried putting in another parm of the
typename to guarantee the uniqueness of the parm list but it didn’t
help. I am getting undefined externals from the linker, one for each
elemental type. Any ideas would be appreciated.

Thank you,

// Class declaration
class UTILITY_STUFF
{
public:

template<typena me T>
T* GetJunk(unsigne d int x, unsigned int y);
}
// Method usage
template<typena me T>
T* UTILITY_STUFF:: GetJunk(unsigne d int x, unsigned int y)
{
return (T *)junkFunction( x,y);
}
// Template
template<typena me T>
bool junk(T* pDummy, unsigned int X, unsigned int Y)
{
UTILITY_STUFF* someJunk;
nitfValue = someJunk->GetPixel<T>( X, Y);
}

[Alf P. Steinbach]

* Larry Beck:

Below is a problem I am having with templates. I am trying to use a
template to avoid having multiple class methods that differ only in the
return type of the pointer. I have tried putting in another parm of the
typename to guarantee the uniqueness of the parm list but it didn’t
help. I am getting undefined externals from the linker, one for each
elemental type.
That doesn't say much. But one common template-novice error is to put
template function definitions in an implementation file instead of the
header file. With current compilers a template function definition must
be available at the point where the function is called.

Any ideas would be appreciated.

Thank you,

// Class declaration
class UTILITY_STUFF
Don't use all UPPERCASE except for macro names.
{
public:

template<typena me T>
T* GetJunk(unsigne d int x, unsigned int y);
}
Missing semicolon.

// Method usage
template<typena me T>
T* UTILITY_STUFF:: GetJunk(unsigne d int x, unsigned int y)
{
return (T *)junkFunction( x,y);
Don't use C-style casts. Also, this particular usage is extremely
dangerous because you're not only telling the compiler to accept the
code you have right here, no matter what. You're telling the compiler
to accept the _client_ code, no matter what type T it has supplied.
}

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Larry Beck]

Alf P. Steinbach wrote:

That doesn't say much. But one common template-novice error is to put
template function definitions in an implementation file instead of the
header file. With current compilers a template function definition must
be available at the point where the function is called.

I have the the template function def in the header file. I just put
stripped down code in the message to make it easier to send.

// Method usage
template<typena me T>
T* UTILITY_STUFF:: GetJunk(unsigne d int x, unsigned int y)
{
return (T *)junkFunction( x,y);

Don't use C-style casts. Also, this particular usage is extremely
dangerous because you're not only telling the compiler to accept the
code you have right here, no matter what. You're telling the compiler
to accept the _client_ code, no matter what type T it has supplied.

}

Can you give me a better way of doing it?

Thanks,

[Alf P. Steinbach]

* Larry Beck:

Alf P. Steinbach wrote:

That doesn't say much. But one common template-novice error is to put
template function definitions in an implementation file instead of the
header file. With current compilers a template function definition
must be available at the point where the function is called.

I have the the template function def in the header file. I just put
stripped down code in the message to make it easier to send.

The best advice I can give: make a smallest possible program that
exhibits the problem, post the complete (smallest possible) code here.

// Method usage
template<typena me T>
T* UTILITY_STUFF:: GetJunk(unsigne d int x, unsigned int y)
{
return (T *)junkFunction( x,y);

Don't use C-style casts. Also, this particular usage is extremely
dangerous because you're not only telling the compiler to accept the
code you have right here, no matter what. You're telling the compiler
to accept the _client_ code, no matter what type T it has supplied.

}

Can you give me a better way of doing it?

Depends what "it" is. One further problem with the code as shown is
that it doesn't tell what "it" is or could be... The only thing that
/seems/ clear is that the client code should be able to specify a type,
and in your implementation you must, somehow, make sure that the
specified type makes sense and is compatible with the result of
junkFunction -- but even this is perhaps not cast in stone, for
perhaps what you're trying to do does not require the client code to be
able to specify any type whatsoever?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?