ISO/ IEC JTC1/SC22/WG21 N0823


  Accredited Standards Committee X3       Doc No: X3J16/95-0223  WG21/N0823
  Information Processing Systems          Date:   December 1st, 1995
  Operating under the procedures of       Project: Programming Language C++
  American National Standards Institute   Ref Doc:
                                          Reply to: Josee Lajoie
                                                    (josee@vnet.ibm.com)
+========================+
| Core WG List of Issues |
+========================+

The issues listed as closed in the version of the Core WG list of issues that
appeared in the Pre-Tokyo mailing (95-0196/N0796) were removed from the
Core WG list of issues and are therefore not listed in this version of the 
list. 

The issues listed as editorial in this version of the list were categorized 
as editorial by the Core WG at the Tokyo meeting and will be handled as 
editorial by the editorial team helping the editor. The issues listed as 
closed in this version of the list were resolved and voted on at the Tokyo 
meeting and the motions from the Tokyo meeting indicate the wording that
will be added to the WP to resolve these issues.


+--------+
| Syntax |
+--------+

5.1 [expr.prim]:
  512: parsing destructors calls
  465: grammar needed to support template function call
  466: grammar needed to support ~int()
5.3 [expr.unary]:
  593: syntax for prefix ++ operator
6.8 [stmt.ambig]
  132: Consistency between "::" and "Class::" in declarations
  424: Must disambiguation update symbol tables?


+-------+
| Core1 |
+-------+

General
-------
1.1 [intro.scope]:
  604: Should the C++ standard talk about features in C++ prior to 1985?
1.7 [intro.compliance]:
  602: Are ill-formed programs with non-required diagnostics really 
       necessary?
1.8 [intro.execution]:
  603: Do the WP constraints prevent multi-threading implementations?
  605: The execution model wrt to sequence points and side-effects needs work

Linkage / ODR
------------- 
3.2 [basic.def.odr]:
  427: When is a diagnostic required when a member function used is not
       defined?
  556: What does "An object is used..." mean?
3.5 [basic.link]:
  526: Linkage of names declared in unnamed namespaces
