Test for learners

I have devised two tests for learners of C++:

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.

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

To make sure that the rules are correct, I would like to know
whether anyone can find a counterexample. (I am aware of such
a counterexample in Java, but not in C++.)

Stefan Ram wrote:
> 2.) When you want to test whether something is a statement
> within a correct program, put a pair of braces around it.
> If it is a statement, the program will still be correct
> and the behavior of the program will not change.

int i = 5; // Is this a statement?
std::cout << i << "\n";

Let's test:

{ int i = 5; }
std::cout << i << "\n";

I suppose it isn't. Then what is it?

Juha Nieminen <nospam@thanks.invalid> writes:
>int i = 5; // Is this a statement?

Yes.

My rule has failed.

So, enclosing a statement in braces can change the correctness
and/or behavior.

It might still be valid that a program that complies with the
BNF grammar of C++ will still comply with this grammar when a
statement is enclosed in an additional pair of braces.
(But it might be erroneous after the modification for reasons
of scoping.)

One also might still ask whether it holds that if enclosing a
source text in an additional pair of braces does not change
the behavior, then that source text is a statement.

But, no, here is a counterexample for this:

int main(){ int a[ 2 ][ 2 ]={ 0 }; }
int main(){ int a[ 2 ][ 2 ]={{ 0 }}; }

So this test only is an indication that something is a
statement, but not a strict evidence.

Stefan Ram wrote:
> I have devised two tests for learners of C++:
>
> 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.

Hm... I'm not sure about the intended scope of this rule. Say in this
declaration

int i;

I can put a pair of parentheses around 'i'

int (i);

and get an equivalent program. This still doesn't mean that this
specific 'i' in this specific context is an expression. It is not. Sure,
out of context 'i' is a valid expression, but in the above context it is
a declarator.

BTW, is your rule supposed to work both ways? I.e. if one can't put the
braces around it, does that mean it is not an expression? If so, then it
is not true as well. For example, in this context

struct A { int i; };

struct B : A {
void foo() {
int A::*p = &A::i; // 'A::i' is an expression in this context
}
};

'A::i' is an expression. However, if I put braces around it as in

struct B : A {
void foo() {
int A::*p = &(A::i); // ERROR
}
};

the program becomes ill-formed.

> 2.) When you want to test whether something is a statement
> within a correct program, put a pair of braces around it.
> If it is a statement, the program will still be correct
> and the behavior of the program will not change.

In C++ (as opposed to C, for example) declarations form declaration
_statements_. Juha already gave you an counterexample where extra braces
break the code.

Andrey Tarasevich wrote:
> ...
> BTW, is your rule supposed to work both ways? I.e. if one can't put the
> braces around it, does that mean it is not an expression? If so, then it
> is not true as well. For example, in this context
>
> struct A { int i; };
>
> struct B : A {
> void foo() {
> int A::*p = &A::i; // 'A::i' is an expression in this context
> }
> };
>
> 'A::i' is an expression. However, if I put braces around it as in
>
> struct B : A {
> void foo() {
> int A::*p = &(A::i); // ERROR
> }
> };
>
> the program becomes ill-formed.
> ...

.... although a pedantic person might argue that while 'A::i' is indeed a
valid expression in 'B::foo', nevertheless 'A::i' in '&A::i' is _not_ a
sub-expression, but rather a mere 'qualified-id'. There would probably
be no reason to even consider this pedantic issue, if not for your rule

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>BTW, is your rule supposed to work both ways? I.e. if one can't
>put the braces around it, does that mean it is not an expression?

I was not sure about this, too.

Now, I see, that these rules are not valid always, so I will
have to use wording like »often« for these rules.

BTW: I believe, a qualified-id is an expression, too, because
it is an id-expression, whis is a primary-expression.

Stefan Ram wrote:

> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> > BTW, is your rule supposed to work both ways? I.e. if one can't
> > put the braces around it, does that mean it is not an expression?
>
> I was not sure about this, too.
>
> Now, I see, that these rules are not valid always, so I will
> have to use wording like »often« for these rules.

Frankly, I'd drop them altogether. Even if they were 100% reliable, I
don't think they are useful to a student. As they aren't even
consistently true, their utility is further dimished.



Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

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.

On Sep 6, 1:40 pm, Martin Eisenberg <martin.eisenb...@udo.edu> wrote:
> 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: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:
> On Sep 6, 1:40 pm, Martin Eisenberg <martin.eisenb...@udo.edu> wrote:
>> 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.

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

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?

Well I'm too lazy to look it up.

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


Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?