Movatterモバイル変換

Proposed resolution (10/00):

• 7.6.1.7 [expr.dynamic.cast] paragraph 8,bullet 2: change "unambiguous public base class" to "unambiguousand public base class"
• 11.7.3 [class.virtual] paragraph 5: change"the class in the return type... is an unambiguous direct orindirect base class... and is accessible inD" to "theclass in the return type... is an unambiguous and accessible director indirect base class..."

The Standard uses confusing terminology when referring toaccessibility in connection with ambiguity. For instance:

7.3.12 [conv.ptr] paragraph 3:

IfB is an inaccessible or ambiguous base ...

... has an unambiguous public base ...

... is an unambiguous direct or indirect base ... andis accessible ...

not involving conversions to pointers to private orprotected or ambiguous classes

The phrase "unambiguous public base" is unfortunate as itcould mean either "anunambiguous base not considering accessibility, which is public"or "anunambiguous base considering only the publicly accessible bases."I believe theformer interpretation correct, as accessibility is applied after visibility(11.8 [class.access] paragraph 4)and ambiguity is described in terms of visibility(6.5.2 [class.member.lookup] paragraph 2).

Suggested Resolution:Use the phrases "public and unambiguous,""accessible and unambiguous,""non-public or ambiguous," or "inaccessible or ambiguous" as appropriate.

Proposed resolution (10/00):

• 7.6.1.7 [expr.dynamic.cast] paragraph 8,bullet 2: change "unambiguous public base class" to "unambiguousand public base class"
• 11.7.3 [class.virtual] paragraph 5: change"the class in the return type... is an unambiguous direct orindirect base class... and is accessible inD" to "theclass in the return type... is an unambiguous and accessible director indirect base class..."