7.5 [dcl.link]:
   78: Linkage specification and calling protocol
  420: Linkage of C++ entities declared within `extern "C"'
9.6 [class.union]:
  505: Must anonymous unions declared in unnamed namespaces also be static?

new / delete 
------------

3.7.3 [basic.stc.dynamic]:
  546: What is the required behavior for a user allocator?
5.3.4 [expr.new]:
  453: Can operator new be called to allocate storage for temporaries, RTTI
       or exception handling?
5.3.5 [expr.delete]:
  470: Deleting a pointer allocated by a new with placement

Memory Model
------------

3.9 [basic.types]:
  192: Should a typedef be defined for the type with strictest alignment?
5.3.4 [expr.new]:
  577: Are there any requirements on the alignment of the pointer used with
       new with placement?

Object Model
------------

1.6 [intro.object]:
  421: What is a complete object? a sub-object?
3 [basic]:
  460: Definition for the term "variable"
9.6 [class.union]:
  533: Is an anonymous union a type?
12.2 [class.temporary]:
  598: Should a diagnostic be required if an rvalue is used in a 
       ctor-initializer or in a return stmt to initialize a reference?
12.8 [class.copy]:
  536: When can objects be eliminated (optimized away)?

Initialization / Destruction
----------------------------
3.6.2 [basic.start.init]
  613: What is the order of destruction of objects statically initialized?
5.19 [expr.const]:
  610: Is a string literal considered a constant expression for the purpose 
       of non-local static initialization?
12.4 [class.dtor]:
  293: Clarify the meaning of y.~Y
12.6 [class.init]:
  138: When are default ctor default args evaluated for array elements?


+-------+ 
| Core2 |
+-------+

Name Look Up
------------
3.4.2.2 [namespace.qual]:
  612: Qualified name look up and unnamed namespaces
5.1 [expr.prim]:
  433: What is the syntax for explicit destructor calls?
5.2.4 [expr.ref]: 
  452a: How does name look up work after . or -> for namespace names or
        template names?
9.1 [class.name]:
  252: Can the definition of an incomplete class appear in an anonymous 
       union?
9.6 [class.union]:
  105: How can static members which are anon unions be initialized?
  570: Name look up for anonymous union member names need to be better
       described.
10[class.derived]:
  441: In which scope is the base class clause looked up?
10.1 [class.mi]:
  446: Can explicit qualification be used for base class navigation?
15.3 [except.handle]:
  540: How does name look up proceed in a function-try-block?

Preprocessor
------------

16.8 [cpp.predefined]:
  595: Is a macro __STDC_plusplus__ needed?

Lexical conventions
-------------------

2 [lex]:
  606: The description of the compilation model needs work
2.1 [lex.phases]:
  584: May a // comment end with an EOF instead of a newline?
2.9.2 [lex.ccon]:
  607: Definition needed for basic source character set
2.9.3 [lex.fcon]:
  506: Is a program containing a non-representable floating point constant
       ill-formed?

Types / Classes / Unions
------------------------

3.9 [basic.life]:
  608: Is an incompletely-defined object type an object type?
7 [dcl.dcl]:
  213: Should vacuous type declarations be prohibited?
7.1.5 [dcl.type]:
  116: Is "const class X { };" legal?
7.1.5 [dcl.type]:
  564: is 'void f(const a);' well-formed?
7.2 [dcl.enum]:
  503: Better semantics of bitfields of enumeration type needed
9 [class]:
  568: Can a POD class have a static member of type pointer-to-member, ...?
9.6 [class.union]:
  266: Access specifiers in union member list
9.7 [class.bit]:
  571: Is bitfield part of the type?

Declarators
-----------

8.2 [dcl.ambig.res]:
  573: How does 'C()' parses when it appears as the operand of the typeid 
       operator or sizeof operator?
8.3.5 [dcl.fct]:
  567: Can a parameter have type 'T arr[]' where T is incomplete?
8.3.6 [dcl.fct.default] :
  530: Can default arguments appear in out-of-line member function
       definitions?
  531: Is a default argument a context that requires a value?
  586: When do access restrictions apply to default argument names?
9.7 [class.bit]:
   47: enum bitfields - can they be declared with < bits than required?
  267: What does "Nor are there any references to bitfields" mean?
  458: When is an enum bitfield signed / unsigned?
12.6 [class.init]:
  138: When are default ctor default args evaluated for array elements?

Expressions
-----------

5.6 [expr.mul]:
  600: Should the value returned by integer division and remainder be defined
       by the standard?
5.19 [expr.const]:
  537: Can the implementation accept other constant expressions?

Type Conversions / Function Overload Resolution
-----------------------------------------------

4.12 [conv.class]:
  547: Semantics of standard conversion "derived to base" need better
       description
4.13 [conv.bool]:
  601: Should implicit conversion from int to bool be allowed?
5.2.9 [expr.reinterpret.cast]:
  538: Are user-defined conversions invoked as the result of a
       reinterpret_cast?
5.9 [expr.rel]:
  493: Better description of the cv-qualification for the result of a
       relational operator needed
5.16 [expr.cond]:
  496: The cv-qualification of the result of the conditional operator needs 
       better description
5.18 [expr.comma]:
  609: Is "bitfield" an attribute remembered when a bitfield is used as the 
       right operand of a comma operator?
13.3.3.2 [over.ics.rank]:
  599: Are user-defined conversion sequences always ambiguous when the 
       user-defined conversions considered are different?
13.6 [over.built]:
  582: What are the cv-qualifiers for the parameters of a candidate function?
  583: For a candidate built-in operator, must cv-qualifiers of parameters of
       type pointer to member be the same?

Access Specification & Friends
------------------------------

11 [class.access]:
  585: Is access checking performed on the qualified-id of a member 
       declarator?
11.3 [class.access.dcl]:
  388: Access Declarations and qualified ids
11.4 [class.friend]:
  515: How can friend classes use private and protected names?
  532: Is a complete class definition allowed in a friend declaration?


+--------+ 
| Core 3 |
+--------+

Pointer to Members
------------------

5.5 [expr.mptr.oper]:
  488: Can a pointer to a mutable member be used to modify a const class
       object?

RTTI
----

5.2.6 [expr.dynamic.cast]:
  468: How does dynamic_cast to void* work for non-polymorphic types?
  549: Is a dynamic_cast from a private base allowed?

Exception Handling
------------------

15.2 [except.ctor]:
  594: If a constructor throws an exception, in which cases is the storage 
       for the object deallocated?
  611: What happens when an exception is thrown from the destructor of a 
       subobject?
15.3 [except.handle]:
  539: Can one throw a pointer-to-member to a base class and catch it with a 
       handler taking a pointer to a derived class?
  541: Is a function-try-block allowed for the function main?
  542: What exception can a reference to a pointer to base catch?
  587: Can a pointer/reference to an incomplete type appear in a catch
       clause?
  590: With function try blocks, does the caller or callee catches exceptions
       from constructors/destructors called for parms?
  592: Can a type be defined in a catch handler?
15.4 [except.spec]:
  588: How can exception specifications be checked at compile time if the
       class type is incomplete?


+----------------+
| Core Editorial |
+----------------+

3.6.1 [basic.start.main]:
  552: Why is an implementation prohibited from destroying objects with
       automatic storage duration when exit is called?
3.6.2 [basic.start.init]:
  527: When must the initialization of nonlocal objects take place?
3.9 [basic.types]:
  557: The description of the memory model needs fine tuning
3.9.1 [basic.fundamental]:
  553: Clarify: "The representations of integral types shall define values by
       use of a pure binary numeration system."
4.5 [conv.prom]:
  572: How do enum values promote?
5.2.1, 5.2.5, 5.3.1, 5.3.2, 5.7:
  417: Should pointer arithmetic be allowed for pointer-to-abstract classes?
5.2.2 [expr.call]:
  548: Which conversions apply to the postfix-expression in a function call?
5.2.8[expr.static.cast]:
  550: Minor clarifications on the conversions a static_cast can performed
5.2.9 [expr.reinterpret.cast]:
  486: Can a value of enumeration type be converted to pointer type?
  487: Conversions to pointer to member functions need to be changed to allow
       covariant return types
  559: Are pointer-to-derived -> pointer-to-base conversions performed with a
       reinterpret_cast?
  560: Can a reinterpret_cast add cv-qualifiers?
5.3.5 [expr.delete]:
  471: When can an implementation change the value of a delete expression?
5.3.5 [expr.delete]:
   93: Deleting the "current object" (this) in a member function
5.4 [expr.cast]:
  563: Which "inaccessible" conversions are allowed using old style casts?
5.9 [expr.rel]:
  596: What is the result of a relational operator if only one operand is a 
       null pointer?
5.16 [expr.cond]:
  472: lvalue-> rvalue transformation for the operands of the conditional 
       operator needs better description
  497: The conversion applied to operands of the conditional operator of
       class type needs to be better described
8.5 [dcl.init]: 
  476: Can objects with "indeterminate initial value" be referred to?
8.5 [dcl.init]:
  565: fine tuning of the description of type conversions used during
       initialization needed
8.5.3 [dcl.init.ref]:
  566: fine tuning of the description of type conversions used during
       reference initialization needed
11.1 [class.access.spec]:
   22: Must implementations respect access restrictions?
12.1 [class.ctor]:
  576: How do volatile semantics affect the ctor and dtor code?
12.3.1 [class.conv.ctor]:
  562: Is a copy constructor a conversion function?
12.3.2 [class.conv.fct]:
  347: Limitations on declarations of user-defined type-conversions
13.3.1.3 [over.match.user]:
  578: Do cv-qualifiers on the conversion functions considered matter?
13.6 [over.built]:
  579: The declarations for the candidate built-in operators do not reflect
       the constraints described in clause 5
  580: The declaration for builtin ->* does not allow lhs of derived class 
       type and left hand side of base class type
  581: The declarations describing the built-in operators do not take into 
       account operands of enumeration type


+------------------------------------------------------+
| Closed Issues - issues resolved at the Tokyo meeting |
+------------------------------------------------------+

3.6.1 [basic.start.main]:
  551: Must all C++ program defined main?
  462: Calling exit from a destructor for a global variable
3.6.2 [basic.start.init]:
  429: Order of initialization of reference variables
  555: Clarify: order of (static vs dynamic) initialization
3.6.3 [basic.start.term]:
  430: Order of destruction of local static variables
  484: When must objects of static storage duration be destroyed wrt to calls
       to functions registered with atexit?
3.8 [basic.life]
  554: Can the storage in which a const object resides be reused?
3.9 [basic.types]:
  464: Can memcpy be used to copy pointer to members?
4.9 [conv.fpint]:
  455: Should implicit floating->integral conversions be deprecated?
5.2.2 [expr.call]:
  535: Does the initialization of a parameter take place in the caller or in
       the callee?
5.2.3 [expr.type.conv]:
  558: In T(), may T be more than one simple-type-specifier?
5.2.7 [expr.typeid]:
  483: What does a compiler know about type_info if the header isn't
       included?
  588: When is it determined that the operand of typeid is a polymorphic 
       type?
5.2.9 [expr.reinterpret.cast]:
  543: Can volatile be cast away using static_cast or reinterpret_cast?
5.3.4 [expr.new] New
  561: How does initialization proceed when a new expression creates a
       pointer-to-member?
5.3.5 [expr.delete]:
  416: Can a delete expression be of abstract type?
5.4 [expr.cast]:
  545: Which 'static_cast' or 'reinterpret_cast' conversions are performed
       using the old style casts?
5.7 [expr.add];
  597: Should the results of the + or - operators be well-defined if one
       operand is a null pointer and the other is the value 0?
5.9 [expr.rel]:
  513: Are pointer conversions implementation-defined or unspecified?
6.7 [stmt.dcl]:
  524: Exactly when are objects of automatic storage duration destroyed?
7.3.2 [namespace.alias]:
  474: Lookup of namespace names in alias declarations
7.3.3 [namespace.udecl]:
  591: Can a using declaration be applied to a constructor?
7.3.4 [namespace.udir]:
  475: Lookup of namespace names in using directives
8.3.5 [dcl.fct]:
  482: Are cv-qualifiers allowed in a typedef for a function type?
9.2 [class.mem]:
  479: How can typedefs be used to declared member functions?
  569: Is the mapping of members separated by access specifiers 
       implementation-defined or unspecified?
10.1 [class.mi]:
  529: Can two base class subobjects be allocated at the same address?
10.3 [class.virtual]:
  447: When should a class without a final overrider be ill-formed?
  589: Can the return type of an overridding function be incomplete and 
       different from the return type of the base class function?
11.2 [class.access.base]:
  284: Access to base class ctor/dtor
11.4 [class.friend]:
  448: Can '::' be used to declare global functions as friends?
12 [special]:
  575: Can programs explicitly name implicitly-declared special member 
       functions?
12.1 [class.ctor]:
  379: Invoking member functions which are "not inherited"
12.6 [class.init]:
  574: Must const members and reference members be initialized in the 
       ctor-initializer of their owning class? 
12.6.2 [class.base.init]:
  534: Can the members of an anonymous union be named in a ctor-initializer?
  478: Can a union constructor initialize multiple members?
12.8 [class.copy]:
   95: Volatility, copy constructors, and assignment operators
13.2.1.1.1 [over.call.func]:
  451: Description of a call to a member function through a pointer to member
       is missing

=============================================================================
 Chapter 1 - Introduction
--------------------------
Work Group:     Core
Issue Number:   604
Title:          Should the C++ standard talk about features in C++ prior to
                1985?
Section:        1.1 [intro.scope]
Status:         active
Description:
        UK issue 229:
	"Delete the last sentence of 1.1 and Annex C.1.2. This is the first 
	 standard for C++, what happened prior to 1985 is not relevant to 
	 this document."
Resolution:
Requestor:      UK issue 229
Owner:          
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   421
Title:          What is a complete object? a sub-object?
Section:        1.6 [intro.object] Object Model
Status:         active
Description:
	There appears to have been a substantive change in the definition of 
	"sub-object" and "complete object" in the Working Paper.

	Sub-objects used to include only objects representing base classes.
	A complete object used to include all objects (even members) that 
	aren't base class objects of other objects.  Now sub-objects include
	members, and complete objects exclude members.  This introduces a 
	number of unfortunate side-effects in the standard where the 
	definitions are used.  
	3.8 [basic.life] p7:
	"-- the original object was a complete object of type T and the new 
	 object is a complete object of type T (that is, they are not base 
	 class subobjects)."

	5.2.6 [expr.dynamic.cast] p7:
	"If T is ``pointer to cv void'', then the result is a pointer to the 
	 complete object pointed to by v. ...

	 If, in the complete object pointed (referred) to by v, v points 
         (refers) to an public base class sub-object of a T object, ...
	 Otherwise, if the type of the complete object has an unambiguous 
	 public base class of type T, the result is a pointer (reference) to 
	 the T sub-object of the complete object."

	5.2.7 [expr.typeid] p3
	"If the expression is a reference to a polymorphic type, the 
	 type_info for the complete object referred to is the result. ...
	
	 ... Otherwise, the result of the typeid expression is the value that
	 represents the type of the complete object to which the pointer
	 points."
	
	10 [derived] p3
	"3 The order in which the base class subobjects are allocated in the 
	   complete object is unspecified."

         5 A base class subobject might have a layout different from the
           layout of a complete object of the same type.  A base class
           subobject might have a polymorphic behavior of a complete object
           of the same type."

	10.1 [class.mi] p4
	"For each distinct occurrence of a nonvirtual base class in the class 
	 lattice of the most derived class, the complete object shall contain
         a corresponding distinct base class subobject of that type.  For 
	 each distinct base class that is specified virtual, the complete 
	 object shall contain a single base class subobject of that type."

	12.7 [class.cdtor] p3:
	"3 When a virtual function is called directly or indirectly from a
	   constructor (including from its ctor-initializer ) or from a 
	   destructor, the function called is the one defined in the
           constructor or destructor's own class or in one of its bases, but
           not a function overriding it in a class derived from the 
           constructor or destructor's class or overriding it in one of the
           other base classes of the complete object."
 	   ...
	 5 When a dynamic_cast is used in a constructor (including in its
	   ctor-initializer) or in a destructor, or used in a function called
	   (directly or indirectly) from a constructor or destructor, if the 
	   operand of the dynamic_cast refers to the object under 
	   construction or destruction, this object is considered to be a 
	   complete object that has the type of the constructor or 
	   destructor's class.  

	This is also a UK issue: 593.
Proposed Resolution:
	We need to introduce another term in the WP to describe objects that 
	are either member subobject or complete objects.
	It was suggested before that the term "nonbase" object could be used.

	Clark Nelson will provide a paper for the Tokyo meeting (November
        1995).
Resolution:
Requestor:      Neal M Gafter <gafter@mri.com>
Owner:          Clark Nelson (Object Model)
Emails:         edit-195, edit-196
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   602
Title:          Are ill-formed programs with non-required diagnostics really
	        necessary?
Section:        1.7 [intro.compliance]
Status:         active
Description:
	UK issue 9:
	"We believe that current technology now allows many of the 
	 non-required diagnostics to be diagnosed without excessive overhead.
	 For example, the use of & on an object of incomplete type, when the
	 complete type has a user-defined operator&(). We would like to see 
	 diagnostics for such cases."

	At the Tokyo meeting, we discuss this a bit and decided that this
	issue required more dicussions. 

	Question: Do deprecated features render a program ill-formed but
	no diagnostic is required?
Resolution:
Requestor:      UK issue 9
Owner:          Tom Plum (Required Diagnostics)
Emails:         
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   603
Title:          Do the WP constraints prevent multi-threading 
	        implementations? 
Section:	1.8 [intro.execution]
Status:         active
Description:
	UK issue 11:
	"No constraints should be put into the WP that preclude an 
	 implementation using multi-threading, where available and 
	 appropriate."

	For example, do the requirements on order of destruction between
	sequence points preclude C++ implementation on multi-threading 
	architectures?
Resolution:
Requestor:      UK issue 11
Owner:          Tom Plum (Program Execution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   605
Title:	        The execution model wrt to sequence points and side-effects
	        needs work
Section:        1.8 [intro.execution]
Status:         active
Description:
	See UK issues 263, 264, 265, 266:
	1.8 para 9:  
	"What is a "needed side-effect"? This paragraph, along with 
	 footnote 3 appears to be a definition of the C standard "as-if" 
	 rule.  This rule should be defined as such.  [Proposed definition 
	 of "needed": if the output of the program depends on it.]"
	1.8 para 10:
	"It is not true to say that values of objects at the previous 
	 sequence point may be relied on.  If an object has a new value 
	 assigned to it and is not of type sig_atomic_t the bytes making up 
	 that object may be individually assigned values at any point prior 
	 to the next sequence point.   So the value of any object that is 
	 modified between two sequence points is indeterminate between those
	 two points.  This paragraph needs to be modified to reflect this 
	 state of affairs."

	Also, para 11:
	"Such an object [of automatic storage duration] exits and retains its
         last-stored value during the execution of the block and while the 
	 block is suspended ..."
	This is not quite correct, the object may not retain its last-stored
	value.

	para 9, 10, 11 and 12 also contain some undefined terms.
Resolution:
Requestor:      UK issues 263, 264, 265, 266
Owner:          Tom Plum (Program Execution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 2 - Lexical Conventions
---------------------------------
Work Group:     Core
Issue Number:   606
Title:          The description of the compilation model needs work
Section:        2.1 [lex.phases]
Status:         active
Description:
	UK issues 19:
	Interaction of templates with phases of translation needs to be 
	specified.
Resolution:
Requestor:      UK issues 19
Owner:          Tom Plum (compilation model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   584
Title:          May a // comment end with an EOF instead of a newline?
Section:        2.1 [lex.phases]
Status:         active
Description:
	2.1 [lex.phases], 1st paragraph, third bullet, does not clearly 
	answer this question.
Resolution:
Requestor:	Mike Holly
Owner:          Tom Plum 
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   607
Title:          Definition needed for basic source character set
Section:        2.9.2 [lex.ccon]
Status:         active
Description:
	UK issue 288:
	"What is "the machine's character set"?  Is this the basic source 
	 character set that we have forgotten to define?  Suggest that the 
	 wording from C standard, Clause 6.1.3.4, Semantics, first paragraph
	 be used (it contains the important concept of mapping)."

	Other UK related issues 289, 290, 292.
Resolution:
Requestor:	UK issue 288
Owner:          Tom Plum 
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   506
Title:          Is a program containing a non-representable floating point 
                constant ill-formed?
Section:        2.9.3 [lex.fcon]
Status:         active
Description:
	2.9.1 [lex.icon] p3 says:
	"A program is ill-formed if it contains an integer literal that 
	 cannot be represented by any of the allowed types."

	For consistency with 2.9.1, shouldn't a program containing a 
	non-representable floating point constant be ill-formed? (if the 
	exponent is too large, for example?)
Resolution:
Requestor:	Erwin Unruh
Owner:          Tom Plum 
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 3 - Basic Concepts
----------------------------
Work Group:     Core
Issue Number:   460
Title:          Definition for the term "variable"
Section:        3 [basic] Basic concepts
Status:         active
Description:
	Editorial Box 5:
	The definition for the term variable is needed.
Proposed Resolution:
	"A variable is introduced by an object's declaration and the 
	 variable's name denotes the object."        
	Clark Nelson will provide a paper for the Tokyo meeting (November
        1995).

	Also UK issue 334.
Resolution:
Requestor:      
Owner:          Clark Nelson (Object Model)
Emails:
Papers: 
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core        
Issue Number:   427     
Title:          When is a diagnostic required when a function/variable with
                static storage duration is used but not defined?       
Section:        3.2 [basic.def.odr] One Definition Rule        
Status:         active
Description:        
	When is a diagnostic required if no definition is provided for a
        function or for variable with static storage duration?

	int main() {
		extern int x;
		extern int f();
		return 0 ? x+f() : 0;
	}

        Must a disgnostic be issued if x and f are never defined?            

	The current WP contains this sentence: "If a non-virtual function is
	not defined, a diagnostic is required only if an attempt is actually
	made to call that function." This seems to be hinting that, for
	cases such as the one above, a diagnostic is not required.

	[Jerry Schwarz, core-6173:]
	 I think we should be talking about undefined behaviors, not required
	 diagnostics. That is, if a program references (calls it or takes its
         address) an undefined non-virtual function then the program has
         undefined behavior.

	[Fergus Henderson, core-6175, on Jerry's proposal:]
	 I think that would be a step backwards.  If a variable or function
         is used but not defined, all existing implementations will report a
	 diagnostic.  What is to be gained by allowing implementations to
	 do something else (e.g. delete all the users files, etc.) instead?

	[Mike Ball, core-6183:]
	 Then you had better not put the function definition in a shared
         library, since this isn't loaded until runtime.  Sometimes linkers
         will detect this at link time and sometimes they won't.

        [Sean Corfield, core-6182:]
	 I'd like it worded so that an implementation can still issue a
         diagnostic here (example above) AND REFUSE TO EXECUTE THE PROGRAM.
         If 'x' and 'f' were not mentioned in the program (except in their
         declarations) I would be quite happy that no definition is required.
         But unless an implementation can refuse to execute the program, you
         are REQUIRING implementations to make the optimisation and that is
         definitely a Bad Thing(tm), IMO. It seems the only way to allow that
         is to make the program ill-formed (under the ODR) but say no
         diagnostic is required.

	[Fergus Henderson, core-6174:]
	 ObjectCenter reports a diagnostic only if an attempt is actually 
         made to use the function or variable; in other words, link errors 
         are not reported until runtime.  In an interpreted environment, this
         is quite desireable.

	See also UK issues 335, 336, 337.

	Note: Jim Welch will write a paper on this topic for the Scotts 
              Valley meeting.
Resolution:
Requestor:      Josee Lajoie
Owner:          Josee Lajoie (ODR)
Emails:        
	core-6172
Papers: 
	95-0205/N0805
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   556
Title:          What does "An object/function is used..." mean?
Section:        3.2 [basic.def.odr] One Definition Rule
Status:         active
Description:
	This is from public comment T25:
	"It is not clear what object 'use' and 'reuse' is."

	Neal Gafter also notes:
	"When must a class destructor be defined?

	 According to a strict interpretation of 3.2 [basic.def.odr]
         paragraph 2, the destructor for class A in the program below needn't
         be defined.  

	 struct A {
		~A();
	 };
	 void f() throw (A*)
	 {
		A *a = new A;
		throw a;
	 }
	 main()
	 {
		return 0;
	 }

	 The same question applies to many other contexts in which
	 destructors are implicitly used.  For example, the expression

		new A[20]

	 generates code to call the destructor A::~A() when the constructor
	 throws an exception.  Does this mean the destructor must be defined 
         in order to new an array?" 

	 Also see UK issue 364.

	 Note: Jim Welch will write a paper on this topic for the Scotts 
               Valley meeting.
Resolution:
Requestor:      comment T25 (3.8)
Owner:          Josee Lajoie (ODR)
Emails:
Papers:
	95-0205/N0805
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   612
Title:	        Qualified name look up and unnamed namespaces
Section:        3.4.2.2 [namespace.qual]
Status:         active
Description:
	paragraph 5 says:
	"During the look up of a qualified namespace member name, if the 
	 look up finds more than one declaration of the member, and if
	 one declaration introduces a class name or enumeration name and
         the other declaration either introduce the same object, the same
	 enumerator or a set of functions, the non-type name hides the
	 class or enumeration name if and only if the declarations are
	 from the same namespace; otherwise (the declarations are from 
	 different namespaces), the program is ill-formed."

	Consider the program:

	   struct S { };
	   static int S;
	   int foo() { return sizeof(S); }

	The sizeof will resolve to the static int S, because nontypes are
	favored.

	The standard says that unnamed namespaces will deprecate the use of
 	static so we should be able to rewrite the program as:

	   struct S { };
	   namespace {
	      int S;
	   }
	   int foo() { return sizeof(S); }

	However, the sizeof becomes ambiguous according to 3.4.2.2 para 5 
	because the two S are from different namespaces. Is this right?
	Doesn't this mean that static should not be deprecated?
Resolution:
Requestor:
Owner:		Steve Adamczyk (Name Look up)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   526
Title:          What is the linkage of names declared in unnamed namespaces?
Section:        3.5 [basic.link] Program and linkage
Status:         active
Description:
	What is the linkage of names declared in an unnamed namespace?
	Internal linkage?
	Internal linkage applies to variables and functions.
	What would the status of a type definition be in an unnamed 
        namespace? No linkage?
        Can it be used to declare a function with external linkage?  
        Can it be used to instantiate a template?

          namespace {
            class A { /* ... */ };
          }
          extern void f(A&);                            // error?
          template <class T> class X { /* ... */ };
          X<A> x;                                       // error?

	If A does not have external linkage, then the two declarations are
	probably errors.  If it does have external linkage, then the two
	declarations are legal (and the implementation probably has to worry
	about name mangling).

	At the Monterey meeting, Mike Anderson promised to present a paper
	at the Tokyo meeting with a proposed resolution.
Resolution:
Requestor:	Mike Anderson
Owner:          Josee Lajoie (Linkage)
Emails:
	core-5905 and following messages.
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   551
Title:          Must all C++ programs defined main?
Section:        3.6.1 [basic.start.main] Main function
Status:         closed
Description:
	3.6.1[basic.start.main] paragraph 1 says:
	"A program shall contain a global function called main, which is
	 the designated start of the program."

	In C, a freestanding environment is not required to have a main
	function; the program invocation is implementation-defined.
	Should this be the case in C++?
Resolution:
	See Tokyo motion 7a)
	Replace 3.6.1[basic.start.main] paragraph 1 with:
	"A C++ program shall contain a global function called main, which is
	 the designated start of the program.  It is implementation-defined
	 whether a program in a freestanding environment is required to 
         define a main function.  [Note: in a freestanding environment 
	 start-up and termination is implementation-defined; start-up 
         contains the execution of constructors for nonlocal objects with 
         static storage duration; termination contains the execution of 
         destructors for objects with static storage duration.]
Requestor:	Neal Gafter
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   552
Title:          Why is an implementation prohibited from destroying objects
                with automatic storage duration when exit is called?
Section:        3.6.1 [basic.start.main] Main function
Status:         editorial
Description:
	3.6.1[basic.start.main] paragraph 4 says:
	"Calling the function [exit] declared in <cstdlib> terminates the
	 program without leaving the current block and hence without
	 destroying any objects with automatic storage duration."

	Why is an implementation prohibited from destroying objects with
	automatic storage duration when exit is called?
	Could it say it is implementation-defined?
	Could the standard require that the implementation destroy objects
	with automatic storage duration when exit is called?
Resolution:
	Mike Ball had the following comment on the proposal from editorial
	box 15:
	  > There are reasons to call exit rather than abort even in
	  > "emergency" cases.  For example you might want to execute static
	  > destructors to empty file buffers.  You might want to execute a
	  > return with a different status, but not dump core.  If you make
	  > this change you will be deleting a behavior on which some 
	  > programs depend and providing no alternative way to get the 
	  > behavior.
 	  >
	  > I see no justification at all for such a drastic change in
	  > well-defined semantics at this late stage.

	I believe Mike's arguments against the proposal in editorial box 15
	are important enough that we should leave the language as is.

	Keep paragraph 4 as is (and delete the editorial box).

	This was agreed to at the Tokyo meeting.
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   462
Title:          calling exit from a destructor for a global variable
Section:        3.6.1 [basic.start.main] Main function
Status:         closed
Description:
	3.6.1 p4:
	"Calling the function [exit] declared in <cstdlib> terminates the 
 	 program without leaving the current block and hence without 
	 destroying any objects with automatic storage duration."

	What happens if exit is called from the destructor for a global 
	variable?
	The global destructor will be called again for the same object when 
	exit destroys the global objects. 

	[ JL Note: ]
	Related question:
	What if a global destructor throws an exception and the user-defined
	terminate routine calls exit?  
Resolution:
	See Tokyo motion 7a)
	Add to 3.6.1 [basic.start.main] paragraph 4:
	  "If 'exit' is called during the destruction of an object with
	   with static storage duration, the program results in 
           undefined-behavior."
Requestor:      Simon Tooke      
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   429
Title:          Order of initialization of reference variables
Section:        3.6.2 [basic.start.init] Initialization of non-local objects
Status:         closed
Description:
        Is the following initialization of "r" performed "statically" (that
        is, at link time) or "dynamicaly" (that is, at its turn among
        dynamically initialized nonlocal objects in the translation unit)?

        extern int x;
        int &r = x;
Resolution:
	See Tokyo motion 7a)
	The initialization above takes place during the static phase of
	initialization.
	Add to 5.19 [expr.const]:
	"A 'reference constant expression' is an lvalue designating an
	 object of static storage duration or a function.  The
	 subscripting '[]' operator, the class member access '.' and '->'
	 operators, the '&' and * unary operators, and reference casts
	 (except those invoking user-defined conversion functions (12.3)
	 and except dynamic_casts (5.2.6)) can be used by the lvalue
	 expression of a reference constant expression, but the value of
	 an object shall not be accessed by the use of these operators.
	 An lvalue expression that designates a member or base class of a
	 non-POD class object (9) is not a reference constant expression
	 (12.7).  Function calls shall not be used in a reference constant
	 expression, even if the function is inline and has a reference
	 return type."
Requestor:      Neal Gafter
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   527
Title:          When must the initialization of nonlocal objects take place?
Section:        3.6.2 [basic.start.init] Initialization of non-local objects
Status:         editorial
Description:
	3.6.2[basic.start.init] paragraph 1 says:
	  "The initialization of nonlocal objects with static storage 
           duration defined in a translation unit shall be done before the 
           first use of any function or object defined in that translation 
           unit."

        What does 'use' mean here?
        It was suggested that the above wording be clarified as follows:
Resolution:
	At the Tokyo meeting, the Core WG decided that the following
	was an editorial clarification of the current WP rules:

	"It is implementation-defined whether the initialization of an
	 object of namespace scope with static storage duration is done 
	 before the first statement of main() or deferred to any point in 
	 time after the first statement of main() but before the first use 
	 of a function or object defined in the same translation unit.
	 [Example:
		// -- File 1 --
		#include "a.h"
		#include "b.h"

		B b;

		A::A()
		{
			b.Use();
		}

		// -- File 2 --
		A a;

		// -- File 3 --
		#include "a.h"
		extern A a;
		main() { a.Use(); }

	 it is implementation-defined whether 'a' is defined before main is
	 entered or whether its definition is delayed until 'a' is first used
         in main.  It is implementation-defined whether 'b' is defined before
         main is entered or whether this definition is delayed until it is 
 	 used by A::A().
         -- end example]"
Requestor:	John Max Skaller
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
	core-5672
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   555
Title:          Clarify: order of (static vs dynamic) initialization
Section:        3.6.2 [basic.start.init] Initialization of non-local objects
Status:         closed
Description:
	This is from public comment 8.2:
	  Section 3.6.2, paragraph 1: I find this paragraph confusing.  To me
          it appears as if the statement that objects "initializated with
          constant expressions are initialized before any dynamic ... 
          initialization takes place" is in conflict with the statement that
          within a translation unit, "the order of inititialization of 
          non-local objects ... is the order in which their definition
          appears".
Resolution:
	See Tokyo motion 6).	
Requestor:	Public Comment 8.2
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   613
Title:          What is the order of destruction of objects statically
	        initialized?
Section:        3.6.2 [basic.start.init]
Status:         active
Description:
	Given:
		struct A { int i; ~A(); };
		A a = { 1 };
	when can we expect 'a' to be destroyed?
Resolution:
Requestor:	Erwin Unruh
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   430
Title:          Order of destruction of local static variables
Section:        3.6.3 [basic.start.term] Termination
                6.7 [stmt.dcl] Declaration statement
Status:         closed
Description:
        3.6.3 says static objects are destroy in reverse order of
        intialization.
        6.7 says destruction order is unspecified.
        Which one is right?

	The possibilities:
	1) The order of destruction of local variables with static storage
	   duration is unspecified. [as 6.7 implies].
	2) It is guaranteed that local variables with static storage duration
	   declared in the same function are destroyed in reverse order of
	   construction.  The order of destruction of local variables with
	   static storage duration is otherwise unspecified.
	3) It is guaranteed that variables with static storage duration
	   declared in the same translation unit (either declared at block
	   scope or declared in namespace scope) are destroyed in reverse of
	   construction.  The order of destruction of local variables with
	   static storage duration is otherwise unspecified.
	4) It is guaranteed that all variables with static storage
	   duration in the program (either declared at block scope or
	   declared in namespace scope) are destroyed in reverse of
	   construction.  [as 3.6.3 implies].

	4) is the nicest option for users.  However, it is the most expensive
	option for implementations.  Mike Ball has commented earlier that
	this option does not work well for dynamic libraries.  However, the
	draft does not describe the behavior of programs using dynamic
	libraries in many other situations.  The committee's position has
        been to leave the description of programs using dynamic libraries as
	implementation-defined.  Maybe here is a situation where this applies
	as well: the order of destruction of local variables with static
	storage duration if the program uses dynamic libraries is
	implementation-defined.
Resolution:
	See Tokyo motion 7b).
	Option 4) was adopted.
Requestor:      Mike Ball
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:         core-4989
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   484
Title:          When must objects of static storage duration be destroyed wrt
                to calls to functions registered with atexit?
Section:        3.6.3 [basic.start.term] Termination
Status:         closed
Description:
	3.6.3[basic.start.term] paragraph 1 says:
	"If atexit is to be called, the implementation shall not destroy
	 objects initialized before an atexit call until after the function
	 specified in the atexit() call has been called."

	6.7[stmt.dcl] paragraph 5 says:
	"The destructor [for local object with static storage duration]
	 is called either immediately before or as a part of the calls to
	 the atexit functions."

	18.3[lib.support.start.term] paragraph 3 says:
	"-- First all functions f registered by calling atexit(f) are called,
	    in reverse order of their registration.
	 -- Next, all static objects are destroyed in the reverse order of
	    their construction. ..."

	When must local objects with static storage duration be destroyed
        wrt to calls to functions registered with atexit?
Resolution:
	See Tokyo motion 7b).
	The WP will be made consistent with the rule in 3.6.3.
Resolution:
Requestor:      lijewski@roguewave.com
Owner:          Josee Lajoie (Initialization/Destruction)
Emails:
        core-5596
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   546
Title:          What is the required behavior for a user allocator?
Section:        3.7.3 [basic.stc.dynamic]
Status:         active
Description:
	3.7.3 [basic.stc.dynamic] para 3 says:
	"Any allocation and/or deallocation functions defined in a C++
         program shall conform to the semantics specified in this subclause."
	3.7.3.1 [basic.stc.dynamic.allocation] para 2 says:
	"Each such allocation shall yield a pointer to storage
         (_intro.memory_) disjoint from any other currently allocated 
         storage."

	Does "currently" mean at the time of the call to the allocation
	function, or at the time it returns?  If the latter, how can a
	user-defined allocation function return a pointer to storage that is
	disjoint from any other currently allocated storage?  Even if the
	former interpretation is correct, the above two rules would rule out
	all of the most useful ways of defining operator new - at least one 
	of those rules must be changed. 

	Erwin Unruh suggests in core-6228 that this requirements belongs to
        the library clause that describes the requirements on the allocation
        functions provided by the standard library.
Resolution:
Requestor:	Fergus Henderson
Owner:          Josee Lajoie (new/delete)
Emails:	        core-6170
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   554
Title:          Can the storage in which a const object resides be reused?
Section:        3.8 [basic.life]
Status:         closed
Description:
	Can the storage in which a const object resides be reused?
	And if so, how is the "write-protected" attribute that may be
	associated with the memory in which the object resides interpreted?
Resolution:
	See Tokyo motion 8).

	Add the following as paragraph 9 of 3.8[basic.life].
	"Creating a new object at the storage location which a const object
	 with static or automatic storage duration occupies or at the storage
         location which such an object used to occupy before its lifetime 
	 ended results in undefined behavior.  [Example:
	 struct B {
	 	~B();
	 };
	 const B b;
	 void h() {
	 	b.~B();
		new (&b) B; // undefined behavior
	 }
	 --end of example]
	"
Resolution:
Requestor:
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   192
Title:          Should a typedef be defined for the type with strictest
                alignment?
Section:        3.9 [basic.types] Types
Status:         active
Description:
        It would be useful if  <new.h>  provided a typedef for a name such as
        __strict_align_t , to describe a type whose alignment is the 
	strictest required in this environment.  It is otherwise hard to 
	write a portable overloaded new operator.  Faking it, by defining a 
	union of several "typical" types, is not really portable, and its 
	quiet mode of failure might be extremely puzzling, because the 
	program would run just fine most of the time in most environments, 
	except that in some unusual environment the program would 
	occasionally produce an alignment error.

        As WG14 and X3J11 have found out, some compilers add an alignment
        requirement for structures embedded inside structures, one which is
        even more restrictive than the scalar types!
        There are no real-world guarantees about alignment, unless the
	committee imposes them.

        ALTERNATIVE: The committee could prescribe specific requirements for
        alignment.  E.g., in any conforming environment, no object may have 
	an alignment requirement more restrictive than this specific type:
                struct _strict_align_t { struct { long n; double d; }; };

        92/12/07 NOTE: To allow the writing of portable allocators, it may
	also be necessary to define an  __align_pointer(p)  function, which
	returns the nearest pointer (address) value which is aligned on the
	strictest boundary and is greater than or equal to the pointer value
	 p .
Resolution:
Requestor:      Tom Plum / Dan Saks
Owner:          Josee Lajoie (Memory Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   464
Title:	        Can memcpy be used to copy pointer to members?
Section:        3.9 [basic.types] Types
Status:         closed
Description:
	3.9 p3 says:
	"For any scalar type T, if two pointers to T point to distinct T
	 objects obj1 and obj2, if the value of obj1 is copied into obj2,
 	 using the memcpy library function, obj2 shall subsequently hold the
	 same value as obj1."

	Shouldn't this also be valid if T is a pointer to member type?

	class A { void f(int); };
	typedef (A::*PM)(int);
		
	{
		A a;
		PM p = A::f;
		PM q;
		memcpy(&q, &p, sizeof(PM));
		(a.*q)(0);
	}
Resolution:
	At the Tokyo meeting, the core WG decided to adopt Bill Gibbons' 
	paper 95-0174/N0774, Definitions of "scalar type" and "fundamental 
	types" as editorial work.
	As a result of this, pointer-to-members are now scalar types and 
	are covered by the rules above.
Requestor:	Nathan Myers
Owner:          Bill Gibbons (Memory Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   557
Title:          The description of the memory model needs fine tuning
Section:        3.9 [basic.types] Types
Status:         editorial
Description:
	1) What does it mean for a copy operation to be ``well-defined''?
	paragraph 2 says:
	"For any object of type T, the underlying bytes of the object can be
	 copied (using the memcpy library function) into an array of char or
         unsigned char. This copy-operation

	How can I tell that the ``copy operation is well-defined''?
	It is not clear what ``well-defined'' means here or if I can test for
	it.
	
	2) Is the notion of value-representation really needed? 
	paragraph 4 says:
	"The value representation of an object is the sequence of bits in the
	 object representation that hold the value of type T. The bits of the
	 value representation determine a value, which is one discrete 
	 element of an implementation-defined set of values." 

	The ``value'' of an object of type T is not necessarily based upon
	its bit represention, especially when the class is a handle to other
	data.  The ``value'' in this case would depend upon how the
	"==" operator is overloaded.  Even if its ``representation value'' is
        somehow defined, what purpose does it serve?  Where else is this used
	in the draft?
Resolution:
	At the Tokyo meeting, the core WG decided that the following
	clarifications were editorial:
	1) The sentence in 3.9 paragraph 2 will be replaced with:
	"For any object of type T, whether or not the object holds a valid
	 value of type T, the underlying bytes of the object can be copied
	 into an array of char or unsigned char.  If the content of the array
         of char or unsigned char is copied back into the object, the
	 object shall subsequently hold its original value."
	2) The sentences in 3.9 paragraph 4 will be replaced with:
	"The value representation of an object of type T is the sequence of
	 bits that holds the value of type T.  For scalar types, the value 
	 representation is a sequence of bits in the object representation 
	 that determines a value that is one discrete element of an 
	 implementation-defined set of values."
Requestor:      public comment T25 (3.9-2)
Owner:          Josee Lajoie (Memory Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   608
Title:	        Is an incompletely-defined object type an object type?
Section:        3.9 [basic.life]
Status:         active
Description:
	paragraph 6:
	"The term incompletely-defined object type is a synonym for
	 imcomplete type; the term completely-defined object type is a
	 synonym for complete type." 

	UK issue 400:
	"In ISO 9899 an incomplete type is not an object type 
	(Clause 6.1.2.5, first paragraph).  Defining an 
	"incompletely-defined object type" is a needless incompatibility 
	with ISO 9899.  Use another term.
Requestor:	UK issue 400
Owner:          Steve Adamczyk (Types)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   553
Title:          Clarify: "The representations of integral types shall define
                values by use of a pure binary numeration system."
Section:        3.9.1[basic.fundamental]
Status:         editorial
Description:
	3.9.1[basic.fundamental] paragraph 9 says:
	"The representations of integral types shall define values by use of
	 a pure binary numeration system."
	Does this means two's complement?
Proposed Resolution:
	The following footnote should be added to the WP (which is almost
        word for word the footnote that appears in the C standard):
	"A positional representation for integers that uses the binary
	 digits 0 and 1, in which the values represented by successive bits
	 are additive, begin with 1, and are multiplied by successive
	 integral power of 2, except perhaps the bit with the highest
	 position.

	 For any integral type, 2's complement and signed magnitude
	 implementations are permitted, and for integral types other than
	 character types, 1's complement implementations are also permitted."
Resolution:
Requestor:
Owner:          Josee Lajoie (Core Editorial)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 4 - Standard Conversions
----------------------------------
Work Group:     Core        
Issue Number:   572
Title:          How do enum values promote? 
Section:        4.5 [conv.prom]
Status:         editorial
Description:
	Section 7.2, "Enumeration declarations" defines the "underlying type"
        of an enum, but then mentions it only for purposes of defining the
        effect of sizeof.

	Paragraph 8 says enum values undergo integral promotions in
        expressions according to 4.5. But in neither place does it say how to
        perform the promotion.

	Example, supposing 16-bit ints:
	    enum E { lo = 1, hi = 32769 };
	The range won't fit in an int, so the underlying type of E must be
	unsigned int, long, or unsigned long.

	    f(int);
	    f(unsigned int);
	    f(long);
	    f(unsigned long);
	    ...
	    f(2 + lo); // which 'f' gets called?

	I would assume the underlying type would determine the type of the
	promoted value of 'lo', and thus which 'f' gets called, but the
	draft doesn't say.

	I think you have to use the underlying type, because of this:
	    E e = lo;
	    f(2 + e); // which 'f' gets called?
	This expression better call the same version of 'f' as the previous
	one.
Resolution:
	At the Tokyo meeting, the core WG decided on the following 
	editorial clarification:
	  "The underlying type of an enumeration type determines how 
	   the enumeration type promotes."
Requestor:	Steve Clamage
Owner:          Steve Adamczyk (Type Conversions)        
Emails:
Papers:        
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core        
Issue Number:   455
Title:          Should implicit floating->integral conversions be deprecated?
Section:        4.9 [conv.fpint] Floating-integral conversions
Status:         closed
Description:
Resolution:
	At the Tokyo meeting, the core WG decided that, given the schedule
	constraints, this request would not be consider for the first
	release of the C++ standard.
Requestor:      Bjarne Stroustrup
Owner:          Steve Adamczyk (Type Conversions)        
Emails:        
	core-4757
Papers:        
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core        
Issue Number:   547
Title:          Semantics of standard conversion derived to base need better
                description
Section:        4.12 [conv.class]
Status:         active        
Description:
	4.12 [conv.class] says:
	  "An rvalue of type "cv D", where D is a class type, can be
	   converted to an rvalue of type "cv B", where B is a base class of
	   D.  If B is an inaccessible or ambiguous base class of D or if the
	   conversion is implemented by calling a constructor and the
	   constructor is not callable, a program that necessitate this
	   conversion is ill-formed." 

	Isn't the copy constructor always called to convert an rvalue of a
	derived class type to an rvalue of base class type?  If so, I don't
	understand the phrase "..._if_ the conversion is implemented by
	calling a constructor...".  Since all classes have a copy constructor
	(either user-declared or implicitly-declared), I would assume that,
	at least conceptually, a copy constructor is always used.

	Also, the conversion is described as converting from "cv D" to "cv
	B".  I don't believe it is accurate to say that the cv-qualifiers are
	always the same.  Don't the cv-qualifiers on D depend on the
	cv-qualifiers acceptable for the copy constructor's 1st parameter and
	aren't the cv-qualifiers on B independent of the cv-qualifiers
	specified on the source type of the conversion?
Resolution:
	Steve Adamczyk will present a paper for the Scotts Valley meeting.
Requestor:
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   601
Title:          Should implicit conversion from int to bool be allowed?
Section:        4.13 [conv.bool]
Status:         active
Description:
	ISO Swedish comment R-28:
	Strengthening of bool datatype [conv.bool]  The original proposal 
	for a Boolean datatype (called bool) provided some additional 
	type-safety at little cost.  SC22/WG21 changed the proposal to allow
	implicit conversion from int to bool, thereby reducing type-safety 
	and error detectability.

	The implicit conversion from int to bool shall be deprecated, as
	described in document 93- 0143/N0350.  As a future work-item, the
	implicit conversion should be removed.
Resolution:
Requestor:	Swedish Delegation
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 5 - Expressions
-------------------------
Work Group:     Core
Issue Number:   512
Title:          parsing destructors calls
Section:        5.1 [expr.prim] Primary expressions
Status:         active
Description:
	5.1p7 says:
	"A class-name prefix by ~ denotes a destructor."
	
	There is a syntactic ambiguity on the usage of a destructor. 
	The code '~X();' in the scope of a member function of class X can be 
	interpreted as an explicit destructor call using the implicit this
        pointer. The other interpretation is the unary operator ~ applied
        to a function like cast.
Resolution:
Requestor:      Erwin Unruh
Owner:          Anthony Scian (Syntax)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   433
Title:          What is the syntax for explicit destructor calls?
Section:        5.1 [expr.prim] Primary expressions
                12.4 [class.dtor] Destructors
Status:         active
Description:
        Question 1:
        p10 says:
        The notation for explicit call of a destructor may be used for any
        simple type name. For example:
           int* p;
           p->int::~int();

        Must the destructor name be a qualified-id or can it be written as:
           p->~int();
        ?

        Question 2:
        Can a typedef name be used following the ~, and if so, what are the
        lookup rules?

        struct A {
                ~A(){}
        };

        typedef class A B;

        int main()
        {
                A* ap;
                ap->A::~A();    // OK
                ap->B::~B();    // cfront/Borland OK, IBM/Microsoft/EDG error
                ap->A::~B();    // cfront OK, Borland/IBM/Microsoft/EDG error
                ap->~B();       // OK?
        }

        This issue concerns the lookup of explicit destructor calls for 
        nonclass types as well.

        typedef int I;
        typedef int I2;
        int*    i;
        i->int::~int();
        i->I::~I();
        i->int::~I();
        i->I::~int();
        i->I::~I2();

        Which of these are well formed? 
Resolution:
Requestor:      John H. Spicer
Owner:          Steve Adamczyk (Name Lookup)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:	465
Title:          grammar needed to support template function call
Section:	5.1 [expr.prim] Primary expression
Status:         active
Description:
	"id-expression" does not allow the syntax
	  f<arg>
	needed for a call to a template function using explicit arguments.

	Possible solution:
	  Add template-function-id (i.e. production for f<>) to the list of
          unqualified-ids:

	  	unqualified-id:
			...
			template-function-id
Resolution:
Requestor:      
Owner:          Anthony Scian (Syntax)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:	466
Title:          grammar needed to support ~int()
Section:        5.1 [expr.prim] Primary expression
Status:         active
Description:
	The grammar does not allow for explicit destructor calls for built-in
        types:
	  int* pi;
	  pi->~int();

  	Possible solution:
	  unqualified-id:
                ...
          	~enum-name
		~typedef-name
		~simple-type-specifier
Resolution:
Requestor:      
Owner:          Anthony Scian (Syntax)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   417
Title:          Should pointer arithmetic be allowed for pointer-to-abstract
                classes?
Section:        5.2.1, 5.2.5, 5.3.1, 5.3.2, 5.7
Status:         editorial
Description:    
        Should pointer arithmetic and/or the sizeof operator be allowed for 
        operands whose type is some pointer-to-abstract type?

        Note that if it is the committee's judgement to effect such 
        restriction, these restrictions would have to be reflected in working
        paper sections 5.2.1, 5.2.5, 5.3.1, 5.3.2, and 5.7.
Resolution:
	At the Tokyo meeting, the Core WG agreed to the following editorial
	resolution:
	1) If an lvalue-to-rvalue consversion takes place, and the lvalue is
	   of type T, if the object referred to by the lvalue is not an 
	   object of type T the program has undefined behavior.
	2) Referring to an object that is not initialized (that has 
	   indeterminate value) results in undefined behavior.
	This covers cases when operators [], ++/--, +/-, +=/-=, =, 
	*(indirection), relational, equality are applied to pointers to 
	abstract type, pointers to incomplete type and other situations where
	the pointer type and the type of the underlying object are different.
Requestor:      Ron Guilmette
Owner:          Josee Lajoie(Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   535
Title:          Does the initialization of a parameter take place in the
                caller or in the callee?
Section:	5.2.2 [expr.call]
Status:         closed
Description:
	The DWP says, (5.2.2, P3)
	    "When a function is called, each parameter(8.3.5) shall be
	    initialized with its corresponding argument.  Standard and 
	    user-defined conversions shall be performed"

	And in (P8) it says
	    "All side effects of argument expressions take effect before the
	    function is entered".

	The questions are

	1.  Is the initialization of the parameter part of entering the 
	    function, or is it part of evaluating the argument?

	2.  Is the application of a conversion part of evaluating the
	    argument, or part of entering the function?

	The answers determine what gets destroyed when an exception is thrown
	in the process of evaluating an argument expression.  It also
	determines the order of destruction, since parameters aren't 
	temporary variables, they have to be destroyed immediately on return 
	rather than at the end of the full-expression.  If they are created 
	as part of the argument evaluation the order of destruction could be
	different from the order of creation.  Suppose there is an exception
	thrown in the copy constructor.  Do all parameters have to have been
	evaluated?

	If we interpret this strictly I don't see how we can ever eliminate
	copy constructors for parameters, since the rules for destruction of
	local temps and parameters are different.

	My preferred solutions, in order of preference.

	1. Initialization is part of argument evaluation and even parameters
	can be treated as temps and left to the end of the full expression.

	2. Initialization is separate and occurs after argument evaluation.
	Conversion is considered part of argument evaluation.
	If a copy constructor is eliminated the "parameter" is what is
	eliminated and the temp isn't destroyed until the end of the
	full expression.

	3. like 2, but conversion is part of the initialization

	4. A strict interpretation requiring that parameters be initialized
	only after arguments are evaluated.  This seems to me to
	eliminate the optimization of copy constructors.                 
Resolution:
	See Tokyo motion 3).
Requestor:	Mike Ball
Owner:	        Josee Lajoie (order of construction/destruction)
Emails:
	core-5854
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   548
Title:          Which conversions apply to the postfix-expression in a
                function call?
Section:        5.2.2 [expr.call]
Status:         editorial
Description:
	paragraph 1 says:
	"For an ordinary function call, the postfix-expression shall be a 
	 function name, or shall have pointer or reference to function type."

	Issue 1)
	 Why does it talk about reference to function here?
	 Shouldn't the decay reference to T -> lvalue of type T have happened
	 already?	
	Issue 2)
	 Also, since this is talking about function name, the conversion
	 function to pointer must not have taken place.  Shouldn't this 
	 subclause say that this conversion is not applied? 
Resolution:
	At the Tokyo meeting, the core WG decided to handle issue 1) 
	as an editorial issue.
	Issue 2) is already solved, see 5.2.2 para 9.
Requestor:
Owner:  	Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   558
Title:          In T(), may T be more than one simple-type-specifier?
Section:        5.2.3 [expr.type.conv]
Status:         closed
Description:
	paragraph 1 says:
	"A simple-type-specifier followed by a parenthesized expression-list
	 constructs a value of the specified type given the expression list."
	
	Is 'unsigned int (1)' well-formed?
Resolution:
	No, 'unsigned int (1)' is ill-formed. At the Tokyo meeting, the 
	core WG decided this was not a problem worth fixing.
Requestor:
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   452a
Title:          How does name look up work after . or -> for namespace names
                or template names?
Section:        5.2.4 [expr.ref] Class member access
Status:         active
Description:
        5.2.4 says p3: 
        "If the nested-name-specifier of the qualified-id specifies a
	 namespace name, the name is looked in the context in which the
	 entire postfix-expression occurs."
       
        This is backward. One doesn't know if the name is a namespace name 
        until the name has been looked up. In which scope must the name 
	following the . or -> operator be first looked up?  
         
        namespace N { } 
        struct S { 
          class N { };
        };
        S s;
  
        ... s.N::b ...

        The scope of the object-expression 's' or the scope in which the 
        entire expression takes place? 

        --------
	
	Neal Gafter also asks:
	"In the syntax

	    p->template T<args>::x

	 in which scope(s) is T looked up?"

	template <class X> class T { static X x; };
	
	class C {
	   template <class X> class T { static X x; };
        };
	
	C* p;
	p->template T<args>::x
Resolution:
Requestor:
Owner:          Steve Adamczyk (Name Look Up)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   468
Title:          How does dynamic_cast to void* work for non-polymorphic 
                types?
Section:        5.2.6 [expr.dynamic.cast]
Status:         active
Description:
	5.2.6 p7 says:
	"If T is 'pointer to cv void', then the result is a pointer to the 
	 complete object pointed (referred) to by v. Otherwise the run-time
	 check is applied ..."

	Does this apply to pointers to non-polymorphic types?

	class A { };
        class B { };
	class C : public A, public B { };

        C c;
	B* pb = &c;

	dynamic_cast<void*>(pb);  // will this return a ptr to the object c?
Resolution:
Requestor:
Owner:		Bill Gibbons (RTTI)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   549
Title:          Is a dynamic_cast from a private base allowed?
Section:        5.2.6 [expr.dynamic.cast]
Status:         active
Description:
	paragraph 8 says:
	"...if the type of the complete object has an unambiguous public base
	 class of type T, the result is a pointer (reference) to the T
	 sub-object of the complete object. Otherwise, the runtime check
         fails."
	
	This contradicts the example that follows:
	class A { };
	class B { };
	class D : public virtual A, private B { };
	...
	D d;
	B* bp = (B*) &d;
	D& dr = dynamic_cast<D&>(*bp); // succeeds

	According to the wording in paragraph 8, the cast above should fail.
Resolution:
Requestor:
Owner:          Bill Gibbons (RTTI)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   483
Title:          What does a compiler know about type_info if the header isn't
                included?
Section:        5.2.7 [expr.typeid] Type identification
Status:         closed
Description:
	If you don't include <typeinfo> and you do a typeid(...), do you get 
        an error ("<typeinfo> must be included before using typeid")?
	Or is the type type_info built-in in some way?  
	If so, why do we define it in a header?  
	Or perhaps the compiler predeclares type_info, but you have to 
	include the header to get the definition, which means you could do a
        typeid(...) but then you couldn't do much with the result because
        type_info is incompletely-defined.
Resolution:
	See Tokyo motion 12).
	"If <typeinfo> (_lib.type.info_) has not been included prior to a use
	 of typeid, typeid returns an lvalue of type const std::type_info, 
	 but the class std::type_info is considered incompletely defined and
	 is not visible by name at that point."
Requestor:	Steve Adamczyk 
Owner:          Bill Gibbons (RTTI)
Emails:         	
	core-5463
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   588
Title:          When is it determined that the operand of typeid is a 
                polymorphic type?
Section:        5.2.7 [expr.typeid] Type identification
Status:         closed
Description:
	5.2.7[expr.typeid] says:
	"If the expression is an lvalue of polymorphic type(10.3) ... "
	"If the expression is neither a pointer nor a reference to a
         polymorphic type ...."

	If the relevant type is incomplete at the point of the typeid, do you
        determine "being a polymorphic type" by some kind of search for the 
        typename at runtime or do you just assume it isn't.

	class X;
	X* p;
	... typeid(p) ...

	Jerry indicates:
	"My memory of the discussion surrounding RTTI was that you need to do
	 the search, but I can't find anything in the WP that confirms my
	 recollection."
Resolution:
	See Tokyo motion 12).
Requestor:	Jerry Schwarz
Owner:          Bill Gibbons (RTTI)
Emails:
	ext-3368
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   550
Title:          Minor clarifications on the conversions a static_cast can
                performed
Section:        5.2.8[expr.static.cast]
Status:         editorial
Description:
	Issue 1)
	paragraph 6 says:
	"The inverse of any standard conversion ...  can be performed
         explicitly using a static_cast..."

	Shouldn't this be:
	"The inverse any standard conversion sequence ..."
	since more than just a single standard conversion can result from a
        static_cast.

	Issue 2)
	paragraph 6 says:
	"The inverse of any standard conversion, other than ...  can be
	 performed explicitly using a static_cast..."

	The 'other than' list does not list the conversion from an rvalue of
	base class type to rvalue of derived class type. 
	It either should or the semantics of this cast should be described
	in 5.2.8, specially given that an implicit conversion from an rvalue
        of derived class type to an rvalue of base class type involves
        calling the base class copy constructor.
Resolution:
	At the Tokyo meeting, the core WG decided to handle issue 1) as
	an editorial matter; issue 2) will be handled as part of issue 547
	for which Steve Adamczyk will prepare a paper for the Scotts Valley
	meeting.
Requestor:
Owner:          Steve Adamczyk
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   543
Title:          Can volatile be cast away using static_cast or
                reinterpret_cast?
Section:        5.2.8 [expr.static.cast]
                5.2.9 [expr.reinterpret.cast]
Status:         closed
Description:
	5.2.8 para 1 says:
	  "The static_cast cannot cast away constness."
	5.2.9 para 2 says:
	  "The reinterpret_cast cannot cast away constness."

	Can it be used to cast away volatile?
	  void f(const int *);
          void g(volatile void *p) { 
            f(reinterpret_cast<const int*>(p));
          }
Resolution:
	The term cast-away constness defined in 5.2.10 [expr.const.cast]
	paragraph 6 is already defined to cover casting away volatile.
Requestor:	Tom Holladay
Owner:          Steve Adamczyk (Type Conversions)
Emails:
	core-5967
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:	486
Title:          Can a value of enumeration type be converted to pointer type?
Section:        5.2.9 [expr.reinterpret.cast]
Status:         editorial
Description:
	5.2.9 p5 says:
	"A value of integral type can be explicitly converted to pointer
         type."
	Can a value of enumeration type be explicitly converted to pointer
        type?
Resolution:
	This is a substantive change to which the Core WG agreed to during
	the Thursday session of the Tokyo meeting. 
	Add to the sentence above: 
	"... of integral type or enumeration type..."

	I will add this to the WP as an editorial proposal (with change
	box to identify the change).
Requestor:      Bill Gibbons
Owner:	        Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   487
Title:          Conversions to pointer to member functions need to be changed
	        to allow covariant return types
Section:        5.2.9 [expr.reinterpret.cast]
Status:         editorial
Description:
	5.2.9 p11 says:
	"Calling a member function through a pointer to member that 
	 represents a function type that differs from the function type 
	 specified on the member function declaration results in undefined 
	 behavior."

	This needs to be clarified wrt pointer to member functions that 
	differ because they represent virtual functions that differ only 
	because of their covariant return type.

        Proposal:
	Add at the end of paragraph 2:
	  "... (except that an overriding virtual function with a different 
	   return type may be called (10.4))." 

	Erwin Unruh also notes:
	There are implicit conversions, which alter the type of a 'pointer to
 	member function' according to the class of which it is a member. 
	How does it interact with this sentence?
Resolution:
	At the Tokyo meeting, the core WG decided to handle this as an 
	editorial matter.
Requestor:      Bill Gibbons
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   538
Title:          Are user-defined conversions invoked as the result of a
                reinterpret_cast?
Section:        5.2.9 [expr.reinterpret.cast]
Status:         active
Description:
        struct A {
          operator void* ();
        } a;

        main() {
          int i = reinterpret_cast<int>(a);
        }

        Is A::operator void* invoked as the result of the reinterpret_cast?
Resolution:
	Steve Adamczyk will write a paper on this subject for the Scotts
	Valley meeting.
Requestor:      Jason Merrill
Owner:          Steve Adamczyk (Type conversions)
Emails:
        core-5913, core-5939 and following messages.
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   559
Title:	        Are pointer-to-derived -> pointer-to-base conversions
                performed with a reinterpret_cast?
Section:        5.2.9 [expr.reinterpret.cast]
Status:         editorial
Description:
	paragraph 6 says:
	"The operand of a pointer cast can be an rvalue of type 'pointer to
	 incomplete class type'.  The destination type of a pointer cast
	 can be 'pointer to incomplete class type'.  In such cases, if there
	 is any inheritance relationship between the source and the
	 destination classes, the behavior is undefined."

	This paragraph should be deleted.  It is misleading.
	With reinterpret_cast, there are never any pointer value
	adjustments, even when the pointers point to class types with an
	inheritance relationship.  So there is nothing special when pointers
	to incomplete class types are operands of a reinterpret_cast.
Resolution:
	At the Tokyo meeting, the core WG decided to handle this as an
	editorial matter.
Requestor:
Owner:          Steve Adamczyk (Type conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   560
Title:          Can a reinterpret_cast add cv-qualifiers?
Section:        5.2.9 [expr.reinterpret.cast]
Status:         editorial
Description:
	paragraph 8, 10 and 12 do not say whether the cv-qualifiers on the
	types must be exactly the same or whether they may differ (as long
	as casting away constant is not performed, as required by
	paragraph 2).

	Reading these paragraphs, I believe the intent is that, in a
	reinterpret_cast, the cv-qualifiers of the source type must be 
	exactly the same as the cv-qualifiers of the target type.  If this is
	the case, I believe this should be stated explicitly.
Resolution:
	At the Tokyo meeting, the core WG agreed that the intent was as 
	follows:
	 A pointer to T1 can be cast to a pointer to T2 using a 
	 reinterpret_cast if this cast does not cast away constness (i.e.
	 if the cast does not remove cv-qualifiers; this is already implied 
	 in paragraph 2 of 5.2.9). The 1st level cv-qualifiers are ignored.

	This will be handled as an editorial matter.
Requestor:
Owner:          Steve Adamczyk (Type conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   593
Title:          syntax for prefix ++ operator
Section:        5.3 [expr.unary]
Status:         active
Description:
	The grammar indicates:
		unary-expression ::= ++ unary-expression
	This seems to make things like ++(int&)x  ill-formed.
Proposed Resolution:
		unary-expression ::= ++ cast-expression
Resolution:
Requestor:	Jerry Schwarz
Owner:          Anthony Scian
Emails:
	core-6231
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   453
Title:          Can operator new be called to allocate storage for
	        temporaries, RTTI or exception handling?           
Section:        5.3.4 [expr.new] New
Status:         active
Description:
        Is it permitted for an implementation to create temporaries on the
        heap rather than on the stack?  If so, does that require that 
	operator new() be accessible in the context in which such a temporary
	is created?

        Is an implementation allowed to call a replaced operator new whenever
        it likes (storage for RTTI, exception handling, initializing static 
	in a library)?

	Core 1 discussed this issue in Monterey.
	This is the resolution the WG seemed to converge towards:
	  The storage for variables with static storage duration, for data
	  structures used for RTTI and exception handling cannot be acquired 
          with operator new.

	  global operator new/delete (either the user-defined ones or the
	  implementation-supplied ones) will only be called from new/delete
	  expressions and by the functions in the library.

Proposed Resolution:
        The C standard says the following:
        See 6.1.2.4 (storage durations of objects):

         o For objects of static storage duration:
            "For such an object, the storage is reserved ...  prior to 
	     program start up.
           The C++ standard should probably say something like this in 
	   section 3.7.1 [basic.stc.stc].

         o For objects of automatic storage duration:
            "Storage is guaranteed to be reserved for a new instance of such
             an object on each normal entry into a block with which it is
             associated, or on a jump from outside the block to a labeled
             statement in the block or in an enclosed block.  Storage for the
             object is no longer guaranteed to be reserved when execution of
             the block ends in any way.  (Entering an enclosed block suspends
             but does not end execution of the exclosing block.  Calling a
             function suspends but does not end execution of the block
             containing the call."
          The C++ standard should probably say something like this in section
          3.7.2 [basic.stc.auto].

        The C++ standard should also indicate the following restrictions:
          12.2 [class.temporary] should probably indicate that the storage
          for temporaries is not allocated by operator new.

          5.2.6[expr.dynamic.cast], 5.2.7[expr.typeid] and 15[except] should
          probably indicate that the storage for the data structures required
          for RTTI and exception handling is not allocated by operator new.

	I will write a paper for the Scotts Valley meeting.
Resolution:
Requestor:      Mike Miller
Owner:          Josee Lajoie (New)
Emails:
        core-5068
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   561
Title:          How does initialization proceed when a new expression creates
                a pointer-to-member?
Section:        5.3.4 [expr.new] New
Status:         closed
Description:
	paragraph 14 says:
	"If the type of the object created by the new-expression is T:
	 ...
	 - If the new-initializer is omitted and T is a POD type, then the
	   object thus created has indeterminate value;
	"

	Shouldn't this apply to pointer to members as well?
Resolution:
        At the Tokyo meeting, the core WG decided to adopt Bill Gibbons' 
        paper 95-0174/N0774, Definitions of "scalar type" and "fundamental 
        types" as editorial work.
        As a result of this, pointer-to-members are now scalar types and 
        are covered by the rules above.
Requestor:
Owner:          Bill Gibbons (pointer-to-members)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   577
Title:          Are there any requirements on the alignment of the pointer
	        used with new with placement? 
Section:        5.3.4 [expr.new] New
Status:         active
Description:
	For example, 12.4 para 10 gives examples of placement new used with
	a buffer created as follows:
		class X { };
		static char buf[sizeof(X)];
	Is the alignment of a static array of char guaranteed to satisfy the
	alignment requirements of an arbitrary class X?
Resolution:
Requestor:	public comment T26
Owner:	        Josee Lajoie (Memory Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   416
Title:          Can a delete expression be of abstract type?
Section:        5.3.5 [expr.delete] Delete
Status:         closed
Description:    
	Ron would like to see the following rules apply to the 
	cast-expression of a delete expression:
                The referent type of the cast-expression may be an 
                abstract class type, provided that this type was earlier
	        defined to contain a virtual destructor.
Resolution:
	See the resolution for issue 417 which covers this issue as well.
Requestor:      Ron Guilmette
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   470
Title:          deleting a pointer allocated by a new with placement
Section:        5.3.5 [expr.delete] Delete
Status:         active
Description:
	5.3.5 p2 says:
	"... in the first alternative (delete object), the value of the
	 operand of delete shall be a pointer to a non-array object created
	 by a new-expression without a new-placement specification, ..."

	In some situations, it is well-defined what happens even when new
	with placement was called. Do we want to prohibit these cases?
	
	Erwin Unruh also notes:
	The deletion of a pointer gained by a placement new must be allowed. 
	Using the default operator delete for a pointer gained by the library 
	placement new is undefined. However, a user may write placement news 
	that allocate storage in which case using delete on a pointer 
	returned by such a placement new should be well-defined.
Proposed Resolution:
	Replace 5.3.5[expr.delete] p2 to say:
	  "...  in the first alternative (delete object), the value of the
	   operand of delete shall be a pointer to a non-array object created
	   by a new-expression, ...  In the second alternative (delete 
	   array), the value of the operand of delete shall be a pointer to 
	   an array created by a new-expression.  If not, the behavior is 
	   undefined.  In either alternative, if the operand of the delete 
	   expression is a pointer to an object created by a new expression 
	   with a new-placement specification, and if the library operator 
	   new with placement was used to allocate the storage, the behavior
	   of the delete expression is undefined."

	Mike Miller and Erwin Unruh will provide a paper for the Scotts 
	Valley meeting (March 1996).
Resolution:
Requestor:	Jason Merrill 
Owner:          Mike Miller (new / delete)
Emails:
	core-5569, core-6227
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   471
Title:          When can an implementation change the value of a delete 
		expression?         
Section:        5.3.5 [expr.delete] Delete
Status:         editorial
Description:
	5.3.5p4
        "If the expression denoting the object in a delete-expression is a 
         modifiable lvalue, any attempt to access its value after the 
	 deletion is undefined."

	ISSUE 1):
 	When can an implementation change the pointer value of a delete 
 	expression?

	inline void* operator new(void* p) { return p; }
	struct Base { virtual ~Base() {} };
	struct Immortal : Base {
		operator delete(void* p) { new(p) Immortal; }
	};

	main()
	{
		Base* bp = new Immortal;
		delete bp;
		delete bp;
		delete bp;
	}

	Is the above well-formed?    

	Once this issue is resolved, 3.7.3.2 [basic.stc.dynamic.deallocation]
	para 4 and 5 will also need to be clarified.

        -----
	Issue 2):

	Also, 
	
	int *a, *b, *c;
	a = b = new int;
	c = b; //1
	c = a; //2

	because the sentence above discusses lvalues, it implies that
	//1 is OK but //2 is undefined ! 

	----
	Issue 3):
	
	Also, the first sentence of this paragraph says:
	"It is unspecified whether the deletion of an object changes its 
         value."

	After deletion has completed, there is no object anymore...
	So saying that the value of the object may have changed as the 
        result of the deletion is somewhat useless. This sentence
	repeats what is already specified in 3.8[basic.life] and should be
	deleted from 5.3.5.
Resolution:
	At the Tokyo meeting, the Core WG agreed on the following resolutions
	for issue 1), 2) and 3):

	Issue 1) was rejected.
	The implementation cannot always tell when processing the delete 
	expression whether the implementation global operator delete, the 
	user global operator delete or the class operator delete will be 
	called. Therefore, the limitation described in 5.3.5 paragraph 4:
         "If the cast-expression in a delete-expression is a modifiable 
	  lvalue, any attempt to access its value after the completion of
	  the delete-expression is undefined."
	will remain true in all cases.

	Issue 2) and 3) will be handled as editorial matter.
Requestor:	Nathan Myers
Owner:          Josee Lajoie (Memory Model)
Emails:
        core-5565
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   93
Title:          Deleting the "current object" (this) in a member function
Section:        5.3.5 [expr.delete] Delete
Status:         editorial
Description:
        In a standard conforming program, may delete be used within a
        non-static member function (or within a function which is called
        directly or indirectly by such a function) to delete the object for
        which the non-static member function was called?

        Example:

        struct S { void member (); };
        void delete_S (S *arg) { delete arg; }
        void S::member ()
        {
                delete_S (this);
        }

        If this is prohibited in a standard conforming program is a standard
        conforming implementation required to issue a diagnostic for such 
	code?

	Proposal:
        The WP should say somewhere that accessing memory after is has been 
	deallocated results in undefined behavior.
Resolution:
	3.7.3.2 will be modified to say:
	  "If the argument given to a deallocation function is a pointer that
	   is not the null pointer constant, the deallocation function will
	   deallocate the storage referenced by the pointer and render the
	   pointer invalid.  The value of a pointer that refers to 
	   deallocated storage is indeterminate.  Any attempt to access the 
	   value of a pointer that points to deallocated storage is 
	   undefined."             

	This will take care of Ron's issues described here.
Requestor:      Ron Guilmette
Owner:          Josee Lajoie (Memory Model)
Emails:
        core-1650
Papers:
        94-0185/N0572
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   545
Title:          Which 'static_cast' or 'reinterpret_cast' conversions are
                performed using the old style casts?
Section:        5.4 [expr.cast]
Status:         closed
Description:
	5.4 says:
	"The conversions performed by static_cast, reinterpret_cast, 
	 const_cast, or any sequence theresof, can be performed using the 
         cast notation of explicit type conversion."

	Since static_cast and reinterpret_cast have different sementics, 
	which type conversions are allowed/disallowed using old style casts?

	Is this allowed?
	  struct A { };
	  struct B : public A { };
	  struct Ptr {
	    operator A* () { return 0; }
	  };

	  int main ()
	  {
	    Ptr p;
	    (B*)p; // allowed?
	    // since this can be interpreted as:
	    // static_cast<B*>(static_cast<A*>(p));
	  }                                           
Resolution:
	The last sentence in 5.4 paragraph 4 already covers this.
Requestor:      Jason Merrill
Owner:          Steve Adamczyk (Type Conversions)
Emails:
	core-6114
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   563
Title:          Which "inaccessible" conversions are allowed using old style
	        casts?
Section:        5.4 [expr.cast]
Status:         editorial
Description:
	paragraph 5 says:
	"In addition to those conversions, ..."

	Are the following conversions allowed as well?
	o pointer to (lvalue of) a private base class to a pointer to
          (lvalue of) a derived class?
	o pointer to member of private base class to pointer to member of
	  derived class?
	o pointer to member of derived class to pointer to member of private 
          base class?
Resolution:
	At the Tokyo meeting, the core WG decided to address this issue as
	an editorial matter.
Requestor:
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   488
Title:          Can a pointer to a mutable member be used to modify a const
                class object?
Section:        5.5 [expr.mptr.oper]
Status:         active
Description:
	5.5 p4 says:
	"The restrictions on cv-qualification, and the manner in which 
	 cv-qualifiers of the operands are combined to produce the 
  	 cv-qualifiers of the result, are the same as the rules for E1.E2..."
	
        It should be noted that a pointer to member that refers to a mutable 
	member cannot be used to modify a const class object.

        struct S {
          mutable int i;
        };
        const S cs;
        int S::* pm = &S::i;
        cs.*pm = 88;
Proposed Resolution:
	Add a note at the end of p4: 
	"Note: a pointer to member that refers to a mutable member cannot be 
         used to modify a member of an object of const class type."
Resolution:
Requestor:      Bill Gibbons
Owner:          Bill Gibbons (pointer to member)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   600
Title:          Should the value returned by integer division and remainder
	        be defined by the standard?
Section:        5.6 [expr.mul]
Status:         active
Description:
	ISO Swedish comment R-26:
	Division of negative integers [expr.mul]  Paragraph 4: The value 
	returned by the integer division and remainder operations shall be 
	defined by the standard, and not be implementation defined.  The
	rounding should be towards minus infinity.  E.g., the value of the C
	expression (-7)/2 should be defined to be -4, not implementation
	defined.  This way the following useful equalities hold (when there 
	is no overflow, nor "division by zero "):

	(i+m*n)/n == (i/n) + m for all integer values m
	
	(i+m*n)%n == (i%n) for all integer values m

	These useful equalities do not hold when rounding is towards zero.
	If towards 0 is desired, it can easily be defined in terms of the
	round towards minus infinity variety, whereas the other way around is
	trickier and much more error-prone.
Resolution:
Requestor:	Swedish Delegation
Owner:          
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   597
Title:          Should the results of the + or - operators be well-defined if
	        one operand is a null pointer and the other is the value 0?
Section:        5.7 [expr.add]
Status:         closed
Description:
	The WP does not currently say what the result of the following 
	operations is:
		(char*)0 + 0 == (char*)0
		(char*)0 - (char*)0 == 0

	In core-6234, Andrew Koenig says:
	"Without this, it is impossible to use the pair (0,0) to indicate an 
         empty range, for example.  Moreover, I suspect that otherwise null 
         pointers fail to meet the requirements for random access iterators.

	 Consider the following loop, where p and q are pointers:

		while (p < q) {
			f(*p);
			++p;
		}

	 One would think it possible to rewrite it as follows:

		int n = q - p;
		for (int i = 0; i < n; ++i)
			f(p[i]);

	 but this plausible rewrite fails if p and q are both zero?"
Resolution:
	See Tokyo motion number 8).
	Add to 5.7, after paragraph 6, the following new paragraph:

	"If the value 0 is added to or substracted from a pointer value,
	 the result compares equal to the original pointer value. If two 
	 pointers point to the same object or function or both point 
	 one past the end of the same array or both are null, and the two
	 pointers are substracted, the results compares equal to the value
	 0 converted to the type ptrdiff_t."
Requestor:	Andrew Koenig
Owner:	        Josee Lajoie (Memory Model)
Emails:
	core-6234
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   596
Title:          What is the result of a relational operator if only one 
                operand is a null pointer?
Section:        5.9 [expr.rel] Relational Operators
Status:         editorial
Description:
	Issue 1)
	para 2 says:
	"If two pointers to the same type point to different objects or
         functions, or only one of them is null, they shall compare unequal."

	Given:
		(char*)0 >= p   // 1
		(char*)0 < p    // 2

	If p is not a null pointer, what is the result of //1 and //2 if p 
	shall compare unequal with a null pointer?
	Is it undefined? Or well-defined and false?

	Issue 2)
	para 2 also says:
	"If two pointers to the same type point to the same object or 
         function or ... are both null, they compare equal."

		(char*)0 >= (char*)0 //3
		(char*)0 < (char*)0  //4

        The current wording indicates that //3 is well-defined and true.
	What about //4? Is it undefined or well-defined and false?
	
	It seems that rather all should be defined or all undefined.	
Resolution:
	At the Tokyo meeting, the core WG decide to resolve this issue 
	as an editorial matter.
	
	Issue 1)
	This sentence will be deleted.
	This case will be covered by the general rule: "all pointer 
	conversions not explicitly covered by the rules in paragraph 2
	are unspecified."
	
	Issue 2)
	This sentence will be modified to say that if "two pointers to 
	the same type point to the same object or function or ... are 
	both null," the result of <= and >= is true while the result of
	< and > is false.
Requestor:	Nathan Myers
Owner:	        Josee Lajoie (Memory Model)
Emails:
	core-6233
Papers:       
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   493
Title:          Better description of the cv-qualification of the result of a
	        relational operator needed
Section:        5.9 [expr.rel] Relational Operators
Status:         active
Description:
	5.9p2 says:
	"Pointer conversions are performed on the pointer operands to bring 
	 them to the same type, which shall be a cv-qualified or
	 cv-unqualified version of the type of one of the operands."

	This seems to imply that the result has exactly the type of one of 
	the operands, or an unqualified version of that type.  In fact, the 
	common type may have more qualifiers than either operand type.

	[Note JL:
	 for example the following is allowed in C: 
	   const int* pci;
	   const volatile* pvi;
	   if (pci == pvi) { }
	]
Proposed Resolution:
	Steve Adamczyk will write a paper on cv-qualifiers and operand  
	types to be available for the Scotts Valley meeting (March 96).
Resolution:
Requestor:      Bill Gibbons
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   513
Title:          Are pointer conversions implementation-defined or 
	        unspecified?
Section:        5.9 [expr.rel] Relational Operators
Status:         closed
Description:
	5.9p2 last '--' says:
	"Other pointer comparisons are implementation-defined."
	
	Comparison of unrelated pointers should be unspecified or undefined. 
	At present it reads implementation defined, but I doubt that the 
	exact rules can be described by a compiler vendor.
Resolution:
	See Tokyo motion 8).
        Change the text above to say:
        "Other pointer comparisons are unspecified."
Requestor:	Erwin Unruh
Owner:	        Josee Lajoie (Memory Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   472
Title:          lvalue-> rvalue transformation for the operands of the 
                conditional operator needs better description
Section:        5.16 [expr.cond] Conditional operator
Status:         editorial
Description:
	It is not clear when the lvalue-> rvalue transformation takes place 
	on the operands of the conditional operator.

	Paragraph 2 says that if the second and third operands of the
	conditional operator do not have the same type, the
	lvalue-to-rvalue conversion takes place.  Then later on in 
	paragraph 3 it says:
	 "...  if both the second and the third expressions are _lvalues_
	  of related class types ..."
	which cannot be true if the lvalue-to-rvalue conversion has already
	taken place.

	Either paragraph 2 should say that the lvalue-to-rvalue conversion
	does not take place if the second and third operands are of related
	class types, or paragraph 3 should say that the operands are
	rvalues.  If I understand things correctly, I believe it should be
	the former.

	----
	Also, does the phrase "same type" in paragraph 2 includes
	cv-qualifiers? That is, is the following well-formed?

        const int i = 88;
        volatile int j = 99;
        const volatile *p = &((1) ? i : j); 
Resolution:
	At the Tokyo meeting, the Core WG decided to handle this issue as an 
	editorial issue. 
Requestor:
Owner:          Steve Adamczyk (Type conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   496
Title:          The cv-qualification of the result of the conditional 
	        operator needs better description
Section:        5.16 [expr.cond] Conditional operator
Status:         active
Description:
        5.16p3 says:
        "...pointer conversions are performed on the pointer operands to 
	 bring them to a common type, which shall be a cv-qualified or
	 cv-unqualified version of the type of either the second or the third
	 expression.
         ...
         if both the second and the third expressions are lvalues of related
	 class types, they are converted to a common type (which shall be
	 a cv-qualified or cv-unqualified version of the type of either the
	 second or the third expression)..."
         
        This seems to imply that the result has either exactly the type of 
	the second or third expression, or the unqualified version of that 
	type.  In fact, the common type may have more qualifiers than either
	operand type.
Proposed Resolution:
        This issue will be addressed in a paper Steve Adamczyk will write on
        cv-qualifiers and operand types (to be available for the Scotts 
	Valley meeting (March 96)).
Resolution:
Requestor:      Bill Gibbons
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   497
Title:          The conversion applied to operands of the conditional 
	        operator of class type needs to be better described
Section:        5.16 [expr.cond] Conditional operator
Status:         editorial
Description:
	5.16p3 says:
	"... if the second and the third expressions are lvalues of related
	 class types..."
	The term "related class type" is not defined.
Resolution:
	At the Tokyo meeting, the Core WG decided to handle this issue as an 
	editorial issue. 

        The sentence above should be changed to say:
	"... are lvalues of class type, and one class is an unambiguous 
	 public base of the other, ..."
Requestor:      Bill Gibbons
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   609
Title:	        Is "bitfield" an attribute remembered when a bitfield is used
	        as the right operand of a comma operator?
Section:        5.18 [expr.comma]
Status:         active
Description:
	Given:
		struct B {
			unsigned bit:2;
		};
		B b;
		void f(int);	
		void f(unsigned int);	
		... f(((0, b.bit)+1)) ...

	Is the bitfield attribute remembered when the type of the right 
	hand expression becomes the resulting type of the comma expression? 
	This will influence how the resulting type of the comma expression
	promotes.
Requestor:
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   537
Title:          Can the implementation accept other constant expressions?
Section:        5.19 [expr.const] Constant expressions
Status:         active
Description:
	The C standard says, in its section on constant expressions:
        "An implementation may accept other forms of constant expressions."
	Should C++ say the same thing?

	In particular, implementations often accept extended forms of
	constant expressions in order to support 'offsetof', defined as
	returning an 'integral constant expression'. Are implementations
	prohibited to accept other forms of 'integral constant expressions',
	expressions which the WP does not describe as constant expressions?

	If, in C++, implementations are not allowed to extend the set of
        constant expressions, then the C compatibility appendix should list
	this as an incompatibility.
Resolution:
Requestor:	Dave Hendricksen
Owner:          Tom Plum (C compatibility)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   610
Title:          Is a string literal considered a constant expression for
	        the purpose of non-local static initialization?
Section:        5.19 [expr.const] Constant expressions
Status:         active
Description:
	In 5.19, paragraph 2 provides a list of expressions that can be used
	as constant expressions for the purpose of non-local static 
	initialization (only). Should string literals be included in that 
	list?

	Or be in the list of expressions that can be used in an address
	constant expression (i.e. para 4)?
Resolution:
Requestor:	Tom Plum
Owner:          Josee Lajoie (Initialization)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 6 - Statements
------------------------
Work Group:     Core
Issue Number:   524
Title:          Exactly when are objects of static storage duration 
	        destroyed?
Section:        6.7 [stmt.dcl] Declaration statement
Status:         closed
Description:
	6.7p5 says:
	"The destructor is called either immediately before or as part of the
	 calls of the atexit functions."

	What if the atexit function is not called?
Resolution:
	See Tokyo motion 7b).
Requestor: 	Sean Corfield
Owner:          Josee Lajoie (Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:	Core
Issue Number:	132 (WMM.83)
Title:		Consistency between "::" and "Class::" in declarations
Section:	6.8 [stmt.ambig] Ambiguity resolution
Status:		active 
Description:
	WMM.83. Is a change necessary for syntactic consistency between the 
	treatment of "::" and "class::" in declarations?

	float a;
	float b;
	main(){
		int (a)  ; // valid block scope redeclaration of a
		int (::b); // valid function like cast of b
	}
	Note that the reason for the "function like cast" interpretation is
	that "::b" can *only* be used as a reference, and never used as a
	declarator. 

	struct T { static a;};
	int (T::a); // valid declaration and definition of T::a
	main(){
		int (T::a);  // semantic error: attempt to redeclare T::a
		(int)(T::a); // cast of T::a
	}
	Since the syntax allows "T::a" to be used as a declarator, the
	statement: int (T::a); is interpreted as a declaration even though
	this declaration is not valid at block scope.
	And eventhough the statement: int (T::a); is an invalid block scope
	declaration, it is not interpreted as an expression because it is
	validated as a declaration by the grammar. 

	Should the syntax "Class::" always be interpreted as a reference 
	instead of a part of a declaration when placed inside block scope? 
Resolution:
Requestor:	Mike Miller / Jim Roskin
Owner:          Anthony Scian (Syntax)
Emails:
	core-629
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   424
Title:          Must disambiguation update symbol tables?
Section:        6.8 [stmt.ambig] Ambiguity resolution
Status:         active
Description:
	The question is about the following sentence from 6.8p3 [stmt.ambig]

	WP> The disambiguation is purely syntactic; that is, the meaning of
	WP> the names, beyond whether they are type-ids or not, is not used
	WP> in the disambiguation.

	On the one hand, this would imply that a trial parser needn't update
 	a symbol table, since that would be processing that is not purely 
	syntactic.

	On the other hand, some input would be disambiguated differently if
	the symbol table were updated during trial parsing.  Symbol table
	updates would determine which names will be type-ids during the
	actual parse.

	To be more concrete and specific about the problem, consider the 
	statement in main() in the enclosed test case.  Should this be 
	disambiguated as a declaration with a syntax error, or should it be 
	disambiguated as a well-formed expression?

	struct T1
	{
	        T1 operator()(int x) { return T1(x); };
	        int operator=(int x) { return x; };
                T1(int) {};
	};
	struct T2
	{
	        T2(int) {};
	};
	int a, (*(*b)(T2))(int), c, d;
	void main ()
	{
        	// Is the following a declaration with a syntax error?
                // Or is it a semantically valid expression?
                T1(a) = 3,
	        T2(4),
	        (*(*b)(T2(c)))(int(d));
	}
Resolution:
Requestor:      Neal M Gafter <gafter@mri.com>
Owner:          Anthony Scian (Syntax)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
Chapter 7 - Declarations
--------------------------
Work Group:     Core
Issue Number:   213
Title:          Should vacuous type declarations be prohibited?
Section:        7 [dcl.dcl] Declarations
Status:         active
Description:
	"A declaration introduces one or more names into a program and
	 specifies how those names are to be interpreted."

	Is this intended to prohibit empty declarations like these?
                enum { };
                class { int i; };
                class { };
                typedef enum {};
	In this case the WP should be clearer.

	[Jerry Schwarz also notices:]
	However, this can also be interpreted as prohibiting the following:
		extern int i;
		extern int i;
	since the second declaration does not introduce anything (the name 
	has already been introduced in the program).  
Resolution:
Requestor:      Tom Plum / Dan Saks
Owner:	        Steve Adamczyk (Types)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:	Core
Issue Number:	116 (WMM.65)
Title:          Is "const class X { };" legal?
Section:        7.1.5 [dcl.type]  Type Specifiers
Status:		active
Description:
	Is "const class X { };" legal, and, if so, what does it mean?
	i.e. if the declaration does not declare a declarator and a storage 
	class specifier or a cv-qualifier is specified, are these simply 
	ignored or is the declaration ill-formed?
Resolution:
Requestor:      Mike Miller
Owner:          Steve Adamczyk (Classes)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   564
Title:          is 'void f(const a);' well-formed?
Section:        7.1.5 [dcl.type]  Type Specifiers
Status:         active
Description:
	The working paper says, in 7.1.5 para 3:

	"At least on type-specifier is required in a function declaration
	 unless it declares a constructor, destructor or type conversion
	 operator.56)
	 56) There is no special provision for a decl-specifier-seq that
	     lacks a type-specifier. The "implicit int" rule of C is no
	     longer supported."

	 Annex C gives the following example:
	   "void f(const parm); // invalid C++"

	 A cv-qualifier (like const in the example above) is a
	 type-specifier.  So, according to the rule above, the example is
	 valid, i.e. a declaration that has only cv-qualifiers in its
	 type-specifier is valid according to 7.1.5.

	 Is the rule in 7.1.5 incorrect or is the example incorrect?
Resolution:
Requestor:
Owner:          Steve Adamczyk (Types)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   503
Title:          Better semantics of bitfields of enumeration type needed
Section:        7.2 [dcl.enum] Enumeration declarations
Status:         active
Description:
	7.2p5 describes the underlying type of enumeration types.
	It should be made clear that this description does not apply to 
	the underlying type of enumeration bit-fields.

	Also, something should be said about the signedness of enumeration
        types.  Bill Gibbons's suggested words:
	"Even though the underlying type of an enumeration type will be
         either signed or unsigned, enumerations themselves are neither 
	 signed nor unsigned.  [For example, a two-bit bit-field can hold an
	 enumeration with values {0,1,2,3}.]" 
Resolution:
Requestor:	Bill Gibbons
Owner:          Steve Adamczyk (Types)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   474
Title:          Lookup of namespace names in alias declarations
Section:        7.3.2 [namespace.alias]
Status:         closed
Description:    
	Are names used in namespace-alias-definitions looked up only as
	namespace names?

                namespace very_long_name { }

		void f() {
			int very_long_name;
			namespace VLN = very_long_name;  //1
		}

	Does the namespace-alias-definition on line //1 find the namespace 
	name very_long_name declared in global scope?
	Or is the declaration in error?

	Proposal:
	When looking up the names mentioned in the 
	qualified-namespace-specifier of a namespace-alias-definition,
	only namespace names are looked up.
Resolution:
	See Tokyo motion 11) and paper 95-0212/N0812 issue 1.8.
Requestor:
Owner:          Steve Adamczyk (Name lookup) 
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   591
Title:          Can a using declaration be applied to a 
	        constructor/destructor?
Section:        7.3.3 [namespace.udecl]
Status:         closed
Description:
	class A {
	public:
		A(int);
		A(char*);
	};

	class B : A {
	public:
		using A::A;
		B(B*);
	};                    

	[Erwin Unruh, ext-3407]:
	"I would like to have an explicit statement, that the following 
         functions can not be 'used' because they already have special 
         treatments regarding their declaration: constructors, the 
	 destructor, copy assignment operators."
Resolution:
	See Tokyo motion 11) and paper 95-0212/N0812 issue 1.6.
Requestor:      Bjarne
Owner:          Bill Gibbons (Namespaces)
Emails:
	ext-3406
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   475
Title:          Lookup of namespace names in using directives
Section:        7.3.4 [namespace.udir]
Status:         closed
Description:    
	Are names used in using directives looked up only as namespace names?

		namespace NS { }
		
		void f() {
			int NS;
			{
				using namespace NS; //1
			}
		}

	Does the using directive on line //1 find the namespace name NS in
	global scope?

	Proposal:
        When looking up the names mentioned in using directives, only
	namespace names are looked up.
Resolution:
	See Tokyo motion 11) and paper 95-0212/N0812 issue 1.8.
Requestor:
Owner:          Steve Adamczyk (Name lookup)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   78 (also WMM.38)
Title:          Linkage specification and calling protocol
Section:        7.5 [dcl.link] Linkage Specifications
Status:		active
Description:
	extern "C" {
		// Typedef defined in extern "C" blocks:
		// What is the linkage of the function pointed at by 'fp'?
		typedef int (*fp)(int);

		// Type of a function parameter: 
		// What is the linkage of the function pointed at by 'fp2'?
		int f(int (*fp2) (int));

		// Can function with C linkage be defined in extern "C"
	        // blocks?
                int f2(int i) { return i; } 

		// Can static function with C linkage be defined in
		// extern "C" blocks?
                static int f3(int i) { return i; } 
	}
	If function declarations/definitions placed inside the extern "C"
	block have different properties from the ones placed outside these 
	blocks,  many areas of the C++ language will have to be aware of 
	difference.
	i.e. 
	a. function overloading resolution
        b. casting
		one will need to be able to cast from a pointer to a function
		with linkage "X" to a pointer to a function with linkage "Y". 
	In short, it needs to be determined to what extent the linkage is 
	part of the type system.

	[ JL: ]
		The standard should not force implementations to accept the
		following code: 
			extern "SomeLinkage" int (*ptr)();
			int (*ptr_CXX)();
			ptr_CXX = ptr; // 1
        	i.e. an implementation should be able to issue an error for
		line (// 1).

	See 95-0122/N0722 for a proposed resolution.

	Core 1 discussed this issue in Monterey. The consensus the group
	seemed to converge towards was to leave it implementation defined
	whether or not the linkage specification is part of the type.
	I will present a paper for the Tokyo meeting to propose a possible
	resolution.
Resolution:
Requestor:      John Armstrong (johna@kurz-ai.com)
Owner:          Josee Lajoie (Linkage)
Emails:
	core-1583, core-1584, core-1585, core-1586, core-1587, core-1589
	core-1590, core-1591, core-1594, core-1595, core-1597, core-1598
	core-1599, core-1608, core-1609, core-1612
        core-920 (Hansen),core-985 (O'Riordan),core-1064 (Miller)
Papers: 94-0034/N0421
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   420
Title:          Linkage of C++ entities declared within `extern "C"'.
Section:        7.5 [dcl.link] Linkage Specification
Status:         active
Description:    
	Given a declaration or definition of some C++ entity (e.g.  a data 
	member, a function member, and overloaded operator, an anonymous 
	union object, etc) whose existance within an otherwise standard 
	conforming program written in ANSI/ISO C would be a violation of the
	language rules, what is the effect of the linkage specification on 
	the declarations/definitions of the C++ specific entities:
	Example:
	extern "C" {
	        struct S {
                        int data_member;
                };
                int operator+ (S&, int);
	}
