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-