This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: suggested --enable-concept-checks
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: suggested --enable-concept-checks
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Wed, 25 Apr 2001 07:35:19 -0400
- References: <20010420223255.A18157@disaster.jaj.com>
On Fri, Apr 20, 2001 at 10:32:55PM -0400, Phil Edwards wrote:
> Enabling the switch will cause a horrible linker mess the first time you
> try to link anything. That's because the library is missing 253 template
> symbols that would otherwise be automatically instantiated. I'm trying
> to come up with a way of handling those (easy) that doesn't suck (not easy).
>
> Okay to apply to trunk, once I get the symbol problem solved?
To date I only have two solutions. Both work, both suck, but they in
different ways.
Solution #1: Semi-automatically create a source file with explicit
instantiations of all 253 symbols. This file gets built and linked in just
like anything else in the src directory. Any additional use of a concept
check which hasn't been used before in the same exact form will require,
on the average, another five or six instantiations added to this file.
The person adding the concept-check call will have to build with
--enable-debug[*] and link a trivial program, and then add instantiations
based on the error messages from the linker. Basically, do what some
compilers do for templates, but by hand. (And probably with the help of
a script.)
[*] to disable inlining, insuring that all C-C functions are referenced.
Solution #2: The 253 symbols are caused by an initial set of about three
dozen, used by the checks directly. The checks then use other checks
themselves, etc, etc; 253 brings us to closure. Solution 2 is explicitly
instantiating those 30-odd symbols in their own source file, which is then
compiled with -fimplicit-templates. (This is actually what I did to
discover the count of 253 above.)
The big win for #2 is that the compiler does all the slogwork; future
maintainence happens largely automatically. The loss is that we have
another pair of special rules in src/Makefile.am to override the compiler
options, like we do with strstream.cc already. Maintaining exceptional
rules is its own pain.
Opinions? I'd like to settle this and get the changes out of my local tree,
so I can move on to other things and stop cvs complaining about conflicts
in configure. :-)
Phil
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.