Resolution:
Requestor:      Ron Guilmette
Owner:          Josee Lajoie (Linkage)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 8 - Declarators
-------------------------
Work Group:     Core
Issue Number:   573
Title:          How does 'C()' parses when it appears as the operand of the
                typeid operator or sizeof operator?
Section:        8.2 [dcl.ambig.res]
Status:         active
Description:
	class C { };
	typeid(C()); // Is this equivalent to: typeid(C (*_fp)()) 
	             // or: typeid(_temp = C()) 
Proposed Resolution:
	It parses as: typeid(C (*_fp)()).
        This matches what happens in function parameter lists (see
        paragraph 7).
Resolution:
Requestor:      
Owner:          Steve Adamczyk (Declarators)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   567
Title:          Can a parameter have type 'T arr[]' where T is incomplete?
Section:        8.3.5 [dcl.fct] Functions
Status:         active
Description:
	Is the following valid:
	  struct T;
	  void f(T arr[]); //1
	?
	8.3.4 says:
	"As per 8.3.4, Arrays, paragraph 1, "In a declaration T D where D has
         the form "D1 [ const-expr(opt) ]" ... . T shall not be a reference
         type, an incomplete type, ...".

	Is //1 ill-formed because T is incomplete?
Proprosed Resolution:
	8.3.5 needs to say that pointer conversions do happen before the 
	check for complete types on the function parameters takes place.
