Re: c++/3575: Unnecessary template expansion when explicit function present.

Re: c++/3575: Unnecessary template expansion when explicit function present.

[nathan]

Synopsis: Unnecessary template expansion when explicit function present.

State-Changed-From-To: open->closed
State-Changed-By: nathan
State-Changed-When: Sun Jul  8 09:09:19 2001
State-Changed-Why:
    The current release (3.0), produces an executable which
    outputs,
    Template
    NON-Template
    which is I think what you expect.
    
    btw, on compilation with -fexternal-templates, it says
    nathan@uha:8>g++ 3575.C -fexternal-templates
    cc1plus: warning: -fexternal-templates is deprecated, please see the documentation for details
    

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3575&database=gcc

c++/3575: Unnecessary template expansion when explicit function present.

[peterho]

>Number:         3575
>Category:       c++
>Synopsis:       Unnecessary template expansion when explicit function present.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 05 13:26:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     peterho@ned.dem.csiro.au
>Release:        unknown-1.0
>Organization:
>Environment:
RedHat Linux 7.1
g++ version 2.96-85
>Description:
The call to INPUT(in, (const char *) "name") in main
triggers the template INPUT( blah, T& ) instead of
INPUT( blah, const char *).

Please refrain from "don't use external-templates" response.
There are good reasons for using this template strategy
in this app.

The repo model is no use in the real app, which is large, 
and used the strategy of expanding templates a the mainline compile
time. The SGI strategy also works, as does the "ptr"
template repository method, provided it is possible to specify
the repository directory.
 
The source is spread across many directories, and the
libraries also reside in different trees. All have templates.

The repo model does not seem expand templates that arise from 
lower level library code, or at least, making it do so seems
onerous, and violates modularity.

Ie. template "here" uses template "there" which uses another
second tier template "elsewhere". Explicit expansion using phony
forward reference does not seem to generate code for the second 
tier expansion "elsewhere". The solution of forward ref'ing all
templates "here" that might be generated "there" and elsewhere
requires knowledge of the internal structure of the lower level 
library, which violates modularity. It would also result 
in mul'defs with absolute certainty unless everybody knows 
what everybody else is expanding. So, that is not acceptable.

An alternative is to force all libraries to close by
compiling with a fake mainline and forcing the rpo's to
do their thing, layer by layer, closing each library in 
turn.

That works up to a point BUT  

If there are circular dependencies (not in header files, 
but in implementation .cc files) then the repo strategy results 
in an infinite loop generated by pairs of files triggering recompiles
of each other. This circular dependency is not bad
design. All it requires is for a template container to 
ref it's template contents, and for the contents to ref. 
their container (plus some other conditions)! 
Have not put my finger on the EXACT circumstance, 
but frankly, I have to give up.

BTW, the same problem exists in the current version.
>How-To-Repeat:
compile attached file with
g++ -fexternal-templates
>Fix:
None, tried many obvious re-orderings of definitions etc.

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="WRONG.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="WRONG.cc"

CiNpbmNsdWRlIDxpb3N0cmVhbS5oPgoKCi8vIFJlYWQgb25lIGlucHV0IHZhbHVlIGZyb20gc3Ry
ZWFtIGFuZCBjaGVjayBmb3IgYW4gZXJyb3IuCnRlbXBsYXRlIDxjbGFzcyBUPgppbmxpbmUgaW50
CklOUFVUKGlzdHJlYW0gJmluLCBUICZ2YWwpCnsKICAgaW4gPj4gdmFsOwogICBjb3V0IDw8ICJU
ZW1wbGF0ZSIgPDwgZW5kbDsKICAgcmV0dXJuIDE7Cn0KCi8vIE92ZXJyaWRlIGZvciBjb25zdCBj
aGFyIConcwovLyB0ZW1wbGF0ZSA8Y2xhc3MgVD4KaW5saW5lIGludApJTlBVVChpc3RyZWFtICZp
biwgY29uc3QgY2hhciAqc3RyaW5nKQp7CiAgIGNvdXQgPDwgIk5PTi1UZW1wbGF0ZSIgPDwgZW5k
bDsKICAgcmV0dXJuIDE7Cn0KCgppbnQgbWFpbigpCnsKICAgaXN0cmVhbSBpbjsKICAgaW50IHBv
aXU7CiAgIElOUFVUKGluLCBwb2l1KTsKICAgSU5QVVQoaW4sIChjb25zdCBjaGFyICopICJuYW1l
Iik7Cn0K