template-depth

[Gabriel Dos Reis]

Mike Stump <mrs@windriver.com> writes:

| > To: Mike Stump <mrs@windriver.com>
| > Cc: gcc-patches@gcc.gnu.org
| > From: Gabriel Dos Reis <gdr@codesourcery.com>
| > Date: 28 Dec 2000 19:21:13 +0100
| 
| > Mike Stump <mrs@windriver.com> writes:
| 
| > | I have a user that reported that the library uses 14 levels all by
| > | itself in their code, leaving them with 3 levels for the application.
| 
| > That is odd.  Exactly which components of the library are faulting?
| 
| I didn't investigate.  I already have seen problems like it over and
| over again, over a period spanning years.  Always in something like a
| stack of queued maps of lists or some such.  Fairly trivial to see how
| that will run out fast.  Ok, I exaggerate, I usually only see maps
| composited with one other type, but even this runs down a few levels.

Well, now I no longer understand exactly what your concerns are as far
as the library is concerned.  You reported

# I have a user that reported that the library uses 14 levels all by
# itself in their code, leaving them with 3 levels for the application.

from which I (mis?) understood that a component of the library is
being silly.  Hence my answer.  Now, your message seems to imply that
your user is writing a rather convoluted badly nested template
specializations from the library leading to 14 nesting levels.
For that, my first answer would be: tell him/her to use
-ftemplate-depth to accomodate his program.
But I'm not opposed to increasing the default template-depth value
once the isssues are clearly stated and understood.


[...]

| > I'm not asking that for a rhetorical purpose; before we bindly
| > increase template instantiation depth here and there, we need to
| > understand where the library is consuming to much template nesting
| > levels
| 
| I disagree.  This is like saying that something is blowing out 31
| significant symbols in external identifiers.

I disagree: the issue are completely different.  For symbols, we know
that the length is always finite but one can't reasonably assume an
upper bound.  

For template nesting, there is no guarantee about the finitess of the
nesting level at compile time.  So we need to put an arbitrary upper
bound which can be increased (or decreased) thanks to an appropriate
switch.  Exactly what that upper bound should be can be a matter of
debate, but I can't accept a statement along the lines "the library is
already using 14 levels for its own use" with not further evidence.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com