Requestor:      public comment T13.1
Owner:          Steve Adamczyk (Declarators)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   482
Title:          Are cv-qualifiers allowed in a typedef for a function type?
Section:        8.3.5 [dcl.fct] Functions
status:         closed
Description:
        struct A {
                typedef void FTYPE() const;
                void f() const;
                FTYPE f1;
        };

	Do f and f1 have the same type?

	Bill Gibbons' proposed resolution:

	Since const/volatile qualifiers are part of the type of a member 
	function, they should be allowed on typedefs.  Of course if that ends 
	up putting cv qualification on a non-member, a static member, a 
	constructor or a destructor, the program is ill-formed - exactly as 
	if it were done without the typedef.

	Bill Gibbons suggested the following change to 8.3.5 [dcl.fct].
	Paragraph 3 presently says:

        "... A cv-qualifier-spec can only be part of a declaration or
         definition of a nonstatic member function, and of a pointer to
         member function; see[class.this].  It is part of the function type."

	He proposed changing it to:

        "... A cv-qualifier-spec can only be part of a declaration or
         definition of a nonstatic member function, or part of a
         pointer to member function type, or part of a typedef for a
         function type; see [class.this].  It is part of the function
         type. Typedefs of cv-qualified function types can only be used
         to declare nonstatic member functions and to form pointer to member 
	 types."
