Test for learners

In article <6-udnYeUib2KfF_VnZ2dnUVZ_sWdnZ2d@posted.comnet>,
alfps@start.no says...

[ ... ]

> I did look up the expression syntax earlier, but now, it's late evening.

Yes -- one of the possibilities for a primary expression is an id-
expression, which is either a qualified id or an unqualified id. An
identifier is an unqualified id (section 5.1).

--
Later,
Jerry.

The universe is a figment of its own imagination.

On Sep 6, 9:59 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:
> > Putting parentheses around the name of a function-style macro
> > can unmask a real function which it hid. So without parenthese,
> > you get a macro, with them, you don't. And we all know that
> > macros can wreck havoc and change the semantics in all sorts of
> > ways.

> I couldn't think of anything when I saw the original article.

I didn't even try:-). But when putting parentheses around a
function was mentionned, it reminded me of the C days (without
inline), when the trick was used to allow an implementation to
make isspace() a macro, but still allow you to take the address
of the function: isspace is a function style macro, which will
only be recognized as a macro and expanded as such if it is
immediately followed by a '(' token: "isspace,", for example,
doesn't expand the macro, so the code "sees" the external
function declaration which preceded the macro definition. And
of course, as soon as "macro" came to mind, I realized that it
was anythinig goes.

> And I'm still not sure you guys are right.

> Is an unparenthesized function name that's part of a function
> call, really an expression? A function name on its own is an
> expression, and a complete function call is, but the
> unparenthesized function name in a call?

Of course. Otherwise, how could you construct a function call
expression? (Remember, () is an operator, just like any other
operator. It can even be overloaded. And if it's not
overloaded, it's left hand argument can be any expression which
has function or pointer to function type.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> writes:
>>Is an unparenthesized function name that's part of a function
>>call, really an expression? A function name on its own is an
>>xpression, and a complete function call is, but the
>>unparenthesized function name in a call?
>Of course. Otherwise, how could you construct a function call
>expression?

By a modification of the grammar and the language.
For example, in Java, the method name is /never/ an
expression and cannot be written inside of parentheses.

On Sep 7, 4:37 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> James Kanze <james.ka...@gmail.com> writes:
> >>Is an unparenthesized function name that's part of a function
> >>call, really an expression? A function name on its own is an
> >>xpression, and a complete function call is, but the
> >>unparenthesized function name in a call?
> >Of course. Otherwise, how could you construct a function call
> >expression?

> By a modification of the grammar and the language.
> For example, in Java, the method name is /never/ an
> expression and cannot be written inside of parentheses.

And there are no pointers to functions, or even free functions.
Java's not C++.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alf P. Steinbach wrote:
>
> And I'm still not sure you guys are right.
>
> Is an unparenthesized function name that's part of a function call,
> really an expression?

Yes.

> A function name on its own is an expression, and a
> complete function call is, but the unparenthesized function name in a call?

Yes, it is an expression. With an ordinary function it is pretty
obvious, since you can always use the function name alone as a valid
(albeit useless) expression

void foo();

foo; // <- a valid expression

With member functions things are a bit more complicated. One can't use a
qualified name of a member function as a standalone expression

struct S { void foo(); };

S::foo; // <- ill-formed

which often leads people to conclude that a member function name alone
is not an expression. In reality, from the language point of view, it is
an expression, but it is only allowed to be used in a restricted set of
contexts, as described in 5/10.

In article <ga3kj7$e3i$1@aioe.org>,
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> Alf P. Steinbach wrote:
> > A function name on its own is an expression, and a
> > complete function call is, but the unparenthesized function name in a call?
>
> Yes, it is an expression. With an ordinary function it is pretty
> obvious, since you can always use the function name alone as a valid
> (albeit useless) expression
>
> void foo();
>
> foo; // <- a valid expression

What about something overloaded? f doesn't name a single object until
it's used in a context (calling, or converting to function pointer).

void f( int );
void f( double );

int main()
{
f; // ambiguous
}