Message c++std-env-360
ANSI DOC NO: X3J16/93-0070
ISO DOC NO: WG21/N0277
May 1993
Editor's Note:
This image is an ASCII char-set reduction of the paper
provided in the pre-Munich mailing.
C++ Implementation Limits
-------------------------
Third Proposal
Paul Stone
Perennial
paul@peren.com
Table of Contents
-----------------
Introduction
Abstract
Proposed Wording
Implications and Discussion
Table of Recommended Minima
Glossary
Acknowledgements
References
Introduction
------------
This third proposal on Implementation Limits is a compromise
proposal that developed at the Portland meeting as the result of
much debate, discussion, and polling. We believe that this
proposal is significantly more popular than the previous.
This proposal is an intentional departure from requiring "hard
numbers" for translation limits such as in ISO C 9899. As an
important historical note, the "Boston Proposal" of Translation
Limits, per 92-0101R, was rejected by straw votes at the Portland
meeting primarily because it specified required values for the
minima. The actual values selected were shown by straw vote to
not be at issue, however.
Abstract
--------
ANSI/ISO C specified translation limits for C implementations.
The goal was to allow reasonably large portable programs to be
written, without placing excessive burdens on reasonably small
implementations. C++, by design, attempts to be "as close to C
as possible, but no closer". This proposal strives to
harmoniously address these concerns.
===============================================================
Proposed Wording for Committee Vote
-----------------------------------
1. Add a new section to the Draft (near chapter 1)
on Implementation Limits containing the following text:
1.1. The values for the implementation limit entities listed
in the following Glossary are "implementation-defined".
However,
1.1.1. Where appropriate, an implementation may specify
the value of an entity as NO_FIXED_LIMIT.
1.1.2. For compatibility with ISO C, an implementation
shall meet or exceed the requirements stated in
ISO C 5.2.4.1 Translation Limits.
2. Add an Annex A (informative),
Recommended Minima for Implementation Limits:
2.1. It is recommended that an implementation meet or
exceed each of the following values for implementation
limit entities.
2.2. Table of Recommended Minima for Implementation Limits
===============================================================
Implications and Discussion
---------------------------
1.1. The values for the implementation limit entities listed
in the following Glossary are "implementation-defined".
>From WP 1.4 Definitions and Terms, this means that "each
implementation shall document", in this case, what the limits
are for each entity for each equipment configuration.
The use of "implementation-defined" is a significant departure
from the previous proposal. For one, the C standard, and the
previous proposal, focused on required minimum, whereas this
proposal, by virtue of specifying the entities as implementation-
defined, implies that the implementor will document her maximum
in each case. Secondly, there is no restriction on the values
an implementation may choose for an entity, other than being
positive integers.
1.1.1. Where appropriate, an implementation may specify
the value of an entity as NO_FIXED_LIMIT.
This allowance serves a few purposes where applicable.
o It is much more descriptive of the implementation than
a hardcoded minimal value.
o The implementor can apply NO_FIXED_LIMIT across all the
platforms and configurations where it applies. This
alleviates much of the documentation effort for such
implementation-defined entities.
o The addition of resources indicates an increase in the
empirical limit. In other words, an entity specified as
NO_FIXED_LIMIT can be shown empirically to not be fixed.
1.1.2. For compatibility with ISO C, an implementation
shall meet or exceed the requirements stated in
ISO C 5.2.4.1 Translation Limits.
The above statement makes it clear that C++ will not allow
gratuitous imcompatibilities with ISO C in this area.
If such a statement is not adopted, it will be necessary
to document said incompatibilities in WP section 19.
2. Add an Annex A (informative),
Recommended Minima for Implementation Limits:
2.1. It is recommended that an implementation meet or
exceed each of the following values for implementation
limit entities.
Note that the annex is informative only, not a requirement
upon implementations or programs. Its usefulness is
o Users need guidelines for program portability.
Programs that are intended to be highly portable
should not exceed the guidelines without further
research.
o This kind of information is difficult to obtain elsewhere.
Even with implementations being required to document the
implementation-defined values for limits, information
on more than one product does not tend to reach the
programmer or manager in the midst of designing or
writing code.
o It helps to broadly define the overall utility of C++.
===============================================================
Table of Recommended Minima for Implementation Limits
-----------------------------------------------------
Legend
------
Item
----
A cardinal number assigned for the entity for reference
purposes.
Name
----
You may notice the temporary introduction of what
look like macro names, ie, NEST_COMPOUNDS, as abbreviations
for each entity. This is only to aid in our discussion,
which may last quite a while. The names need not appear
in the Draft Document. A glossary is attached.
The numbers preceding (leftmost column) are also for the
ease of the reader, but are more subject to change than
the entity names.
ISO C
-----
The third column, "ISO C", holds the value defined for
ISO C 5.2.4.1 Translation Limits. These values are given
for historic reference, are not subject to debate,
(at least not within X3J16/WG21) and may not actually
have to appear in the Draft Document.
ISO C++
-------
The fourth column, "ISO C++", lists the recommended values
for separately-tested implementation limits.
Other notes about the table:
The first three entities were treated as one limit by ISO C.
Table of Recommended Minima for Implementation Limits
-----------------------------------------------------
Item Name ISO C ISO C++
-- ---------------------- ----- -------
01 NEST_COMPOUNDS 15 256
02 NEST_ITERATIONS 15 256
03 NEST_SELECTIONS 15 256
04 NEST_CONDITIONAL_INCLUSION 8 256
05 DECL_PTR_ADR_FNC 12 256
06 NEST_PAREN_DECL 31 256
07 NEST_PAREN_EXPR 32 256
08 SIGNIFICANT_INTERNAL 31 1024
09 SIGNIFICANT_EXTERNAL 6 1024
10 EXTERNAL_IDENTIFIERS 511 65536
11 BLOCK_IDENTIFIERS 127 512
12 MACRO_IDENTIFIERS 1024 65536
13 FUNCTION_PARAMETERS 31 256
14 FUNCTION_ARGUMENTS 31 256
15 MACRO_PARAMETERS 31 256
16 MACRO_ARGUMENTS 31 256
17 LINE_LENGTH 509 65536
18 LITERAL_LENGTH 509 65536
19 OBJECT_SIZE 32767 262144
20 NEST_INCLUDES 8 256
21 CASE_LABELS 257 257
22 STRUCT_MEMBERS 127 16384
23 ENUM_CONSTANTS 127 4096
24 NEST_STRUCTS 15 256
25 AT_EXIT_FUNCTIONS 32 2048
C++-specific limits:
Item Name ISO C ISO C++
-- ---------------------- ----- -------
26 ALL_BASES - 16384
27 DIRECT_BASE_CLASSES - 1024
28 NEST_CLASSES - 256
29 BASE_CLASS_MEMBERS - 4096
30 CLASS_MEMBERS - 16384
31 ABSTRACT_FUNCTIONS - 4096
32 CONVERSION_FUNCTIONS - 1024
33 OVERLOADED_FUNCTIONS - 1024
34 OVERLOADED_CONSTRUCTORS - 1024
35 VIRTUAL_FUNCTIONS - 1024
36 NON_VIRTUAL_FUNCTIONS - 1024
37 VIRTUAL_BASE_SUBOBJECTS - 1024
38 STATIC_MEMBERS - 1024
39 FRIENDS - 4096
40 ACCESS_DECLARATIONS - 4096
41 MEM_INITIALIZERS - 32768
42 SCOPE_QUALIFIERS - 4096
43 NEST_EXTERNS - 1024
44 TEMPLATE_ARGUMENTS - 256
45 HANDLERS_PER_TRY_BLOCK - 256
46 EXCEPTION_SPECS - 256
Glossary of Implementation Limit Entities
-----------------------------------------
NEST_COMPOUNDS
Nesting levels of compound statements.
Note: NEST_COMPOUNDS, NEST_ITERATIONS & NEST_SELECTIONS
entities were treated as one limit by ISO C.
NEST_ITERATIONS
Nesting levels of iteration control structures.
NEST_SELECTIONS
Nesting levels of selection control structures.
NEST_CONDITIONAL_INCLUSION
Nesting levels of conditional inclusion.
DECL_PTR_ADR_FNC
Pointer, array, and function declarators
(in any combinations) modifying an arithmetic,
a structure, a union, or an incomplete type
in a declaration.
NEST_PAREN_DECL
Nesting levels of parenthesised declarators within
a full declarator.
NEST_PAREN_EXPR
Nesting levels of parenthesised expressions within
a full expression.
SIGNIFICANT_INTERNAL
Significant initial characters in an internal identifier
or macro name.
SIGNIFICANT_EXTERNAL
Significant initial characters in an external identifier.
EXTERNAL_IDENTIFIERS
External identifiers in one translation unit.
BLOCK_IDENTIFIERS
Identifiers with block scope declared in one block.
MACRO_IDENTIFIERS
Macro identifiers simultaneously defined in one
translation unit.
FUNCTION_PARAMETERS
Parameters in one function definition.
FUNCTION_ARGUMENTS
Arguments in one function call.
MACRO_PARAMETERS
Parameters in one macro definition.
MACRO_ARGUMENTS
Arguments in one macro invocation.
LINE_LENGTH
Characters in a logical source line.
LITERAL_LENGTH
Characters in a character string literal or wide string
literal (after concatenation).
OBJECT_SIZE
Bytes in an object (in a hosted environment only).
NEST_INCLUDES
Nesting levels for #included files.
CASE_LABELS
Case labels for a switch statement (excluding those
for any nested switch statements).
STRUCT_MEMBERS
Data members in a single structure or union.
ENUM_CONSTANTS
Enumeration constants in a single enumeration.
NEST_STRUCTS
Levels of nested structure or union definitions in a
single struct-declaration-list.
AT_EXIT_FUNCTIONS
Functions registered by atexit().
See ISO C 9899, 7.10.4.2.
Note: This is a runtime, rather than translation, limit.
- - - - - - - - - -
C++-specific limits:
ALL_BASES
Direct and indirect base classes
(count of edges in the inheritance graph).
DIRECT_BASE_CLASSES
Direct base classes per class.
NEST_CLASSES
Depth of nested class definitions, ie,
class S1 { class S2 { class S3 { int i; }; }; };
Note: NEST_CLASSES may be redundant with NEST_STRUCTS.
BASE_CLASS_MEMBERS
Non-static base class members in a single class object.
CLASS_MEMBERS
Non-static class members in a single class object.
Includes the base class members for derived classes.
Excludes compiler-generated members.
ABSTRACT_FUNCTIONS
Abstract functions in one class.
CONVERSION_FUNCTIONS
Type conversions `operator T()' in one class.
OVERLOADED_FUNCTIONS
Overloaded functions for a given name.
OVERLOADED_CONSTRUCTORS
Overloaded constructors in one class.
VIRTUAL_FUNCTIONS
Virtual functions accessible in a given class, including
pure-virtuals not redefined.
NON_VIRTUAL_FUNCTIONS
Non-virtual functions accessible in a given class,
including automatically generated functions, but
excluding constructors, destructors, operator new/delete,
and static function members.
VIRTUAL_BASE_SUBOBJECTS
Virtual base subobjects per class object.
STATIC_MEMBERS
Static members of one class.
FRIENDS
Friend declarations in one class.
ACCESS_DECLARATIONS
Access control declarations in one class.
MEM_INITIALIZERS
mem-initializers. Initializations of base classes
or members in a constructor definition, e.g.,
T::T() : a(1), b(2), ... { }
SCOPE_QUALIFIERS
Scope qualifications of one identifier, e.g.,
BASE1::BASE2::BASE3::id
NEST_EXTERNS
``extern "lang" { }'' nesting levels.
TEMPLATE_ARGUMENTS
Template arguments in a template declaration.
HANDLERS_PER_TRY_BLOCK
Handlers per try block.
EXCEPTION_SPECS
Throw specifications on a single function declaration;
that is, the number of type-id's in the type-id-list
of an exception-specification
Acknowledgements
----------------
I would like to thank, without implying endorsement or
editorial liability, the following individuals:
Paul Kohlmiller for the first draft.
Steve Clamage for relentless, often constructive, criticism.
Daniel Edelson for numerous proofs and additions.
Dag Br ck for his many suggestions.
Roland Hartinger for NO_FIXED_LIMIT, and other ideas.
Steve Rumsby for initiating discussions in the UK.
Bjarne Stroustrup for important insights and values.
Jerry Schwarz for suggesting the Annex.
Laura Yaker and Bruce Cohen for clarifications.
Pete Becker and Martin O'Riordan for a DOS perspective.
Anyone else inadvertantly unmentioned.
===============================================================
References
----------
1. ISO C Standard, ISO/IEC 9899, Section 5.2.4.1, aka
ANSI C X3.159-1989, Section 2.2.4.1.
2. Minutes of X3J16 Dallas meeting, X3J16/91-0136, pg 16-18.
Sets mandate for inclusion of translation limits.
3. The "Boston Proposal" of Translation Limits, 92-0101R.
4. Minutes of X3J16/WG21 Boston meeting, Nov `92. Both straw
and formal votes were taken (and formal vote reconsidered).
5. "The Need for Translation Limits", 93-0011, Paul Stone,
in rebuttal to unabridged "Why Translation Limits?",
92-0134, by Steve Clamage.
6. Email traffic on env reflector, beginning with
x3j16-env-289.
7. "Translation Quantities in C++", 93-0030, Dag Br ck.
8. Minutes of X3J16/WG21 Portland meeting, March 1993,
part 2 of 4, c++std-all-455, 5.4 Environments Group.
-end-