Resolution:
	See Tokyo motion 5) and paper 95-0213/N0813.
Requestor:	Bill Gibbons
Owner:          Steve Adamczyk (Declarators) 
Emails:
	core-5447
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   530
Title:	        Can default arguments appear in out-of-line member function
                definitions?
Section:        8.3.6 [dcl.fct.default] Default arguments 
status:         active
Description:
	For example
        struct X {
            void f(int);    // no default argument here
        };                                            

        void X::f(int = 3) { } // is this allowed?

        void g(X* xp) {
            xp->f();    // uses default argument from definition
        }                                                          

	This is particularly interesting when the function in question
	is a constructor. Adding default arguments outside of the class 
        definition may add a default constructor to the class.
Resolution:
Requestor:      Bill Gibbons
Owner:          Steve Adamczyk (Declarators)
Emails:
	core-5855 and following messages
Papers:
	95-0156=N0756  Default Arguments in Member Function Definition
        by John Wilkinson
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   531
Title:          Is a default argument a context that requires a value?
Section:        8.3.6 [dcl.fct.default] Default arguments
status:         active
Description:
	extern struct A a_default;
	extern struct B b_default;
	struct A {
		void f(B = b_default);
	};
	struct B {
		void f(A = a_default);
	};
	A a_default;
	B b_default;
	inline void A::f(B b) { /* ... */ }
	inline void B::f(A a) { /* ... */ }   

	Is this valid code?
	Is the default value only needed if and when the function is called 
	with less than the full number of arguments?                      
