gidon
asked on
Templates and Exceptions MIXED
I want to write a template class that one of it's methods
contain try - except (Win32 exceptions) statment.
the Bc5.02 compiler issues a warning "inline functions
cant contain try statment".
so I tryed to move this method to cpp, resulted in
linker error "Unresolved external" (in the files using
the template)
I think that templates has to be in header files only
Is that true? also I have to get rid of the warning
cause I'm afraid it will destroy the precompiled headers.
Templates and Exceptions Don't Mix ?
contain try - except (Win32 exceptions) statment.
the Bc5.02 compiler issues a warning "inline functions
cant contain try statment".
so I tryed to move this method to cpp, resulted in
linker error "Unresolved external" (in the files using
the template)
I think that templates has to be in header files only
Is that true? also I have to get rid of the warning
cause I'm afraid it will destroy the precompiled headers.
Templates and Exceptions Don't Mix ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The problem is that in order to instantiate the template, the compiler has to see the definition code.
Here's an alternative suggestion:
In one source file force the instantiation of the template using:
template MyTemplateClass<args>;
In other source files prevent the instantiation of the template using:
extern template MyTemplateClass<args>;
Let the linker sort out the references.
Here's an alternative suggestion:
In one source file force the instantiation of the template using:
template MyTemplateClass<args>;
In other source files prevent the instantiation of the template using:
extern template MyTemplateClass<args>;
Let the linker sort out the references.
The two approaches should produce the same results. (Notice the "should" always best to hedge one's bets when at the forefront of C++ technology.) The method I proposed is what the standard template library (STL) so it is likely to work well. (Although if you told me if has the side effect of causing massive power outages in Easter Europe, I wouldn't be surprised. This stuff can be a little unpredicatable.)
Premature posting... Brain fart... Sorry...
However, in your method, there will actually multiple definitions of the class methods which the linker will later merge. Same result, different way to get there.
However, in your method, there will actually multiple definitions of the class methods which the linker will later merge. Same result, different way to get there.
>> which the linker will later merge
Hopefully. I'm not sure that is guaranteed by the standard.
However, your approach will problably end up working the same. This is implimentation defined of course, but from what I've heard (I believe--I may be making this up.) it is common to just instanciate every template that is needed in a translation unit. Then let the linker sort things out. This is because the output of translation unit (obj) could be linked with different translation units at different times. Thus an algorithm that looks at compile time at the things that it links with to decide if a procedure should be instanciated (or if it was already instanciated in anther translation unit) will possible fail if you link with something new.
Hopefully. I'm not sure that is guaranteed by the standard.
However, your approach will problably end up working the same. This is implimentation defined of course, but from what I've heard (I believe--I may be making this up.) it is common to just instanciate every template that is needed in a translation unit. Then let the linker sort things out. This is because the output of translation unit (obj) could be linked with different translation units at different times. Thus an algorithm that looks at compile time at the things that it links with to decide if a procedure should be instanciated (or if it was already instanciated in anther translation unit) will possible fail if you link with something new.
>> it is common to just instanciate every template that is needed in a translation unit.
Yup. That's exactly what "my" approach tries to avoid.
Yup. That's exactly what "my" approach tries to avoid.
You missunderstand me. My point is that no matter what you do. The compiler will instanciate every template in needs in that translation unit, even if it can find out that the template has already been instanciated for the project. In other words, if you provide the compiler with the declation, but not the definition, it will seek out the definition anyways.
I don't know how true that is....
I don't know how true that is....
Bzzzzt... Wrong! Thank you for participating :-)
Most current compilers will not instantiate using the method I outlined above. It allows putting pre-instantiated templates in libraries.
Most current compilers will not instantiate using the method I outlined above. It allows putting pre-instantiated templates in libraries.
template<T>
class SomeClass
{
T SomeFunction(T i);
}
Template<T>
T SomeClass::SomeFunction(T i)
{
cout << i;
return i;
}