• Welcome to Computer Association of SIUE - Forums.
 

templates

Started by Chris Lerner, 2003-10-11T21:51:33-05:00 (Saturday)

Previous topic - Next topic

Chris Lerner

I have been trying to do a template in c++ with an implemination file. but I get linking errors with the constructor and deconstructor andy ideas on how to fix this?

Peter Motyka

Posting/pasting your linking errors would be helpful.
SIUE CS Alumni 2002
Grad Student, Regis University
Senior Engineer, Ping Identity
http://motyka.org

Guest

------ Build started: Project: pro3, Configuration: Debug Win32 ------

Compiling...
stack.cpp
Linking...
evaluate.obj : error LNK2019: unresolved external symbol "public: __thiscall stack::stack(void)" (??0?$stack@N@@QAE@XZ) referenced in function _main
Debug/pro3.exe : fatal error LNK1120: 1 unresolved externals

Build log was saved at "file://c:\Documents and Settings\Chris Lerner\My Documents\Visual Studio Projects\cs240pro3\pro3\Debug\BuildLog.htm"
pro3 - 2 error(s), 0 warning(s)


---------------------- Done ----------------------

    Build: 0 succeeded, 1 failed, 0 skipped


Is the error I am getting. It all compiles fine and the code appears to be correct to. What else can cause this?

Geoff Schreiber

Have a look at this: http://support.microsoft.com/default.aspx?scid=kb;en-us;239436

The reference at the bottom may be of help as well.
~~~~~~~~~~~~~~~~~~~
Geoff Schreiber
Project Engineer
FASTechnology Group

R. Andrew Lamonica

I remember having this bug.  I would have thought they would fix it for VS.NET, but the BUG report says it applies to .NET 2002 and 2003 so I guess they must not care about it enough to fix it.  

Frankly, aside from the STL types I don’t use templates all that much. Of course I use Java and C# more than C++ and they both have standardized runtime type checking plus a root Object type so templates are unnecessary unless you are going for speed like MS will be in the new .NET release.

http://msdn.microsoft.com/msdnmag/issues/03/09/net/default.aspx

Guest

If you put your implementation into your header file (also known as inlining) the errors should go away.  Another solution would be to change your include in you driver file from:
include "blahblah.h";
to:
include "blahblah.cpp";   //assuming implementation and header are named the same

I know there must exist a better fix but I haven't found it yet.

HM

R. Andrew Lamonica

The previous author is correct in saying that putting the implementation code in the header file will fix your link errors.  I would have mentioned that before, but I did not read carefully and assumed that the answer was already posted. In VS6 I tried the #include a cpp file solution and it never seemed to work entirely, so I would suggest you move the code or compile with gcc unless VS.NET allows for a better solution.

It should be noted, however, that putting you implementation into a header file is not called inlining.  Inlining (sometimes called â€Ã...“inline expansionâ€Ã,) is when a function call is replaced with the function itself at compile time.  This is useful when you call a very simple function a lot in a program and the call-stack creation/deletion overhead might significantly increase the program execution time.  One neat thing about OOP in C++ (which probably led to this confusion) is that any (non-recursive) methods implemented inside the declaration of a C++ class are automatically inlined.  This is why experienced OO programmers always either put the code for accessors in the class declaration or use the keyword â€Ã...“inlineâ€Ã, when writing them.  Because accessors do very little and need to do it very fast it is worth it to replace a call to them with their code.  In fact, for accessors the code (assembly) is often smaller then the code required for a method call.  

The code bellow shows both ways to inline.  In the compiled result, main() should make no function calls.  

However, it is important to note that most modern compilers do a cost-benefit analysis to double check that the programmer used inline correctly.  This cost-benefit analysis is usually good at avoiding inlining of functions that should not be.  For example, in older compilers the inlining of a recursive function will generate an error because you cannot indefinatly expand the code, where as in new compilers the inline will most likely just be ignored because the space requirements will exceed a threshold.


[img align=left]http://solar.cs.siue.edu/~lamonica/inline.jpg[/img]