Resolution:
Requestor:	Fergus Henderson
Owner:          Steve Adamczyk (Declarators)
Emails:
	core-5884
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   586
Title:          When do access restrictions apply to default argument names?
Section:        8.3.6 [dcl.fct.default] Default arguments
status:         active
Description:
	class C {
		static int f() { return 0; }
	public:
		C( int = f() ) { }
	};
	C c; // error? C::f accessible?

	class D {
		static int f;
	public:
		D( int = f ) { }
	};
	D d; // error? D::f accessible?

	Does access checking take place when the default argument name is
	bound (at the point of the function declaration) or when the 
        default argument name is implicitly used on the call?
Proposed resolution:
        Access checking takes place when the default argument name is bound.
	That is, the example above is well-formed.
Resolution:
Requestor:      Neal M Gafter <gafter@mri.com>
Owner:          Steve Adamczyk (Declarators)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   476
Title:          Can objects with "indeterminate initial value" be referred 
	        to?
Section:	8.5 [dcl.init] Initializers
status:         closed
Description:
	8.5p6 says:
	"If no initializer is specified for an object with automatic or 
	 dynamic storage duration, the object and its subobjects, if any, 
	 have an indeterminate initial value."

	The C standard specifies that accessing a variable with indeterminate
	value results in undefined behavior, but the C++ draft contains no
	such language.
	Also, a definition of "indeterminate value" is needed in the C++ 
	standard.

	Add the following text at the ned of 8.5 paragraph 6:
	"Referring to an object with an indeterminate value results in 
	 undefined behavior."

	For the definition of indeterminate value, Steve suggests using C's 
	definition.
Resolution:
	At the Tokyo meeting, the Core WG decided to handle this as an
	editorial issue.
Requestor:	Steve Clamage
Owner:		Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   565
Title:          fine tuning of the description of type conversions used 
                during initialization needed
Section:        8.5 [dcl.init] Initializers
status:         editorial
Description:
	paragraph 12, 4th bullet, 3rd sub-bullet:
	"User-defined conversions that can convert from the source type to
	 the destination type are enumerated, ..."

	This omits to take into account that a standard conversion is
	allowed before and after the user-defined conversion, so these
	words are too strict.

	How about:
	 "User-defined conversion sequences that can convert from the
	  source type to destination type are enumerated, ..."
Resolution:
	At the Tokyo meeting, the Core WG decided to handle this as an
	editorial issue.
Requestor:
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   566
Title:          fine tuning of the description of type conversions used 
                during reference initialization needed
Section:        8.5.3 [dcl.init.ref]
status:         editorial
Description:
	paragraph 10:
	"Otherwise, a temporary of type "cv1 T1" is created and initialized
	 from the initializer expression using the rules for non-reference
         initialization (8.5)."

	Should the direct initialization or the copy initialization rules
	be used in this case?
Resolution:
	At the Tokyo meeting, the Core WG decided to handle this as an
	editorial issue.
Requestor:
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 9 - Classes
---------------------
Work Group:     Core
Issue Number:   568
Title:          Can a POD class have a static member of type
                pointer-to-member, non-POD-struct or non-POD-union?
Section:        9 [class]
Status:         active
Description:
	para 4 says:
	"A POD-struct is an aggregate class that has no members of type
	 pointer-to-member, non-POD-struct or non-POD-union (or arrays of
	 such types) or reference, and has no user-defined copy assignment
	 operator and no use-defined destructor."
	And similar wording for POD-union.

	An aggregate can have static members. 
	The wording above allows a POD class to have static members as well. 
        However, it prohibits static members of type "pointer-to-member, 
        non-POD-struct or non-POD-union (or arrays of such types) or 
        reference". Should it? 
Proposed Resolution:
	The sentence above should say: 
	"A POD-struct is an aggregate class that has no _non-static_ members
         ...."
	and similarly for POD-union.
Resolution:
Requestor:      
Owner:          (Steve Adamczyk) Types
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   252
Title:          Can the definition of an incomplete class appear in an
                anonymous union?
Section:        9.1 [class.name] Class names 
Status:         active
Description:
        must an incomplete class object be completed in the same scope?
        9.1p24   In C, a struct-or-union of incomplete type must be
        completed in the same scope as the incomplete-type declaration, or it
        remains an incomplete type.
        [We believe the same is intended for incompletely-defined classes in
        C++, but the document is not yet clear enough to tell.]

        [ Note JL: ]
        The resolution needs to clarify the following test case as well:
                class C; //1
                union {
                        class C { ... }; //2
                        ...
                };
        Does line //2 defines the class declared on line //1?
Resolution:
Requestor:      Tom Plum / Dan Saks
Owner:          (Steve Adamczyk) Name look up
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:	479
Title:          How can typedefs be used to declare member functions?
Section:        9.2 [class.mem] class members
Status:         closed
Description:
	Is this legal? 

	typedef void voidf(int);
	class foo {
		voidf vfunc;          // legal? (unsure)
		static voidf sfunc;   // legal? (I think so)
	};
	
	The type of vfunc is certainly not voidf.

	----------

	Another example from Bill Gibbons:

	struct A {
                typedef void FTYPE();
                void f();
                FTYPE f1;
        };

	Do f and f1 have the same type?

	----------
	And how does this affect pointer to members?
	More examples from Bill Gibbons:

	struct T { void f(); };
	typedef void F();
	F T::*pmf = &T::f;  // pointer to member function ?
                            // Bill's proposed answer yes. 

	struct T { void f(); };
	typedef void (*PF)();
	PF T::pmf = &T::f;  // pointer to member function ?
                            // Bill's proposed answer no.

	That is, once a declarator has been established to be a pointer to
	member, the distinction of pointer to data member or pointer to
        member function is entirely dependent on the type, not the syntax.
Resolution:
	See Tokyo motion 5) and paper 95-0213/N0813.
Requestor:	Mike Ball
Owner:          Steve Adamczyk (Types)
Emails:
	core-5374, core-5447
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   569
Title:          Is the mapping of members separated by access specifiers
	        implementation-defined or unspecified?
Section:        9.2 [class.mem] class members
Status:         closed
Description:
	Paragraph 11 says:
	"The order of allocation of nonstatic data members separated by an
	 access-specifier is implementation-defined."

	Shouldn't this be: unspecfied?
	Implementation-defined requires implementation to document how the
	members are mapped while unspecified doesn't. 
	(note: the same wording appears in 11.1 para 2).
Resolution:
	See Tokyo motion 9).
	The WP will say that this mapping is unspecified.
Requestor:	public comment 7.12
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   266
Title:          Access specifiers in union member list
Section:        9.6 [class.union] Unions
Status:         active 
Description:
	9.6p3.2 - anonymous union may not have private or protected members.
	This seems to imply that anonymous union may have public members;
	and that non-anonymous union may have any access modifiers.
	Is this wording really what is intended?
Resolution:
Requestor:      Tom Plum / Dan Saks
Owner:		Steve Adamczyk (Unions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   105 (WMM.27)
Title:          How can static members which are anon unions be initialized?
Section:        9.6 [class.union] Unions
Status:         active
Description:
        This is from Mike Miller's list of issues:
        class C {
                static union {
                        int i;
                        char * s;
                };
                union {
                        const int a, b;
                };
        };
        int C::i = 3;  // ? Is this syntax valid?
        int C::a = 5;  // ? Is this syntax valid?
Resolution:
Requestor:      Mike Miller
Owner:          Steve Adamczyk (Name Look up)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   570
Title:          Name look up for anonymous union member names need to be
	        better described.
Section:        9.6 [class.union] Unions
Status:         active
Description:
	paragraph 2 says:
	"The names of the members of an anonymous union shall be distinct
         from other names in the scope in which the union is declared; ..."
	Is this true?
	How about:
		int I;
		static union {
			class I { }; // error?
		};
		void f() {
			class I i; // is this OK?
		}
	How about:
		class C;
		static union {
			class C { }; // does this complete the type of global
			             // class C?
		};
Resolution:
Requestor:
Owner:          Steve Adamczyk (Name Look up)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   505
Title:          Must anonymous unions declared in unnamed namespaces also be
	        declared static?
Section:        9.6 [class.union] Unions
Status:         active
Description:
	9.6p3 says:
	"Anonymous unions declared at namespace scope shall be declared
	 static."
	Must anonymous unions declared in unnamed namespaces also be declared
	static?
	If the use of static is deprecated, this doesn't make much sense.

	Proposal:
	Replace the sentence above with the following:
	"Anonymous unions declared in a named namespace or in the global 
	 namespace shall be declared static."

	This is related to issue 526.
Resolution:
Requestor:	Bill Gibbons
Owner:          Josee Lajoie (linkage)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   533
Title:          Is an anonymous union a type?
Section:        9.6 [class.union] Unions
Status:         active
Description:
	9.6 paragraph 2 says: "... is called an anonymous union; it defines 
	an unnamed object (not a type)."
	Is an anonymous union a type?
	The sentence in paragraph 2 says it is an object with no type.
	Doesn't this break the object model?
	
	Is an anonymous union a class?
        Do the rules in the WP that apply to classes apply to anonimous 
	unions as well? The WP is unclear.
Resolution:
Requestor:	Fergus Henderson
Owner:          Josee Lajoie (object model)
Emails:
	core-5893
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:	Core
Issue Number:	47
Title:		enum bitfields - can they be declared with < bits than
	        required
Section:	9.7 [class.bit] Bitfields
Status:         active
Description:
	enum ee { one, two, three, four };
	struct S {
		ee bit:1; // allowed?
	};
Resolution:
Requestor:      ?	     
Owner:          Steve Adamczyk (Declarators)
Emails:
	core-1578
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   267
Title:          What does "Nor are there any references to bitfields" mean?
Section:        9.7 [class.bit] Bitfields
Status:         active
Description:
        9.7p3.5: "Nor are there references to bit-fields."  Does this 
	actually prohibit anything?  A simple attempt to make a reference 
	refer to a bit-field just creates a temporary:
                union { int bitf:2; } u;
                const int & r = u.bitf;
        Or is this a syntactic restriction that prohibits something like
                union { int (&rbitf):2 } u;
        Or is it meant to prohibit the use of typedefs to attempt it, such as
                union { typedef int bitf_t:2; bitf_t &rbitf; } u;
        The intent needs clarifying.
Resolution:
Requestor:      Tom Plum / Dan Saks
Owner:          Steve Adamczyk (Declarators)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   458
Title:          When is an enum bitfield signed / unsigned?
Section:        9.7 [class.bit] Bitfields
Status:         active
Description:
        enum Bool { false=0, true=1 };
        struct A {
           Bool b:1;
        };
        A a;
        a.b = true;
        if (a.b == true) // if this is sign-extended, this fails. 

	Bill Gibbons proposed resolution:
	Add after the sentence 9.7p5:
	"It is implementation defined whether plain (neither explicitly 
	 signed or unsigned) int bitfield is signed or unsigned."
	"...; enumeration bit-fields are neither signed nor unsigned."
Resolution:
Requestor:      Sam Kendall
Owner:          Steve Adamczyk (Declarators)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   571
Title:          Is bitfield part of the type?
Section:        9.7 [class.bit] Bitfields
Status:         active
Description:
	The description in 4.5 [conv.prom] para 3 seems to indicate that 
        bitfield is part of the type. Is it?

	If it is (as 4.5 seems to indicate) this subclause should be more
	explicit about it. If it isn't, bitfields should be discussed in
        lvalue/rvalue subclause [basic.lval] to describe how a bitfield
        lvalue is transformed into an rvalue.
Resolution:
Requestor:	Bill Gibbons
Owner:          Steve Adamczyk (Types)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 10 - Derived classes
------------------------------
Work Group:     Core
Issue Number:   441
Title:          In which scope is the base class clause looked up?
Section:        10 [class.derived] Derived classes
Status:         active
Description:
        class C {
          class A { };
          class B : A { }; //1
        };
	Is A looked up in the scope of C or in the scope of B?
        Is the declaration on line //1 ill-formed because the nested class B 
	cannot refer to the private type A declared in C?
	Or is it well-formed because the name A can be used in the scope of
	C?
Resolution:
Requestor:
Owner:          Steve Adamczyk (Name Look up)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   529
Title:          Can two base class subobjects be allocated at the same
	        address?
Sections:       10.1 [class.mi] Multiple base classes
Status:         closed
Description:
	struct B { void f(); };
	struct L : B{};
	struct R : B{};
	struct D : L,R{};
	
	Since B has no data members, can B have the same address as another
	member subobject of of D?
	That is, can a base class subobject have zero size?

        [note: Certain folks on the Core reflector have requested that the 
        draft also be changed to allow complete objects and member subobjects
        to have 0-size. I consider this to be an extension and will not cover
        it here. I am only concerned with clarifying the requirements for the
        size of base class subobjects.]
Discussion:
	During the discussions on the core reflector, three options were
	proposed:

	1) No, all objects in C++ (including base class subobjects) must be
	   of non 0-size.

	2) Yes, base class subobjects can be of non 0-size.
	   However, base class subobjects that are of non 0-size must still
	   respect the restrictions in 5.9[expr.rel], paragraph 2 i.e.:

	   "Pointers to objects or functions of the same type (after pointer
	    conversions) can be compared; the result depends on the relative
	    positions of the pointed-to objects or functions in the address
	    space as follows:
	    -- If two pointers to the same type point to the same object or
	       function, or both point one past the end of the same array, or
	       are both null, the compare equal.
	    ...
	   "
	   What this means is that 0-sized subobjects are allowed, but that
	   two subobjects of the same class type cannot be located at the 
	   same address location.

	   If a complete object of a contains a single B, it may have zero
	   size.  There is no way of another B can have the same address 
	   since the complete object has a unique address because objects 
	   cannot overlap.

	   If a complete object contains several subobjects of type B, the
	   compiler should make sure they have different offsets in the
	   complete object.  This may require some additional bytes being
	   allocated between such objects.

	   [Erwin Unruh in core-5430]:
	       class B {};
	       class L : B {};
	       class R : B {};
	       class D : L,R { int i,j; }

	       Layout:
	               0       base class L
	               0       indirect base L::B
	               0       integer i
	               4       base class R
	               4       indirect base R::B
	               4       integer j
	               8       end of object (or start of next one)

	   Not a single byte is wasted and both subobjects of type B have
	   different addresses.

	3) Yes, base class subobjects can be of non 0-size and can be located
	   at the same address location.  In this case, 5.9[expr.rel]
	   paragraph 2 needs to be changed to indicate that the rule 
	   requiring that two pointers to the same type only compare equal if
	   they point to the same object does not apply to base class 
	   subobjects.
Proposed Resolution:
	Adopt solution 2)
	because it is the status quo.

	9[class] paragraph 3 needs to be changed to say:
	 "A class with an empty sequence of members and base class objects
	  is an empty class.  Complete objects and member subobjects of an
	  empty class type shall have a nonzero size."

	10[derived] needs to be updated to say:
	 "A base class subobject can be of zero size.  However, two
	  subobjects of the same class type cannot be located at the same
	  storage location."
Resolution:
	See Tokyo motion 9).
Requestor:	Bill Gibbons
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   446
Title:          Can explicit qualification be used for base class navigation?
Sections:       10.1 [class.mi] Multiple base classes
Status:         active
Description:
        Can explicit qualification be used for base class sublattice 
        navigation?

        class A { 
        public: 
          int i; 
        };
        class B : public A { };
        class C : public B { };
        class D { 
        public: 
          int i; 
        };
        class E : public D { };
        class F : public E { };
        class Z : public C, public F { };
        Z z;
        ... z.F::E::D::i; // is qualification allowed here to navigate the
                          // base class sublattice?
