prefix ++ on an rvalue?!

[Armen Tsirunyan]

Hi all,
I clearly remember from the C++03 standard that a function call is an
lvalue if and only if it returns a reference.
Now I was reading C++ In A Nutshell book, and it says that
object.name, provided name is a nonstatic data member, is an lvalue if
and only if object is an lvalue. And we all know that the built-in
prefix ++ requires an lvalue. All that taken into consideration, I
tried to compile the following code on MSVC9.0
//code begins here
struct x
{
int z;
};

x f()
{
x ret;
ret.z = 0;
return ret;
}

int main()
{
++(f().z);
}
//end of code
And it did compile. Any comments?

 

[Alf P. Steinbach /Usenet]

* Armen Tsirunyan, on 06.10.2010 13:10:

Hi all,
I clearly remember from the C++03 standard that a function call is an
lvalue if and only if it returns a reference.
Now I was reading C++ In A Nutshell book, and it says that
object.name, provided name is a nonstatic data member, is an lvalue if
and only if object is an lvalue. And we all know that the built-in
prefix ++ requires an lvalue. All that taken into consideration, I
tried to compile the following code on MSVC9.0
//code begins here
struct x
{
int z;
};

x f()
{
x ret;
ret.z = 0;
return ret;
}

int main()
{
++(f().z);
}
//end of code
And it did compile. Any comments?

Comeau is a better tool to check the standard's rules.

You can always use Comeau Online for small example programs (note that the
online version does not link).


<example>
Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 15: error: expression must be a modifiable lvalue
++(f().z);
^

1 error detected in the compilation of "ComeauTest.c".
</example>


Most often, and in this case, Comeau is right.

I.e. Visual C++ is not standard-conforming with the options that you used.

Also note that you can call member functions on an rvalue, in particular using
the assignment operator. This has the baffling consequence that you can assign
to a POD struct function result, but not to an individual member of basic type.


Cheers & hth.,

- Alf

 

[Armen Tsirunyan]

* Armen Tsirunyan, on 06.10.2010 13:10:








Comeau is a better tool to check the standard's rules.

As a matter of fact, I did try it on Comeau and got an error

You can always use Comeau Online for small example programs (note that the
online version does not link).

<example>
Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 15: error: expression must be a modifiable lvalue
        ++(f().z);
          ^

1 error detected in the compilation of "ComeauTest.c".
</example>

Most often, and in this case, Comeau is right.

I.e. Visual C++ is not standard-conforming with the options that you used..

And which options do you think I used? As a matter of fact, I even set
"Disable Language Extensions" to true.
What options should I have used so that MSVC would be compliant? Is it
even possible? I mean, what surprises me
is that Microsoft always says that they are committed to 100%
standards-compliance, but the incompliance issues
pass from one version to another unchanged . I just happen to love
the Visual Studio IDE, but the compilers incompliance
is annoying. I mean, it's not as though they can't fix it or don't
know about the problem. It's as though they just don't want to.
So why are thy shouting from the rooftops about compliance?
Sorry, I am agitated

Also note that you can call member functions on an rvalue, in particular using
the assignment operator. This has the baffling consequence that you can assign
to a POD struct function result, but not to an individual member of basic type.

Yeah, I know that, it is explicitly mentioned in the standard, isn't
it?

 

[Stuart Golodetz]

As a matter of fact, I did try it on Comeau and got an error



And which options do you think I used? As a matter of fact, I even set
"Disable Language Extensions" to true.
What options should I have used so that MSVC would be compliant? Is it
even possible? I mean, what surprises me
is that Microsoft always says that they are committed to 100%
standards-compliance, but the incompliance issues
pass from one version to another unchanged . I just happen to love
the Visual Studio IDE, but the compilers incompliance
is annoying. I mean, it's not as though they can't fix it or don't
know about the problem. It's as though they just don't want to.
So why are thy shouting from the rooftops about compliance?
Sorry, I am agitated

I understood what Alf said about options to merely be a qualifying
phrase, since changing compiler options can change the results -- if it
doesn't make a difference in this case, then it doesn't.

IME, there aren't any options that will make MSVC (or any other
compiler) 100% compliant. It's a pain (especially the fact that some
compilers are less compliant than others, which is frustrating when
porting code), but then writing a C++ compiler is damn hard. Like
everyone else, I want to see perfect compliance -- but I do have a
certain amount of sympathy for the compiler writers who actually have to
do the work.

As to why Microsoft keep telling you that their compiler is now much
more compliant -- it is, but it's still not perfect (or, in some cases,
as good as some other compilers). It's a hell of a lot nicer than it
used to be though (remember VC++ 6?). And it's perfectly usable on a
day-to-day basis.

Chill

