public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: peterho@ned.dem.csiro.au To: gcc-gnats@gcc.gnu.org Subject: c++/3575: Unnecessary template expansion when explicit function present. Date: Thu, 05 Jul 2001 13:26:00 -0000 [thread overview] Message-ID: <20010705202102.14109.qmail@sourceware.cygnus.com> (raw) >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
next reply other threads:[~2001-07-05 13:26 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-07-05 13:26 peterho [this message] 2001-07-08 9:09 nathan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20010705202102.14109.qmail@sourceware.cygnus.com \ --to=peterho@ned.dem.csiro.au \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).