Conference turris::c_plus_plus

3565.0. "Problem with templates in CXX560T03" by NNTPD::"[email protected]" (Fran�ois Vorburger @RLE) Mon May 12 1997 09:11

  Hello,

  recently I sent CXX560T03 to a customer to fix a problem.
  This new FT version fixed the problem but they got a new one. They are
working
  on DUNIX V4.0A. Here's the description.

--------
The template instantiation still has a severe problem. We linked our product
and had lots of undefined template symbols in our libraries.

As written in the manual we produce the libraries as shared libraries, while
we compile our files with the -Hf option to force immediate instantiation.
Then we link the library together with all objects in the repository.
So far so good.

Now I found out that in the repository the file xxx.req contains the members
that are really needed.

E.g:
cat List__T18AUPRUL_CONDITION_T.req

__ct__27List__T18AUPRUL_CONDITION_TXRC27List__T18AUPRUL_CONDITION_T
__dt__27List__T18AUPRUL_CONDITION_TXv
__vc__27List__T18AUPRUL_CONDITION_TXUi
getAt__27List__T18AUPRUL_CONDITION_TXi

which obviously means that the compiler needs the copy constructor, the 
destructor, the operator[] and the getAt Function.

Now the bad thing is that this file is deleted as soon as the next object
in the same library requires the same template.

E.g. 
A.cxx has code like  
List<AUPRUL_CONDITION_T> l; ...

B.cxx has code like
void f(List<AUPRUL_CONDITION_T> l)
{
...
}

So first A.cxx is compiled, which produces a List__T18AUPRUL_CONDITION_T.req 
containing the default constructor.
Then B.cxx is compiled , which produces a List__T18AUPRUL_CONDITION_T.req 
containing the copy constructor BUT NOT the default constructor anymore.

Therefore the code for the default constructor is gone and we have an
unresolved
symbol in the end...

As we have huge amounts of templates a fast solution for this problem would
be appreciated very much.
--------

  Is this a known problem? Can a fix be expected for V5.6?

  Thanks in advance for any infos.

  Regards,
  Fran�ois V.

[Posted by WWW Notes gateway]

How about doing the following (presuming you are using a makefile):

A.cxx: 
       cxx -Hf A.cxx
B.cxx: A.o
       cxx -Hf B.cxx A.o


or you can simulate this on the command line, i.e.:

rm -fr cxx_repository
cxx -Hf A.cxx
cxx -Hf B.cxx A.o

We use this technique in the script that builds the
standard "common instantiation" library.

The customer is compiling a large application with approx. 800 objectfiles
and 400 templates. He doesn't like modifying his makefiles.

He's trying to work like this:
	cxx -c 1.cxx
	cxx -c 2.cxx
	cxx ...
	cxx -c 800.cxx
	cxx -Hf 1.o 2.o ... 800.o

Now the customer wants to know, if this problem will be fixed in the final
version.

Fran�ois
[Posted by WWW Notes gateway]

This needs more investigation.  We're looking at it.

This problem also occurred with DEC C++ releases prior to
V5.6.  The problem has been fixed in V6.0.