Once I change the function prototype of DestroyFunc so that it matches with the definition, it compiles and links fine for me on MSVC 2003. The template functions are all defined in headers or are otherwise available right?

To toss out some random possibilities:

1) Try placing the static keyword with the function declerations as well. I don't think it's needed (it may not even be valid) but it's worth a shot.
Given SiCrane's response, I apparently was correct in thinking it wasn't needed.

2) Are the functions declared within a source file? Currently, most compilers require the functions be declared where they're "visible" for proper instantiation, or manually instantiated. E.g.:

Option 1: Visible decleration for automatic instantiation (multiple files not required)

//tmemory.hpp#ifndef IG_TMEMORY#define IG_TMEMORYtemplate < typename T > struct tMemory {    ...};#include "tmemory.impl"#endif //ndef IG_TMEMORY//tmemory.impltemplate < typename T > void tMemory< T >::Allocate(T * & Memory , unsigned int Count ) {    ...}...

Option 2: Manual instantiation

//tmemory.hpp#ifndef IG_TMEMORY#define IG_TMEMORYtemplate < typename T > struct tMemory {    ...};//Not including their actual implementation://#include "tmemory.impl"#endif //ndef IG_TMEMORY//tmemory.impltemplate < typename T > void tMemory< T >::Allocate(T * & Memory , unsigned int Count ) {    ...}...//tmemory.cc#include "tmemory.impl"template tMemory<int>;template tMemory<char>;template tMemory<int (*)(void *)>;...

Option 3: Use the export template feature
This isn't available on most compilers. However, see Comeau C++ Export Overview documentaiton for that, for the, like, one compiler that does that. Comeau, in case you couldn't guess :-).

Quote:Original post by ZedFx
template < typename T > void tMemory< T >::Allocate(T * & Memory, unsigned int Count)
and
template < typename T > void tMemory< T >::Free(T * & Memory)
are defined in tMemory.cpp which includes tMemory.h

Here's the problem. Unless your compiler supports the export keyword, and I'm willing to bet that yours doesn't, then you can't put the definition of a template in a separate source file without explicit instantiation for specific types. Without explicit instantiation, the complete definition of the template needs to be available at point of instantiation, which means, in effect, that the definition needs to go into the header. (Or an inline file of some sort, etc.)

For more details see these articles: "Export" Restrictions, Part 1 and "Export" Restrictions, Part 2.

Quote:Original post by kSquared
Also evil is using the dreaded ellipsis construct in a catch expression.

That much I definately would not call evil, even though in this case, considering the body of the catch, it is.

Often times, especially in templates, you may need to peform some type of memory deallocation, other cleanup, or something else when any exception is thrown, usually prior to a rethrow (since you often can't handle an exception when you don't even know what it is). You may not know what type of exceptions can be thrown, for instance, because you are in a template and the exception is thrown by something dependent on one or more template arguments, such as in this case. Note that here, there is the dynamic allocation of template argument T in the try expression. His catch assumes that only an out of memory exception can be thrown (since he is always calling Err_OutOfMemory.Raise()). Realistically, however, any type of exception can be thrown. This is because the constructor call on one of the array elements may throw an exception for any reason. You don't know what types are possible (and generally shouldn't care) since that information is dependent on T. Such an error should probably still be caught, partially handled (maybe for logging, releasing things not accounted for by RAII, etc.), and then probably rethrown. Using ... in a catch statement is really the best way to handle such a situation.