In article <rfgCD2u9E.KEn@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>In article <JASON.93Aug25173817@rtl.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>Also: should
>>int *p;
>>p->~int();
>>work, or just
>>p->int::~int();
>
>I believe that this is also a case where neither the ARM nor the current
>X3J16 working paper are entirely self-consistant.  It seems to me that I
>recall reading one report which claimed that one part of the X3J16 working
>paper required the fully class-qualified name, while another part seemed
>to say that full class-qualification was not necessary.

The first printing of the ARM required explicit destructor calls to
use the qualified name.  That was a mistake (even an example used
aa.~X()) and it was corrected in the first printing of CPL2 and in the
December 1990 printing of the ARM.  That's right, for over two years
this issue has been settled.  There's no excuse for compiler writers
to still not allow either of the above statements.

If you know that the ARM or the WP is inconsistent, I'd sure like some
section references.  I really hate to think that compiler writers have
just been too lazy to investigaate this subject.

Jamshid Afshar

In article <JASON.93Aug25173817@rtl.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>Section 12.4 of the ARM says,
>
>"The notation for explicit call of a destructor may be used for any simple
>type name...Using the notation for a type that does not have a destructor
>has no effect."
>
>Section 5.2.4 of the January working document says,
> "the id-expression must name a member of that class, except that an
>imputed destructor may be explicitly invoked for a built-in type, see
>f12.4."
>
>Does this mean that the default (null) destructor can be called for any
>type that does not define a destructor, or only for built-in types?

I believe that the intent was that pseudo-destructor functions should
*appear* to be available for *all* types (for the sake of templates).

In other words, I believe that you have found a flaw in the ARM (in 5.2.4).

>Also: should
>
>int *p;
>p->~int();
>
>work, or just
>
>int *p;
>p->int::~int();

I believe that this is also a case where neither the ARM nor the current
X3J16 working paper are entirely self-consistant.  It seems to me that I
recall reading one report which claimed that one part of the X3J16 working
paper required the fully class-qualified name, while another part seemed
to say that full class-qualification was not necessary.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

Section 12.4 of the ARM says,

"The notation for explicit call of a destructor may be used for any simple
type name...Using the notation for a type that does not have a destructor
has no effect."

Section 5.2.4 of the January working document says,
 "the id-expression must name a member of that class, except that an
imputed destructor may be explicitly invoked for a built-in type, see
f12.4."

Does this mean that the default (null) destructor can be called for any
type that does not define a destructor, or only for built-in types?  It
seems to me that the intent of section 12.4 was to allow templates to
destroy the contents of an object when appropriate without regard to
whether or not there is an actual destructor defined, but the text appears
to indicate that this only applies to simple types.

Also: should

int *p;
p->~int();

work, or just

int *p;
p->int::~int();

since the first case might not be considered "explicit"?

--
Jason

In article <JASON.93Aug25173817@rtl.cygnus.com>,
Jason Merrill <jason@cygnus.com> wrote:
>Section 5.2.4 of the January working document says,

Btw, when's the next update going to be released?  I would like to buy
a copy of the WP (see the c.l.c++ FAQ -- I mailed for info and got a
letter back saying it was $35) but I'd rather wait if a newer version
is imminent, especially if it has an updated template section.

> "the id-expression must name a member of that class, except that an
>imputed destructor may be explicitly invoked for a built-in type, see
>f12.4."
>
>Does this mean that the default (null) destructor can be called for any
>type that does not define a destructor, or only for built-in types?  It
>seems to me that the intent of section 12.4 was to allow templates to
>destroy the contents of an object when appropriate without regard to
>whether or not there is an actual destructor defined, but the text appears
>to indicate that this only applies to simple types.

I agree with your interpretation of the ARM and I doubt ANSI/ISO
intends differently; afterall it does refer to 12.4 (btw, what does
`f' stand for?).  WP 5.2.4 probably needs to be clarified a bit unless
it is assumed that all classes which don't explictly define a
destructor have a default destructor created for them.  That's
currently done only for classes which have a base or member with a
destructor.

I think it's very important to pay attention to the ARM/WP when it
refers to another section, especially when that section is the primary
source of information for that particular topic.  For example, ARM 5.4
p70 could be read as allowing the casting of a `void (Derived::*)()'
to a `void(Base::*)()'.  5.4 references section 4, though, which says
such conversions are not legal.  I think that 5.4, like WP 5.2.4, is a
bit imprecise but it's reference to the other section should serve as
the "clincher" when trying to determine its intentions.

>Also: should
>int *p;
>p->~int();
>work [...]

Yes, and I don't know why compiler writers are so hesitant to accept
this.  The first printing(s?) of the ARM required a class name
qualifier for all explicit destructor calls (eg, p->T::~T();), but
that was quickly fixed in later printings and in CPL2.  Examples have
always existed in the ARM without the qualifier.  This isn't that big
of a deal, but it really annoys me that so many compiler writers
either don't know that the above code should be allowed or they have
gotten bug reports about it but are too lazy to actually investigate
the matter.

Jamshid Afshar
jamshid@emx.cc.utexas.edu