Regards,
Stu

 

[Francois Grieu]

On 06/10/2010 13:33, Armen Tsirunyan wrote

what surprises me is that Microsoft always says that they
are committed to 100% standards-compliance

Do you have a reference on that? I want to throw it at the
Microsoft representative who, being informed that

#if (1?1?1:1:1)

cause an error, wrote:
we will not fix this issue as it is not a common code
and is not a high priority issue.

Francois Grieu

 

[Armen Tsirunyan]

On 06/10/2010 13:33, Armen Tsirunyan wrote


Do you have a reference on that? I want to throw it at the
Microsoft representative who, being informed that

#if (1?1?1:1:1)

cause an error, wrote:

      we will not fix this issue as it is not a common code
      and is not a high priority issue.

  Francois Grieu

I have read about that in some articles, and in this newsgroup. I
can't remember exactly where, sorry.
as for the representative's response, it is just exactly what their
attitude is. I mean, I do appreciate that since Visual Studio 6.0 they
have improved a real lot. And I can't complain that ordinary programs
have problems with microsoft's incompliance. It's just an awful lot of
minor issues which would never be used unless for an experiment's
sake. But they should also appreciate that experimenting is a part of
learning, and my first example would definitely confuse a student
about lvalues and rvalues...

 

[Andrey Tarasevich]

What options should I have used so that MSVC would be compliant? Is it
even possible? I mean, what surprises me
is that Microsoft always says that they are committed to 100%
standards-compliance, but the incompliance issues
pass from one version to another unchanged

Firstly, no compiler is 100% standard compliant. And any compiler
contains bugs. Secondly, there's a world of a difference between
compiler refusing to compile correct code and compiler agreeing to
compile incorrect code. The former is a serious problem. The latter is
more of a curiosity, not worth spending too much time on. It is true
that formally a compiant compiler should at least issue a diagnostic
message when it accepts incorrect code, but the world is not perfect.

When a compiler accepts incorrect code, it is often possible to exploit
that "feature" and make the compiler interpret incorrectly some other,
perfectly valid code. If you can come with with such an exploit for this
issue, then it will indeed represent a serious problem. Otherwise,
again, it is just a curiosity. Nothing to write home about.

Checking the validity of the code by trying it in a compiler is by far
not the best way to do it. But if you really want to run a quick check,
use Comeau Online compiler for that purpose. It is quite pedantic.

http://comeaucomputing.com/tryitout/

MSVC++ and GCC compilers are far from being useful for quick-checking
the standard compliance of the code, with GCC being incomparably worse
in the "accepting incorrect code" department because of the motley
collection of thoughtless enabled-by-default extensions implemented into it.

Again, any compiler will have bugs and Comeau Online is not perfect as
well, but in most cases.

--
Best regards,
Andrey Tarasevich

P.S. Here's one beauty I discovered recently in Comeau

int i = 0, f() { return i; }

int main() {
return f();
}

 

[Joshua Maurice]

Firstly, no compiler is 100% standard compliant. And any compiler
contains bugs. Secondly, there's a world of a difference between
compiler refusing to compile correct code and compiler agreeing to
compile incorrect code. The former is a serious problem. The latter is
more of a curiosity, not worth spending too much time on. It is true
that formally a compiant compiler should at least issue a diagnostic
message when it accepts incorrect code, but the world is not perfect.

When a compiler accepts incorrect code, it is often possible to exploit
that "feature" and make the compiler interpret incorrectly some other,
perfectly valid code. If you can come with with such an exploit for this
issue, then it will indeed represent a serious problem. Otherwise,
again, it is just a curiosity. Nothing to write home about.

Checking the validity of the code by trying it in a compiler is by far
not the best way to do it. But if you really want to run a quick check,
use Comeau Online compiler for that purpose. It is quite pedantic.

http://comeaucomputing.com/tryitout/

MSVC++ and GCC compilers are far from being useful for quick-checking
the standard compliance of the code, with GCC being incomparably worse
in the "accepting incorrect code" department because of the motley
collection of thoughtless enabled-by-default extensions implemented into it.

Again, any compiler will have bugs and Comeau Online is not perfect as
well, but in most cases.

I politely disagree. I like type safety, and I think compiler enforced
type safety (among other things) facilitates programmer productivity.
If a compiler compiles something when it shouldn't, it's not
automatically "a curiosity". It could be a very important break of
type safety or similar feature. Binding non-const (lvalue) references
to rvalues is one such example. There is a reason a rule forbidding
this was put into the standard. It prevents accidental type
conversions from surprising the programmer, and overwhelmingly this
helps the programmer write more code with less errors in the same
time.

Then there's also the problem of vendor lock-in through incidental or
accidental use of non-portable non-standard features.