Mandalika's scratchpad [ Work blog @Oracle | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14  07.14  09.14  10.14  11.14  12.14  01.15  02.15  03.15  04.15  06.15  09.15  12.15  01.16  03.16  04.16  05.16  06.16  07.16  08.16  09.16  12.16  01.17  02.17  03.17  04.17  06.17  07.17  08.17  09.17  10.17  12.17  01.18  02.18  03.18  04.18  05.18  06.18  07.18  08.18  09.18  11.18  12.18  01.19  02.19  05.19  06.19  08.19  10.19  11.19  05.20  10.20  11.20  12.20  09.21  11.21  12.22 


Friday, May 20, 2005
 
Behavior of Sun C++ Compiler While Compiling Templates

When the C++ compiler finds a template declaration in a header (.h) file, the compiler needs the definition of the template to allow compilations to proceed faster (on average), because template definitions that are not used don't need to be processed. Hence the compiler automatically searches for a .cc or .C or .cpp etc file with the same name. If such a file exists, it is automatically included in the current compilation. Note that it is not separately compiled. This compiler behavior means that some source code organizations won't work with our compiler.

For example, the compilation of the following driver program fails with Multiple declaration of a variable. The driver program calls a function template multiply, which in turn calls another function template
Array. The definitions of multiply and Array are in different source (.cpp) files. Since there is a dependency between Array and multiply function templates, the compiler tries to include both source files into the compilation unit and hence the failure.

%cat array.h
#ifndef _ARRAY_H_
#define _ARRAY_H_

const int ArraySize = 20;
template <class Type> class Array {

private:
Type* data;
int size;
public:
Array(int sz=ArraySize);
int GetSize();
};

#endif // _ARRAY_H_

% cat array.cpp
static const char file_id [ ] = "$Header: array.cpp 1 04/05/05 1:35p Giri $";

#include "array.h"

template <class Type> Array<Type>::Array(int sz) {
size = sz;
data = new Type[size];
}

template <class Type> int Array<Type>::GetSize() {
return size;
}

% cat multiply.h
#include "array.h"
int AnyNumber;

template <class Number>

Number multiply(Number original);

% cat multiply.cpp
static const char file_id [ ] = "$Header: multiply.cpp 1 04/05/05 1:35p Giri $" ;

template <class Number>

Number multiply( Number original ) {
Array<int> IntArray;
int size = IntArray.GetSize();

return (size * original);
}

% cat driver.cpp
#include "multiply.h"
#include <stdio.h>

int main( ) {
printf("\n ** %d **\n", multiply(50));
}

% CC -o driver driver.cpp
"array.cpp", line 1: Error: file_id is initialized twice.
"array.cpp", line 1: Error: Multiple declaration for file_id.
2 Error(s) detected.


% truss -f -o truss.log CC -o driver driver.cpp
% cat truss.log | egrep "multiply|array"
24813: open("multiply.h", O_RDONLY) = 6
24813: open("multiply.cpp", O_RDONLY) = 5
24813: open("array.h", O_RDONLY) = 6
24813: open("array.cpp", O_RDONLY) = 5


Note that both multiply.cpp and array.cpp are syntactically correct; but the problem can be seen only during the compilation of multiply routine. The above mentioned behavior of the compiler has been documented in Sun C++ User's Guide, Compiling Templates chapter.

Sun C++ User's Guide suggests employing a definitions separate template compilation model. This model can better be described as follows: If file x.h has any template declarations, a file called x.cc or x.C or x.cpp, etc must contain definitions of those templates, and nothing else; no #include directives, no definitions of anything other than the templates declared in x.h.

To comply with the definitions separate template compilation model, array.cpp and multiply.cpp files can be modified as follows:

% cat array.cpp
template <class Type> Array<Type>::Array(int sz) {
size = sz;
data = new Type[size];
}

template <class Type> int Array<Type>::GetSize() {
return size;
}

% cat multiply.cpp

template <class Number>

Number multiply( Number original ) {
Array<int> IntArray;
int size = IntArray.GetSize();

return (size * original);
}

Now the compilation of driver.cpp should succeed, due to the implementation of definitions separate template compilation model.

% CC -o driver driver.cpp
%./driver

** 1000 **

As we can see, the compilation succeeds and the driver program prints the expected result on console.

If the source code organization does not follow this model, you can use the compiler option -template=no%extdef. This option tells the compiler not to look for template definitions in associated files. With this compiler option, the
compilation succeeds, but the linking may fail. For example, compiling the original source files with -template=no%extdef compiler option, fails during linking phase with the following error:

% CC -o driver -template=no%extdef driver.cpp
Undefined first referenced
symbol in file
__type_0 multiply(__type_0) driver.o
ld: fatal: Symbol referencing errors. No output written to driver

Moral of the story: rely on "definitions separate template compilation" model as suggested by the documentation, but not on temporary workarounds.

If source code changes are not feasible, carefully guarding the common interfaces, variable names etc., with #ifdef directives will do the trick and the compilation and eventually linking succeds.

Acknowledgements:
Steve Clamage of Sun Microsystems


Comments: Post a Comment



<< Home


2004-2019 

This page is powered by Blogger. Isn't yours?