Resolution:
Requestor:      Bill Gibbons
Owner:          Steve Adamczyk (Name Lookup)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   447
Title:          When should a class without a final overrider be ill-formed?
Sections:       10.3 [class.virtual] Virtual Functions
Status:         closed
Description:
        p7 shows:
        struct A {
           virtual void f();
        };
        struct B : virtual A {
           void f();
        };
        struct C : virtual A {
           void f();
        };
        struct E : B, C { };   //1
         
        Is the declaration of E on line //1 ill-formed? 
        Why not wait until an object of class E is created to issue the error
        message? 
        Making the declaration of E on line //1 ill-formed prevents programs
        to further derive from E and override the virtual member function.
        i.e. 
        struct F : E { 
           void f();
        };
Resolution:
	At the Tokyo meeting, the Core WG didn't think this change was
	desirable.
Requestor:
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   589
Title:          Can the return type of an overridding function be incomplete
                and different from the return type of the base class 
	        function?
Sections:       10.3 [class.virtual] Virtual Functions
Status:         closed
Description:
	para 5 says:
	"A program is ill-formed if the return type of any overriding 
	 function differs from the return type of the overridden function 
	 unless the return type of the latter is pointer or reference 
	 (possibly cv-qualified) to a class B, and the return type of the 
	 former is pointer or reference (respectively) to a class D such that
	 B is an unambiguous direct or indirect base class of D, accessible 
	 in the class of the overriding function, and the cv-qualification in
	 the return type of the overriding function is less than or equal to
	 the cv-qualification in the return type of the overridden function."

        If the return types are different and the return type of the 
	overridding function is imcomplete, is te program ill-formed?

	[Mike Ball, ext-3401]:
	"The actual requirement, as I see it, is that the type be complete by
	 the end of the class containing the function.  That is the 
         requirement on most implementations I've seen, though it can 
         certainly be relaxed for some implementations."
Resolution:
	See Tokyo motion 9).
Requestor:      Fergus Henderson
Owner:          Josee Lajoie (Object Model)
Emails:
	ext-3383
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 11 - Member Access Control
------------------------------------
Work Group:     Core
Issue Number:   585
Title:          Is access checking performed on the qualified-id of a 
	        member declarator?
Section:        11 [class.access]
Status:         active
Description:
	para 6 says:
	"... access checking is not performed on the components of the 
         qualified-id used to name the member in a declarator..."
     
	Is this true if the qualified-id uses typedef names that are private?

		class D { D f(); };
		class C
		{
			typedef D T;
		};

		D C::T::f() {} // Legal? T is a private typedef of C.
Proposed Resolution:
Resolution:
Requestor:
Owner:          Steve Adamczyk (Access Specifications)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:	Core
Issue Number:	22
Title:		Must implementations respect access restrictions?
Section:	11.1 [class.access.spec] Access Specifiers
Status:         editorial
Description:
	What are the access restrictions used for?
	Are they only limitations on what the programmer may write?
	Must implementations also respect them for the compiler generated
	code? (i.e. use of default and copy constructors, use of destructors
        at the end of a block or at the end of the program). 

        And if implementations must respect access restriction, when must it 
        report the errors? 

        struct B {
        private:
            ~B () { }
        };

        struct D : public B { 
           ~D () { }  // is the mere existence of D::~D considered an
                      // implicit call of B::~B and therefore a protection 
                      // violation?
        };

        void f() {
           D d;       // Or is this an error?
         }            // Or is the error when d is destroyed?
Resolution:
	The Core WG decided to handled this as an editorial issue.
	Yes, implementations must respect access restrictions.
	The error is detected when the destructor for D is defined.
Requestor:	Jerry Schwarz
Owner:          Josee Lajoie (Special Member Functions)
Emails:
	core-1525
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   284
Title:          access to base class ctor/dtor
Sections:       11.2 [class.access.base] Access Specifiers for Base Classes
Status:         closed
Description:
        base access rules don't apply to non-inherited members
        11.2 After much discussion, we believe that the intent is as follows:
        "The members whose accessibility is described in this section are 
	 only those members which are inherited from the base class; the 
	 non-inherited members such as constructors, destructors, and
	 assignment operators are not subject to these accessibility rules."

        I still have problems with this one.  There are two separate issues,
        one minor and one substantive.  Minor issue: The ctor, dtor, and
        assignment op of a base are not accessible as "members of the derived
        class" (because they aren't inherited in the derived class), but I 
        believe that access declarations still apply to them.  So it's just a
        job of re-wording 11.2/p1 to clarify this.

        But the substantive issue is a real problem.  The vagueness has been
        unresolved so long that implementations have differed in the 
	treatment of access declarations upon base class ctors and dtors.  
	Could you discuss this with me and we'll determine how to proceed.
Resolution:
	See Tokyo motion 11) and paper 95-0212/N0812 issue 1.6.
Requestor:      Tom Plum / Dan Saks
Owner:          Josee Lajoie (Special Member Functions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   388
Title:          Access Declarations and qualified ids
Section:        11.3 [class.access.dcl] Access Declarations
Status:         active
Description:    
        The section says:
        The base class member is given, in the derived class, the access in 
        effect in the derived class declaration at the point of the access
        declaration. 
 
        It isn't clear to me what this means for
                class B { public: int i ; } ;
                class D : private B {
                   B::i ;
                };
 
                D* p ;
                p->i ;  // clearly legal
                p->B::i ;
 
        I don't care strongly about this, but I think it should be clarified.
        (And added as an example).
Resolution:
Requestor:      Jerry Schwarz
Owner:          Steve Adamczyk (Access Specifications)
Emails:        
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   448
Title:          Can '::' be used to declare global functions as friends?
Section:        11.4 [class.friend] Friends
Status:         closed
Description:
        Should it be allowed to prefix the declarator of a friend
        function declaration with '::' to indicate that a global
        function is the friend?
 
        void f();
        class C {
           void f();
           friend void ::f();
         };
 
        or
 
        class B {
           void f();
         };
        class C {
           class B { };
           friend void ::B::f();
        };
Resolution:
	See Tokyo motion 11) and paper 95-0212/N0812 issue 1.7.
Requestor:
Owner:          Steve Adamczyk (Name Lookup)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   515
Title:          How can friend classes use private and protected names?
Section:        11.4 [class.friend] Friends
Status:         active
Description:
	11.4 p2 says:
	"Declaring a class to be a friend implies that private and protected
	 names from the class granting friendship can be used in the class
	 receiving it."

	This is not very explicit.
	Where can the private and protected names be used in the befriended 
	class?
	In the base classes of the befriended class?
	In the nested classes of the befriended class?
Resolution:
Requestor:      Erwin Unruh
Owner:          Steve Adamczyk (Friends)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   532
Title:          Is a complete class definition allowed in a friend
                declaration?
Section:        11.4 [class.friend]
Status:         active
Description:
        Is this allowed:

            class A {
                static int x;
                friend class B {
                    int f() { return A::x; };
                };
            };

        If so, what is the scope of the class name B?
Resolution:
Requestor:      Neal M Gafter <gafter@mri.com>
Owner:          Steve Adamczyk (Friends)
Emails:
Papers:                                  
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 12 - Special Member functions
---------------------------------------
Work Group:     Core
Issue Number:   575
Title:          Can programs explicitly name implicitly-declared special 
	        member functions?
Section:        12 [special]
Status:         closed
Description:
	12[special] paragraph 1 says:
	"[Note: ...  Often such special member functions are called
	 implicitly.  The implementation will implicitly declare these member
	 functions for a class type when the programmer does not explicitly
	 declare them."

	This text should make it clear that implicitly-declared special 
	member functions can only be called implicitly by the implementation.
	User code cannot refer to or define these implicitly-declared special
	member functions.
Resolution:
	See Tokyo motion 10), proposed changes to subclause 12.
	Users code can explicitly refer to implicitly-declared 
	special member functions.
Requestor:
Owner:          Josee Lajoie (Special member functions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   379
Title:          Invoking member functions which are "not inherited".
Section:        12.1 [class.ctor] Constructors
                12.4 [class.dtor] Destructors
                12.8 [class.copy] Class Copy
Status:         closed
Description:
        Section 5.1/8 of the 1/93 working paper says:
	"A nested-class-specifier (9.1) followed by :: and the name 
	 of a member of that class (9.2) or a member of a base of that
	 class (10) is a qualified-id; its type is the type of the
	 member.  The result is the member."

	12.1[class.ctor] paragraph 3 says:
	  "Constructors are not inherited."

	12.4[class.dtor] paragraph 6
	  "Destructors are not inherited."

	12.8[class.copy] paragraph 5
	  "Copy constructors are not inherited."

        May a member of a given base class type which is "not inherited" by
        another class type (derived from the given base class type) be 
	invoked for an object whose static type is the derived class type if
	the invocation is done using the class-qualified name syntax?  If, 
	not, is an implementation obliged to issue a compile-time diagnostic
	for such usage?

        Is the behavior "well defined" if an attempt is made to invoke a
        non-inherited member for an object whose static type is that of the
	base class but whose dynamic type is that of the derived class?
                struct B {
                        virtual ~B () { }
                };

                struct D : public B {
                        ~D () { }
                };

                D D_object;
                D D_object2;
                B *B_ptr = &D_object2;

                void caller ()
                {
                        D_object.B::~B();               // ok?
                        B_ptr->~B();                    // ok?
                }
Resolution:
	The various sentences about the special member functions not being 
	inherited will be removed from the WP.

	The syntax "class_name()" is a special syntax naming a default
	constructor.  A derived class can refer to a base class default
	constructor.
	
	For destructors, see Tokyo motion 10), proposed changes to subclause
	12.4.  The syntax "~class_name()" is a special syntax for destructor.
	A derived class can refer to a base class destructor.

	A derived class can refer to a base class copy constructor.
Requestor:      Ron Guilmette
Owner:          Josee Lajoie (Special member functions)
Emails:
Papers:
        94-0193R1/N0580
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   576
Title:          How do volatile semantics affect the ctor and dtor code?
Section:        12.1 [class.ctor] Constructors
                12.4 [class.dtor] Destructors
Status:         editorial
Description:
	12.1 para 2 says:
	  "A constructor can be invoked for a const, volatile or const 
           volatile object. FN)
	   FN) volatile semantics might or might not be used."

	12.4 para 1 says:
	  "A destructor can be invoked for a const, volatile or const
           volatile object. FN)
           FN) volatile semantics might or might not be used."
 
	I thought that during the object model discussions, we agreed that
	const and volatile only came into effect at the end of constructor
        and their effect ended at the beginning of destructor.
Resolution:
	At the Tokyo meeting, the core WG decided that this was an editorial
	matter.

	The footnote in both of these sections will be removed and the WP
	will be made explicit say that const and volatile semantics are 
	never used on the object being constructed or destroyed.  According
	to the object model, const and volatile semantics apply to 
	const/volatile objects only once their initialization has completed 
	and only until their destruction starts.
Requestor:	public comment 7.12
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   598
Title:          Should a diagnostic be required if an rvalue is used in a 
	        ctor-initializer or in a return stmt to initialize a 
	        reference?
Section:        12.2 [class.temporary]
Status:         active
Description:
	12.2p5:
	"A temporary bound to a reference in a constructor's ctor-initializer
	 (12.6.2) persists until the constructor exits. ...
	 A temporary bound in a function retrun statement (6.6.3) persits 
	 until the function exits."

	This actually means that there is no reliable way to initialize a 
        reference member or a return value of reference type with an rvalue 
        expression.  Given that, a diagnostic should be required.
Resolution:
Requestor:	Tom Plum
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   562
Title:          Is a copy constructor a conversion function?
Section:        12.3.1 [class.conv.ctor]
Status:         editorial
Description:
	Is a copy constructor a conversion function?
	Are implicitly-declared copy constructor explicit or not?
	This subclause should be made clearer.
Resolution:
	At the Tokyo meeting, the core WG decided that this was an editorial
	matter.
	
	Yes, a copy constructor is a conversion function (as implied by 
	4.12[conv.class]).  An implicitly-declared copy constructor is not 
	an explicit conversion constructor; it can be used for implicit type
	conversion.
