Re: Test for learners

[Martin Eisenberg]

Stefan Ram wrote:

1.) When you want to test whether something is an
expression within a correct program, put a pair of
parentheses around it. If it is an expression, the
program will still be correct and the behavior of the
program will not change.

Putting parentheses around the function name in an unqualified call
disables ADL; to wit--

#include <iostream>

using namespace std;

namespace N {
struct S {};
void f(S) { cout << "N::f()"; };
}

int main()
{
N::S s;
f(s); // compiles
// (f)(s); // doesn't compile
return 0;
}
Martin

--
Quidquid latine scriptum est, altum videtur.

[James Kanze]

On Sep 6, 1:40 pm, Martin Eisenberg <[e-mail]:

Stefan Ram wrote:

1.) When you want to test whether something is an
expression within a correct program, put a pair of
parentheses around it. If it is an expression, the
program will still be correct and the behavior of the
program will not change.

Putting parentheses around the function name in an unqualified
call disables ADL;

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <6-******************************@posted.comnet>,
al***@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.

[James Kanze]

On Sep 6, 9:59 pm, "Alf P. Steinbach" <[e-mail]:

* 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 7, 4:37 pm, [e-mail] (Stefan Ram) wrote:

James Kanze <[e-mail]:

>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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Andrey Tarasevich]

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.

[blargg]

In article <ga**********@aioe.org>,
Andrey Tarasevich <an**************@hotmail.comwrote:

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
}