On Fri, 12 Jul 2002 16:12:06 GMT, jpotter@falcon.lhup.edu (John
Potter) wrote:

>On 12 Jul 2002 02:58:39 GMT, Gennaro Prota <gennaro_prota@yahoo.com>
>wrote:
>
>> The key is that there's nothing like pseudo-destructor-call in the
>> grammar (the name with the dashes is mine), but there's something like
>> a pseudo-destructor-name.
>
>Agreed.  It is defined in 5.2.4 (check the index).  A
>pseudo-destructor-name can only refer to a non-class type.
>
>> The expressions:
>
>>        i.~integer()
>>        s.~S()
>
>> [in the first one I'm assuming a typedef int integer; your code is
>> illegal]
>
>Hum, I agree.  Now convince my compiler which accepts it. :)
>
>> qualify both as postfix-expression(), and both according to
>> 5.2.2 are function calls (function call expressions). Both contains a
>> pseudo-destructor-name.
>
>Reference?
>
>> postfix-expression:
>>      postfix-expression ( expression-listopt )
>>      postfix-expression . pseudo-destructor-name
>
>What are the parsing rules?  In parsing s.~S, we find
>postfix-expression dot id-expression and the parse is done.

You already said something like that in a previous post. But what kind
of id-expression is that   'tilde-S' ?

>  In
>parsing i.~integer, id-expression does not match and we continue to
>find postfix-expression dot pseudo-destructor-name.
>

Yes.

>> The distinction between "true calls" and "pseudo-calls" is semantical,
>> i.e. we call "pseudo function calls" those function calls that refer
>> to non-class types.
>
>The semantics of i.~integer() are given by 5.2.4.
>
>The semantics of s.~S() are given by 5.2.2 and violate /3.
>

Yes, I already agreed that, with my interpretation, there would be a
problem in 5.2.2/3.


>> Otherwise tell me how do you explain 12.4/12.
>
>Explain what?  Pseudo-destructor-name, rightly, does not appear there.
>

Actually, you should admit that things are far from clear. For
instance 3.4.3/5 talks of qualified pseudo-destructor-names for class
types (but has a link to 5.2.4, which talks of non-class types, just
after the term pseudo-destructor-name). That's one of the reasons why
I think both interpretations (mine and yours) cause problems in the
standard.

If I had chosen the terminology I would have used the term
pseudo-destructor-name for every ~T (with the word 'pseudo' referred
to 'name'), and the term 'pseudo destructor call' (with 'pseudo'
referred to 'call') for non-class types.  But it was not up to me, so
let's hear what was the choice of the committee :-)


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 14 Jul 2002 09:56:12 GMT, Gennaro Prota
<gennaro_prota@yahoo.com> wrote:

> On Fri, 12 Jul 2002 16:12:06 GMT, jpotter@falcon.lhup.edu (John
> Potter) wrote:

> >On 12 Jul 2002 02:58:39 GMT, Gennaro Prota <gennaro_prota@yahoo.com>
> >wrote:

> >> The key is that there's nothing like pseudo-destructor-call in the
> >> grammar (the name with the dashes is mine), but there's something like
> >> a pseudo-destructor-name.

> >Agreed.  It is defined in 5.2.4 (check the index).  A
> >pseudo-destructor-name can only refer to a non-class type.

> >> The expressions:

> >>        i.~integer()
> >>        s.~S()

> >> [in the first one I'm assuming a typedef int integer; your code is
> >> illegal]

> >Hum, I agree.  Now convince my compiler which accepts it. :)

> >> qualify both as postfix-expression(), and both according to
> >> 5.2.2 are function calls (function call expressions). Both contains a
> >> pseudo-destructor-name.

> >Reference?

> >> postfix-expression:
> >>      postfix-expression ( expression-listopt )
> >>      postfix-expression . pseudo-destructor-name

> >What are the parsing rules?  In parsing s.~S, we find
> >postfix-expression dot id-expression and the parse is done.

> You already said something like that in a previous post. But what kind
> of id-expression is that   'tilde-S' ?

5.1/1 id-expression: unqualified-id
      unqualified-id: ~class-name

It is the fourth entry.  That tilde is hard to see.  Zoom!

> >> Otherwise tell me how do you explain 12.4/12.

> >Explain what?  Pseudo-destructor-name, rightly, does not appear there.
> >

> Actually, you should admit that things are far from clear. For
> instance 3.4.3/5 talks of qualified pseudo-destructor-names for class
> types (but has a link to 5.2.4, which talks of non-class types, just
> after the term pseudo-destructor-name). That's one of the reasons why
> I think both interpretations (mine and yours) cause problems in the
> standard.

3.4.3/5 is hard to read.  First sentence is about non-class types.
Hard stop and change of subject to class types.  The examples follow
the same pattern.  It is talking about name lookup not the defintion
of pseudo-destructor-name.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 14 Jul 2002 17:23:08 GMT, jpotter@falcon.lhup.edu (John
Potter) wrote:

>> >> postfix-expression:
>> >>      postfix-expression ( expression-listopt )
>> >>      postfix-expression . pseudo-destructor-name
>
>> >What are the parsing rules?  In parsing s.~S, we find
>> >postfix-expression dot id-expression and the parse is done.
>
>> You already said something like that in a previous post. But what kind
>> of id-expression is that   'tilde-S' ?
>
>5.1/1 id-expression: unqualified-id
>      unqualified-id: ~class-name
>
>It is the fourth entry.  That tilde is hard to see.  Zoom!
>

Oh my God! I swear that the "copy" of the standard I was using has
-textually-:

    unqualified-id:
        identifier
        operator-function-id
        conversion-function-id
        class-name
        template-id


Actually it's an HTML version which so far has never caused me any
problem, at the point that until now I never thought to check the
original. It was a real shock the see that the pdf version (as well as
the grammar in the appendix A of TC++PL) has the tilde.
Of course, I should have understood that something was wrong because
why putting there either identifier, template-id and class-name (which
can only be only of the first two)?

What to say? Shame on me and on my pdf-to-html converter :-(


>> >> Otherwise tell me how do you explain 12.4/12.
>
>> >Explain what?  Pseudo-destructor-name, rightly, does not appear there.
>> >
>
>> Actually, you should admit that things are far from clear. For
>> instance 3.4.3/5 talks of qualified pseudo-destructor-names for class
>> types (but has a link to 5.2.4, which talks of non-class types, just
>> after the term pseudo-destructor-name). That's one of the reasons why
>> I think both interpretations (mine and yours) cause problems in the
>> standard.
>
>3.4.3/5 is hard to read.  First sentence is about non-class types.
>Hard stop and change of subject to class types.  The examples follow
>the same pattern.  It is talking about name lookup not the defintion
>of pseudo-destructor-name.

Yes, of course that foul deed about the grammar changes everything. I
hope you will accept my most sincere apologies.


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 12 Jul 2002 02:58:39 GMT, Gennaro Prota <gennaro_prota@yahoo.com>
wrote:

> >> >> > > Why? Can't mt_ptr -> ~mytype be the postfix expression that is
> >> >> > > followed by ( expression-listopt ) ?
> >
> >> >> >It is, and when followed by () it is (member) function call.  What it
> >> >> >can't be is anything involving pseudo-destructor-name because that is
> >> >> >a term only defined for scalar types.
> >
> >> >> Gulp! Tell me where is it written...
> >
> >> >5.1/7 ~class-name is an id-expression.
> >
> >> Wrong wrong wrong! :-(((
> >
> >> ~class-name can't be a qualified-id! (It's none of the possible
> >> unqualified-ids in 5.1)
> >
> >> >5.2.4/1 pseudo-destructor-name designates a non-class type.
> >
> >> 5.2.4/1 is a little ambiguous.
> >
> >I don't think so.
> >
> >pseudo: apparently, not actually, sham, pretending
> >pseudo-destructor: not actually a destructor
> >pseudo-destructor-name: syntactic element which names nothing
> >pseudo-destructor-call: expression which calls nothing
>
> I'm saying the same for a long time now :-) Where we don't agree is
> that you think that the presence of a pseudo-name makes the entire
> function-call-expression a pseudo-call. Instead I say that
> syntactically we only have function calls and semantically we have
> function calls or pseudo_function_calls depending on whether in ~T the
> T names a class type or not.

> >struct S { };
> >int main () {
> >    int i;
> >    i.~int();
> >    // postfix-expression ()
> >    // postfix-expression -> postfix-expression .
> >    //                       pseudo-destructor-name
> >    // pseudo-destructor-name -> ~ type-name
> >    S s;
> >    s.~S();
> >    // postfix-expression ()
> >    // postfix-expression -> postfix-expression . id-expression
> >    // id-expression -> unqualified-id
> >    // unqualidied-id -> ~ class-name
> >    // You may need to zoom to see that ~ in the standard
> >    }

> The key is that there's nothing like pseudo-destructor-call in the
> grammar (the name with the dashes is mine), but there's something like
> a pseudo-destructor-name.

Agreed.  It is defined in 5.2.4 (check the index).  A
pseudo-destructor-name can only refer to a non-class type.

> The expressions:

>        i.~integer()
>        s.~S()

> [in the first one I'm assuming a typedef int integer; your code is
> illegal]

Hum, I agree.  Now convince my compiler which accepts it. :)

> qualify both as postfix-expression(), and both according to
> 5.2.2 are function calls (function call expressions). Both contains a
> pseudo-destructor-name.

Reference?

> postfix-expression:
>      postfix-expression ( expression-listopt )
>      postfix-expression . pseudo-destructor-name

What are the parsing rules?  In parsing s.~S, we find
postfix-expression dot id-expression and the parse is done.  In
parsing i.~integer, id-expression does not match and we continue to
find postfix-expression dot pseudo-destructor-name.

> The distinction between "true calls" and "pseudo-calls" is semantical,
> i.e. we call "pseudo function calls" those function calls that refer
> to non-class types.

The semantics of i.~integer() are given by 5.2.4.

The semantics of s.~S() are given by 5.2.2 and violate /3.

> Otherwise tell me how do you explain 12.4/12.

Explain what?  Pseudo-destructor-name, rightly, does not appear there.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]