Requestor:
Owner:          Josee Lajoie (Special member functions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   347
Title:          Limitations on declarations of user-defined type-conversions.
Section:        12.3.2 [class.conv.fct] Conversion functions
Status:         editorial
Description:    
        Given a declaration such as:
                struct S {
                   operator T ();
                };
        ... where `T' is a typedef name declared in an earlier typedef 
        declaration, must a standard conforming implementation issue a 
        diagnostic for the declaration of the type conversion operator (as 
        shown above) if, at the point of declaration of the type conversion 
        operator itself, the type T is:
                o       A complete array type?
                o       An incomplete array type?
                o       An incomplete class type?
                o       A function type?
Resolution:
	The core WG decided to clarify as an editorial matter the fact that
	'T' could not be of array of function type.
Requestor:      Ron Guilmette
Owner:          Steve Adamczyk (Type Conversions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   293
Title:          Clarify the meaning of y.~Y
Section:        12.4 [class.dtor] Destructors
Status:         active
Description:
Resolution:
	12.4p22 The notation y.~Y() is explicitly approved of by the example
	at bottom of ARM page 279), but nothing in the draft gives this 
	explicit approval.  Implementations differ.  Committee should approve
	it or disapprove it.
Requestor:      Tom Plum / Dan Saks
Owner:          Josee Lajoie (Destruction)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   138 (WMM.89)
Title:          When are default ctor default args evaluated for array
                elements?
Section:        12.6 [class.init] Initialization
Status:         active
Description:
        From Mike Miller's list of issues.
        WMM.89. Are default constructor arguments evaluated for each element
        of an array or just once for the entire array?
                int count = 0;
                class T {
                        int i;
                public:
                        T ( int j = count++ ) : i ( j ) {}
                        ~T () { printf ( "%d,%d\n", i, count ); }
                };
                T arrayOfTs[ 4 ];
        Should this produce the output :-
                0,4
                1,4
                2,4
                3,4
        or should it produce :-
                0,1
                0,1
                0,1
                0,1
Resolution:
Requestor:      Mike Miller / Martin O'Riordan
Owner:          Steve Adamczyk (Declarators)
Emails:
        core-668
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   574
Title:          Must const members and reference members be initialized in
                the ctor-initializer of their owning class? 
Section:        12.6.2 [class.base.init] Initializing Bases and Members
Status:         closed
Description:
	struct B {
		const int i;
		B();
	};
	B() { } // should this be ill-formed because the const member 'i' is
                // not initialized by the constructor ctor-initializer?
Proposed Resolution:
	Since the standard requires that complete objects that are of const
	or reference type be initialized, it seems to make sense that
	constructors and initializer lists for classes with const or 
	reference members provide initializers for these members.

	Replace 12.6.2[class.base.init] paragraph 3 with:
	  "The definition for a constructor for a class X with a nonstatic
	   data member m of const or reference type shall either specified
	   a mem-initializer for m or m shall be of a class type with a
	   user-declared default constructor, otherwise the constructor
	   definition is ill-formed."

	Similarly, the following text should be added to 
	8.5.1[dcl.init.aggr], at the end of paragraph 2:
	  "An initializer list for an aggregate X with a nonstatic data
	   member m of const or reference type shall either provide an
	   initializer for m or m shall be of a class type with a
	   user-declared default constructor, otherwise the initializer list
	   is ill-formed."
Resolution:
	See Tokyo motion 10), changes proposed for section 12.6.2.
	Yes, the ctor-initializer of a constructor must initialize 
	const members and reference members of its owning class.
Requestor:
Owner:	        Josee Lajoie (Initialization)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core Language
Issue Number:   534
Title:          Can the members of an anonymous union be named in a 
	        ctor-initializer?
Section:        12.6.2 [class.base.init] Initializing Bases and Members
Status:         closed
Description:
	struct X {
        	union { int i; float f; };
	        X() : f(1.0); // Is this valid?
	};                            
Resolution:
	See Tokyo motion 10), changes proposed for section 12.6.2.
	Yes, they can.
Requestor:	Fergus Henderson
Owner:          Steve Adamczyk (Name Look Up) 
Emails:
	core-5893
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   478
Title:          can a union constructor initialize multiple members?
Section:        12.6.2 [class.base.init] Initializing Bases and Members
Status:         closed
Description:
    can a union constructor initialize multiple members?
Resolution:
	See Tokyo motion 10), changes proposed for section 12.6.2.
	No, it cannot.
Requestor:      Neal Gafter
Owner:          Josee Lajoie (Initialization)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   95
Title:          Volatility, copy constructors, and assignment operators.
Section:        12.8 [class.copy]
Status:         closed
Description:
        It appears that volatile qualification has been overlooked in the
        specification of copy constructors and assignment operators.
        Section 12.1p5 of the WP says:
        "A copy constructor for a class X is a constructor whose first
        argument is of type X& or const X&..."

        But a user should be able to pass volatile objects (by reference) to
        copy constructors and/or assignment operators.

        In such cases it would be useful (and symmetric with const
        qualification) if:
        (a) these objects could be used as arguments to copy constructors and
        assignment operators, and
        (b) if the volatility associated with the types of the objects were
        preserved in the process.
Resolution:
	See Tokyo motion 10), changes proposed for section 12.8.
	
	--  change 12.8 [class.copy], paragraph 2, first sentence to:

	    A constructor for class X is a copy constructor if its first
	    parameter is of type X&, const X&, volatile X& or const volatile
	    X&, and either there are no other parameters or else all other
	    parameters have default arguments (_dcl.fct.default_).

	--  change 12.8 [class.copy], paragraph 5 to:

	    The implicitly-declared copy constructor for a class X will have
	    the form
	        X::X(const X&)
	    if
	    --  each direct or virtual base class B of X has a copy 
	        constructor whose first parameter is of type const B& or 
	        const volatile B& and
	    --  for all the nonstatic data members of X that are of a class 
	        type (or array thereof), each such class type has a copy 
	        constructor whose first parameter is of type const M& or 
	        const volatile M&.  
	    Otherwise, the implicitly declared copy constructor will have 
	    the form
	        X::X(X&)

	--  change 12.8 [class.copy], paragraph 9, first sentence to:

	    A user-declared copy assignment operator X::operator= is a
	    non-static member function of class X with exactly one parameter
	    of type X, X&, const X&, volatile X& or const volatile X&.                    
	--  change 12.8 [class.copy], paragraph 10 to:

	    If a class definition does not explicitly declare a copy 	
            assignment operator, one is declared implicitly.  The 
	    implicitly-declared copy assignment operator for a class X will 
	    have the form
	        X& X::operator=(const X&)
	    if
	    --  each direct base class B of X has a copy assignment operator
	        whose parameter is of type const B& or const volatile B& and
	    --  for all the nonstatic data members of X that are of class 
	        type M (or array thereof), each such class type has a copy 
	        assignment operator of type const M& or const volatile M&.
	    Otherwise, the implicitly declared copy constructor will have the
	    form
	        X& X::operator=(X&)
Requestor:      Ron Guilmette
Owner:	        Josee Lajoie (Special Member Functions)
Emails:
        core-1653
Papers:
	See paper 95-0056/N0656
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   536
Title:          When can objects be eliminated (optimized away)?
Section:        12.8 [class.copy]
Status:         active
Description:
	Paragraph 15 indicates that an implementation is allowed to eliminate
	an object if it is created with the copy of another.
	
	ISSUE 1:
        --------  
	However, this is in clear contradiction with other WP text:
	3.7.1[basic.stc.static] says:
	  "If an object of static storage duration has initialization or a
	   destructor with side effects; it shall not be eliminated even if
	   it appears to be unused."

	3.7.2[basic.stc.automatic] says:
	  "If a named automatic objects has initialization or a destructor 
	   with side effects; it shall not be destroyed before the end of its
	   block, nor shall it be eliminated as an optimization even if 
           appears to be unused."                                                         
	So which is right?

	Many have suggested different ways to resolve this difference:

	Andrew Koenig [core-5975]:
	  The correct way to resolve the contradiction is to say that copy 
	  optimization applies only to local objects. 

	Patrick Smith [core-6083]:
	  1) Just weaken 3.7.1 and 3.7.2 so they can be overridden by the
	     copy constructor optimization.

	  2) Restrict the copy constructor optimization to only eliminate
	     temporaries representing function return values.

	  3) Require the programmer to explicitly mark the classes for
	     which the copy constructor optimization is permitted even
	     though it would violate 3.7.1 or 3.7.2.

	  4) Require the programmer to explicitly mark the classes for
	     which the copy constructor optimization is not permitted when
	     it would violate 3.7.1 or 3.7.2.                                

	ISSUE 2:
        --------  
	Jerry Schwarz in core-5993:

	  What may be of concern is not side effects in general, but resource
	  allocation.  E.g. if Thing is intended to obtain a lock that is 
	  held until it is destroyed, then you do indeed have to be careful 
	  about the semantics you give to the copy constructor.

	    {
	        Thing outer ; // get the lock
	        {
	            Thing inner = outer ; // copy constructor increments
	                                  // count on lock.

	            // do stuff that requires the lock
	            inner.release() ;  // decrement count
	            // do stuff that doesn't require the lock
	        }

	        // do stuff that still requires the lock.
	    }

	  The optimization allows outer and inner to be aliased, and the
	  explicit release in inner may cause the lock to be released too
	  early.

	Is Jerry's concern worth worrying about?

	Two possible resolutions were proposed:

	Jerry suggested the following:
	    When we introduced the "explicit" keyword I remember considering
	    what it would mean on copy constructors and thinking about the
	    possibility that it would suppress this optimization.

	Jason Merrill proposed in c++std-core-5978:
	    Perhaps the language in class.copy should be modified so that it
	    only applies when the end of one object's lifetime coincide with 
	    the beginning of its copy's lifetime.   
Resolution:
Requestor:      John Skaller
Owner:          Josee Lajoie (Object Model)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 13 - Overloading
--------------------------
Work Group:     Core
Issue Number:   451
Title:          Description of a call to a member function through a pointer 
                to member is missing   
Section:        13.2.1.1.1 [over.call.func] Call to named function
Status:         closed
Description:
        Should this section also describe calls to member functions using the
        pointer to member syntax (.*, ->*) ? 
Resolution:
	When a pointer to member is used to call a member function, the
	overloaded function resolution mechanism is not used.
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   578
Title:          Do cv-qualifiers on the conversion functions considered 
                matter?
Section:        13.3.1.3 [over.match.user]
Status:         editorial
Description:
	para 1 says:
	"-- When the type of the initializer expression is a class type 
            'cv S', the conversion functions of S and its bases are
            considered. Those that are not hidden within S and yield type 
	    'cv2 T' or a type that can be converted to type 'cv2 T', for any 
            'cv2' that is the same cv-qualification as, or lesser 
            cv-qualification than, cv1, ..."

	Why do the cv-qualifiers matter here?
	This seems to disallow:
           struct T {} t1;
	   struct S { operator const T() { return t1; } } s;
	   T t2 = s;   // no conversion function found

	If the example above is intended to be allowed, then the sentence
	should probably read:
	  "Those that yield type T or a type that can be converted to T
	   using a standard conversion sequence."    
Resolution:
	At the Tokyo meeting, the core WG decided to handle this as an 
	editorial matter.
	Yes, cv-qualifiers on the conversion functions matter, but only
	if the conversion function converts to a class type.
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   599
Title:          Are user-defined conversion sequences always ambiguous when 
                the user-defined conversions considered are different?
Section:        13.3.3.2 [over.ics.rank]
Status:         active
Description:
	para 3 second bullet:
	"- User-defined conversion sequence U1 is a better conversion 
	   sequence than another user-defined conversion sequence U2 if they
	   contain the same user-defined conversion operator or constructor 
	   and if the second standard conversion sequence of U1 is better 
	   than the second standard conversion sequence of U2."
	
	Given the following code sample:
		struct S {
			operator double();
			operator short();
		};

		S s;
		... double(s) ...; // ambiguous?	

	There are two user-defined conversion sequences possible for this
	conversion:
		S::operator double
		S::operator short -> standard conversion to short
	and because the two user-defined conversion sequences use different
	user-defined conversions, the call is ambiguous.

	This seems rather surprising.
	Is this outcome really what the committee wanted?	
Resolution:
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   579
Title:          The declarations for the candidate built-in operators do not 
                reflect the constraints described in clause 5
Section:        13.6 [over.built]
Status:         editorial
Description:
	13.6 paragraph 1 says that clause 13.6 describes the candidate
	operator functions that represent the built-in operators defined in
	clause 5.

	In some cases, the declarations in 13.6 allow for a greater set of
	declarations than what clause 5 actually allows.  For example, in
	clause 5, requirements on the pointer conversions applied to the
	operands of the relational and equality operators are described as
	follows:
	  "Pointer conversions are performed on pointer operands to bring
	   them to the same type, which shall be the type of one of
	   the operands."

	This means that
	  struct B { };
	  struct D1 : B { } *pd1;
	  struct D2 : B { } *pd2;

	  pd1 == pd2;   // error according to clause 5

	The rules in 13.6 paragraph 16 say:
	  "For every triple (T, CV1, CV2), where T is any type..."
	the phrase 'any type' is misleading and can be seen as allowing:

	  struct S1 { operator D1*(); } s1;
	  struct S2 { operator D2*(); } s2;

	  s1 == s2;     // well-formed according to 13.6.
	                // The == operator is resolved to builtin
	                // operator==(B*, B*);
Resolution:
	At the Tokyo meeting, the core WG decided to handle this issue
	as an editorial matter. 

	13.6 should indicate that despite the fact that some declarations for
	the built-in operators are not as restricted as the semantics 
	described in clause 5, the restrictions in clause 5 must still be 
	respected when considering the set of built-in candidate functions 
	for the use of an operator. 
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   580
Title:          The declaration for builtin ->* does not allow lhs of derived
                class type and left hand side of base class type
Section:        13.6 [over.built]
Status:         editorial
Description:
	para 12 says:
	"For every quadruple (C, T, CV1, CV2), where C is a class type, T a
	 complete object type or a function type, and CV1 and CV2 are 
	 cv-qualifier-seqs, there exit candidate operator functions of the
	 form 
		CV12 T& operator->*(CV1 C*, CV2 T C::*);
	 where CV12 is the union of CV1 and CV2."

	This rule doesn't take into account that the left operand of ->* can
        be a pointer to a derived class D and its right operand can be a 
        pointer to member to a base class B of D. For example:

		struct B { };
		struct D : B { };
		int B::*pmb;
		D* pd;

		pd->*pmb;   // OK according to clause 5

	but the candidate functions for builtin operators seem to disallow:

		struct S1 { operator int B::*(); } s1;
		struct S2 { operator D*(); } s2;

		s2->*s1;    // error; 
                            // matches builtin operator->*(B*, int B::*)
	                    // and operator->*(D*, int D::*) equally well

	To fix this, the rules in para 12 could be rewritten as:
	"For every quintuple (C1, C2, T, CV1, CV2), where C2 is a class type,
         C1 is the same type as C2 or C2 is an unambiguous accessible base 
         class of C1, ..."
Resolution:
	At the Tokyo meeting, the core WG decided to handle this issue
	as an editorial matter. 
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   581
Title:          The declarations for the built-in operators do not take into
                account operands of enumeration type
Section:        13.6 [over.built]
Status:         editorial
Description:
	For example:
	Clause 5 says [5.6, expr.mul, paragraph 2]:
	  "... the operands of % shall have integral or enumeration type."

	However, the description in 13.6 paragraph 18 says:
	 "For every pair of promoted integral types L and R, there exist
	  candidate operator functions of the form
		LR  operator%(L, R)
	  ..."
	according to clause 5, L and R could be of enumeration type.

	Another example:
	There is no declaration for operator= for operands of enum types, 
	i.e.
	Something like this should be added:
		VQ E& operator=(VQ E&, E);
	where E is an enumeration type.
Resolution:
	At the Tokyo meeting, the core WG decided to handle this issue
	as an editorial matter. 
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   582
Title:          What are the cv-qualifiers for the parameters of a candidate 
                function?
Section:        13.6 [over.built]
Status:         active
Description:
        What are the cv-qualifiers for the parameters of a candidate 
	function?

        For example, given
                class B {
                   operator const int **();
                };
                class D : B {
                   operator volatile int **();
                };
                B b;
                D d;
                ... b == d ...
        Is the builtin candidate function:
          bool operator==(const volatile int**, const volatile int **);
        or:
          bool operator==(const int**, volatile int **);
        ?
Resolution:
        Steve Adamczyk will write a paper on cv-qualifiers and operand
        types to be available for the Scotts Valley meeting (March 96).
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   583
Title:          For a candidate built-in operator, must cv-qualifiers of 
                parameters of type pointer to member be the same?
Section:        13.6 [over.built]
Status:         active
Description:
        The footnote associated with para 14, 15 and 16 says:
          "When T is itself a pointer, the interior cv-qualfiers of
           the two parameter types need not be identical. The two
           pointer types are converted to a common type (which need
           not be the same as either parameter type) by implicit pointer
           conversions."

        This omits to take into account operands of type pointer to member 
        with different cv-qualifiers on the pointer to member type.
Resolution:
        Steve Adamczyk will write a paper on cv-qualifiers and operand
        types to be available for the Scotts Valley meeting (March 96).
Requestor:
Owner:          Steve Adamczyk (function overload resolution)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 15 - Exception Handling
---------------------------------
Work Group:     Core
Issue Number:   594
Title:          If a constructor throws an exception, in which cases is the 
                storage for the object deallocated?
Section:        15.2 [except.ctor]
Status:         active
Description:
	para 2 says:
	"If the object or array was allocated in a new-expression, the 
         storage occupied by that object is sometimes deleted also (5.3.4)."
	Does this mean:
	o deleted if an appropriate operator delete is present
        or
	o undefined behavior if delete must be called (runtime)
Resolution:
Requestor:      public comment 7.12
Owner:          Bill Gibbons (exceptions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   611
Title:          What happens when an exception is thrown from the destructor
	        of a subobject?
Section:        15.2 [except.ctor]
Status:         active
Description:
	This section is not clear in describing what happens if an exception 
	is thrown from the destructor of a subobject (i.e. for an array 
	element or for a class member or base)?
	Are the remaining elements/members/bases destroyed?
	Is terminate called?
Resolution:
Requestor:	Scott Meyers
Owner:          Bill Gibbons (exceptions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:	Core
Issue Number:	539
Title:		Can one throw a pointer-to-member to a base class and catch 
	        it with a handler taking a pointer to a derived class?
Section:	15.3 [except.handle] Handling an exception
Status:		active
Description:
	struct B { int i; };
	struct D : B { };
        int B::*pmb;

	void f() {
          try {
	    throw pmb;
	  }
          catch (int D::*pmd) {
            // is the exception handled here?
	  }
	  catch(...) {
            // or here?
	  }
        } 
Resolution:
Requestor:
Owner:          Bill Gibbons (exceptions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   540
Title:	        How does name look up proceed in a function-try-block?
Section:        15.3 [except.handle] Handling an exception
Status:         active
Description:
	Can names of variables declared in the outermost block of the 
	function be referred to?
	If the function-try-block appears in a member function definition, 
	are names declared in the scope of the class considered?
Resolution:
Requestor:
Owner:          Steve Adamczyk (Name Look Up)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   541
Title:          Is a function-try-block allowed for the function main?
Section:        15.3 [except.handle] Handling an exception
Status:         active
Description:
	I assume the new syntax that allows for function-try-block is also
	allowed if the function is main:

		main()
		try {
		}
		catch (...) { }

	What is the effect of the catch(...) in main if the constructor for
	an object with static storage duration throws an exception (and the
	constructor does not catch the exception)?

	Because the WP does not dictate a precise moment for the construction
	of objects with static storage duration (these objects can be
	constructed at any time before the first statement in main or...), is
	it implementation-defined whether the handler in main catch an
	exception thrown from a constructor for a global static object?  Or 
	is the catch in main guaranteed to catch (or guaranteed not to catch)
	such an exception?                                        
Resolution:
Requestor:
Owner:          Bill Gibbons (exceptions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   542
Title:          What exception can a reference to a pointer to base catch?
Section:        15.3 [except.handle] Handling an exception
Status:         active
Description:
	15.3 says:
	    A handler with type T, const T, T&, or const T& is a match for a
	    throw-expression with an object of type E if
	    ...
	    [3] T is a pointer type and E is a pointer type that can be 
	    converted to T by a standard conversion.

	This allows code like this:

	struct A { };
	struct B { };
	struct D : A, B { };
	D d;

	try {
		D* pd = new D;
		throw pd;
	}
	catch (B*& pb) {// OK, B*& is a valid handler
			// for a throw of type D*
	}

	However, code equivalent to this outside of the exception handling
	try/catch mechanism is disallowed, i.e.

		B*& pb = new D; // error

	The current language rules (8.5.3) require that the reference be of
	const type for this initialization to be valid.  i.e.

		B* const & pb = new D; // OK

	preventing the pointer referred to by the reference from being
	modified with the value of a pointer of a different type.

	Going back to the original example with EH, 15.3 allows someone to
	write code as follows in the handler, code which modifies the 
	original exception thrown:

	catch (B*& pb) {
		pb = new B;
	}

	Allowing this doesn't seem to make much sense to me because if the
	program ever tries to refer to the original exception thrown as a D*
	after the assignment to pb has taken place (using a rethrow, for
	example) undefined behavior is almost guaranteed to take place i.e.
	the exception of type D* has become an object of type B* and the type
	system has been completely bypassed.

	I believe 15.3 should say that a handler with type T& is _not_ a
	match for a throw-expression with an object of type E if T and E are
	pointer types that are not of the same types.

	There may be other adjustments needed as well to make 15.3 mimic more
	closely the rules on reference initialization.
Resolution:
Requestor:
Owner:          Bill Gibbons (exceptions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   587
Title:          Can a pointer/reference to an incomplete type appear in a
                catch clause?
Section:        15.3 [except.handle] Handling an exception
Status:         active
Description:
	15.3/1 says:
	"The exception-declaration [in a catch clause] shall not denote an 
	 incomplete type."

	This comes from 92-120/N0197 issue 3.3:
	"No, an incomplete type can not appear in a catch clause.

	 A pointer or reference to an incomplete type may appear in a catch
	 clause, however."

	Should pointers and references to incomplete types also be disallowed
        in catch clauses?
	
	The resolution of issue 3.3 (and the related requirement that
        incomplete types be allowed in exception specifications) place 
        unreasonable constraints on implementations.

	In particular, they force implementations to handle exceptions by
	matching the *names* of classes.  This is because it is not possible
	to generate type information for an incomplete class.  Since the 
	class need not ever be complete, an implementation may not rely on 
	type information generated in another translation unit; rather, it 
	must associate the incomplete type with the appropriate type 
	information by searching for the type name.

	Is the need for pointers/references to incomplete types in catch
        clauses sufficient to justify these kinds of restrictions on the 
        implementations? And similarly, is the need for incomplete types in 
        exception specifications of function definitions sufficient to 
        justify these restrictions?
Resolution:
Requestor:      Bill Gibbons
Owner:          Bill Gibbons (exceptions)
Emails:
	ext-3367
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   590
Title:          With function try blocks, does the caller or callee catches
	        exceptions from constructors/destructors called for parms?
Section:        15.3 [except.handle] Handling an exception
Status:         active
Description:
	In the presence of function try blocks, if the constructor/
	desctructor for the function parameter throws an exception, who 
	(caller/callee) is responsible for catching the exception?

	 class X {
         public:
              ~X() { throw xx(); }
              // ...
         };

         class Y {
         public:
              Y(int) { throw yy(); }
              // ...
         };

         class Z {
         public:
              Z(const Z&) { throw zz(); }
              // ...
         };

         void f(X a, Y b, Z c) {
              // ...
         }
         catch (xx) {
              // will the xx thrown by ~X() be caught here? 
         }
         catch (yy) {
              // will the yy thrown by Y(int) be caught here?
         }
         catch (zz) {
              // will the zz thrown by Z(const Z&) be caught here?
         }

         void g(X& x,Z& z)
         {
              ff(x,1,z);
         }
         catch (xx) {
              // will the xx thrown by ~X() be caught here?
         }
         catch (yy) {
              // will the yy thrown by Y(int) be caught here?
         }
         catch (zz) {
              // will the zz thrown by Z(const Z&) be caught here?
         }
Resolution:
Requestor:	Bjarne
Owner:          Bill Gibbons (exceptions)
Emails:
        ext-3402
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   592
Title:          Can a type be defined in a catch handler?
Section:        15.3 [except.handle] Handling an exception
Status:         active
Description:
	Erwin Unruh in ext-3427:
	"There are many places where 'types can not be defined'. The catch 
         handler is one of the places where this is presently not the case.

	 I propose:
	 Add to [except.handle] 15.3:
	 "Types shall not be defined in an 'exception-declaration'."
        "
Resolution:
Requestor:	Erwin Unruh
Owner:          Bill Gibbons (exceptions)
Emails:
        ext-3427
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work Group:     Core
Issue Number:   588
Title:          How can exception specifications be checked at compile time
                if the class type is incomplete?
Section:        15.4 [except.spec]
Status:         active
Description:
	Issue 1:
	--------
	struct A;
	struct B;
	void f() throw(A);
	void g() throw(B) { f(); }

	Because A and B have incomplete type, static checking isn't possible
        because it can't be determined if B is derived from A.

	[Mike Ball, ext-3386]:
        "Having these types incomplete here essentially obviates strong 
         signature checking, which some of our customers have stated very 
         strongly that they want.

	 I think that requiring complete types in a throw specification will
         not produce the dependencies people are assuming.  From what I have
         seen, types thrown tend to be from a rather small set of classes 
         especially designed to be thrown as exceptions.  This means that 
         requiring that they be complete would probably not have cascading 
         effects.  That is, it might pull in the headers defining the 
         exception class hierarchy, but probably not a whole lot else."

	[Andrew Koenig, ext-3387]:
	"As with function argument types, I think it should be OK to use an
	 incomplete type in an exception specification:

	    struct A;
	    void f() throw(A);

	 as long as you complete it

	    struct A { };

	 before calling or defining the function:

	    void g() { f(); }

	Issue 2:
	--------
	paragraph 2 says:
	"If a virtual function has an exception-specification, all 
         declarations, including the definition, of any function that 
         overrides that virtual function in any derived class shall have an 
         exception-specification at least as restrictive as that in the base 
         class."

	What does "shall" mean if incomplete types are used?
	Incomplete types make it impossible to determine if the clause is 
        adhered to.

	[John Skaller, ext-3379]:
	"A reasonable interpretation is that an incomplete type B 'is not as 
         restrictive as' a type A and so this ought to require a diagnostic. 
         My argument -- you can complete B later to be anything you want, so 
         the throw spec of B doesn't exhibit a restriction, as required.

	[Mike Ball, ext-3380]:
        "One could also argue that it could also be checked at the definition
         point of the overriding function, at which point it would certainly 
         be no burden on the programmer to require that the type be 
         complete."
Resolution:
Requestor:      John Skaller
Owner:          Bill Gibbons (exceptions)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=============================================================================
 Chapter 16 - Preprocessing Directives
---------------------------------------
Work Group:     Core
Issue Number:   595
Title:          Is a macro __STDC_plusplus__ needed?
Section:        16.8 [cpp.predefined]
Status:         active
Description:
Resolution:
Requestor:      ANSI public comment 8.5
Owner:          Tom Plum (Preprocessor)
Emails:
Papers:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .