By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,853 Members | 995 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,853 IT Pros & Developers. It's quick & easy.

Conflicting behavior of MS and Borland

P: n/a
I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo

While in case of VC7.0

In const foo
In non-const foo

I could not find much in TC++PL
--
Imanpreet Singh Arora
Jul 22 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Minti wrote:
I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo
gcc 3.4.0 and VC7.1 also says this.

While in case of VC7.0

In const foo
In non-const foo
I suspect it's a bug in VC7.0.

I could not find much in TC++PL


Jul 22 '05 #2

P: n/a
Gianni Mariani wrote:
Minti wrote:
I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo

gcc 3.4.0 and VC7.1 also says this.


Not the VC7.1 I have. It still says the same as VC7.0. What version of
the compiler do you have? Mine says

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Do I need to update it somehow?

While in case of VC7.0

In const foo
In non-const foo

I suspect it's a bug in VC7.0.

Jul 22 '05 #3

P: n/a
Victor Bazarov wrote:
Not the VC7.1 I have. It still says the same as VC7.0. What version of
the compiler do you have? Mine says

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Do I need to update it somehow?


My compiler says:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3052 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

I.e. it's a bit older than yours. If I turn Microsoft's extension off
(/Za), I get the expected:

In const foo
In const foo

Just my $0.05

Br,
Peter
Jul 22 '05 #4

P: n/a
On Thu, 20 May 2004 12:45:06 -0400, Victor Bazarov
<v.********@comAcast.net> wrote:
Gianni Mariani wrote:
Minti wrote:
I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo

gcc 3.4.0 and VC7.1 also says this.


Not the VC7.1 I have. It still says the same as VC7.0. What version of
the compiler do you have? Mine says

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Do I need to update it somehow?

While in case of VC7.0

In const foo
In non-const foo

I suspect it's a bug in VC7.0.


I suspect it is a compatibility "feature" of 7.0 (don't ask me what it is
supposed to be compatible /with/, since VC6 does it "right" by default...)

Using both MSVC 7.0 and 7.1 with /Za, I get both const. Without /Za, I get
the one non-const.

A revealing diagnostic comes out when you compile it with Comeau, though:

test.cpp(10): warning: type qualifier is meaningless on cast type
foo( (const int ) x );

This makes sense, as casts always produce a temporary that is not
assignable, I think. So clearly we have a case of the parameter needing to
be a reference-to-const so that it can bind to a temporary.

None of this explains why VC7.x does it the other way by default. MSVC
works in mysterious ways when it comes to its default compatibility mode...
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Jul 22 '05 #5

P: n/a
Leor Zolman <le**@bdsoft.com> wrote in message news:<ho********************************@4ax.com>. ..
On Thu, 20 May 2004 12:45:06 -0400, Victor Bazarov
<v.********@comAcast.net> wrote:
Gianni Mariani wrote:
Minti wrote:

I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo
gcc 3.4.0 and VC7.1 also says this.
Not the VC7.1 I have. It still says the same as VC7.0. What version of
the compiler do you have? Mine says

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Do I need to update it somehow?


While in case of VC7.0

In const foo
In non-const foo
I suspect it's a bug in VC7.0.


I suspect it is a compatibility "feature" of 7.0 (don't ask me what it is
supposed to be compatible /with/, since VC6 does it "right" by default...)

Using both MSVC 7.0 and 7.1 with /Za, I get both const. Without /Za, I get
the one non-const.

A revealing diagnostic comes out when you compile it with Comeau, though:

test.cpp(10): warning: type qualifier is meaningless on cast type
foo( (const int ) x );

This makes sense, as casts always produce a temporary that is not
assignable, I think.


I really don't think that is indeed the case, if the cast can be done
at compile time
like in

const int x = 5.5;

then there is no need to produce a temporary.

I am not sure what you mean by "not assignable" do you mean that they
can't be an lvalue.

So clearly we have a case of the parameter needing to
be a reference-to-const so that it can bind to a temporary. None of this explains why VC7.x does it the other way by default. MSVC
works in mysterious ways when it comes to its default compatibility mode...
-leor


--
Imanpreet Singh Arora
Jul 22 '05 #6

P: n/a
On 20 May 2004 14:21:46 -0700, mi************@yahoo.com (Minti) wrote:
A revealing diagnostic comes out when you compile it with Comeau, though:

test.cpp(10): warning: type qualifier is meaningless on cast type
foo( (const int ) x );

This makes sense, as casts always produce a temporary that is not
assignable, I think.
I really don't think that is indeed the case, if the cast can be done
at compile time
like in

const int x = 5.5;

I don't consider that a "cast"; that's just a conversion. By "cast", I mean
either
(type) expression
type (expression)
or new-style_cast<type>(expression)

and I'm saying you can't make the result of one of those be the left
operand of an assignment operator (or ++/--).
then there is no need to produce a temporary.
Right, because it isn't a "cast".

I am not sure what you mean by "not assignable" do you mean that they
can't be an lvalue.


That's probably better wording, or "not modifiable" perhaps. I began trying
to elaborate on this based on what the Standard says; I've been bouncing
around between 3.10/2, 3.10/6 and writing test programs, and finally
decided I just don't understand some of the subtleties enough to really
follow through with an analysis.

I do, however, have a pet theory as to what the default MSVC 7 behavior is
doing, even though I haven't a clue why Microsoft would find such behavior
to be useful. In the strange behavior, the call

foo ((const int) x);

results in the function call argument being bound to a reference to
non-const (the function parameter). Here's what section 3.10/6 has to say
about the result of casts:

"An expression which holds a temporary object resulting from a cast to
a nonreference type is an rvalue (this includes the explicit creation
of an object using functional notation (5.2.3))."

My suspicion is that the strange behavior is ignoring this rule, and
retaining all the lvalue-ness of the cast's operand. Thus it behaves as we
see when the operand is an lvalue, but not when it is a constant. Consider
this expansion of the original example:

#include <iostream>

void foo(int& x) {std::cout << "In non-const foo\n"; }
void foo(const int& x) { std::cout << "In const foo\n"; }

int main(void)
{
int x = 23;

foo(5);
foo(x);
foo( (const int ) x );
foo( (const int ) 5 );

return 0;
}

The output is:

In const foo
In non-const foo
In non-const foo
In const foo

The third one is the strange one, and can be explained by imagining that
the cast isn't actually producing a "new" temporary value, but rather is
passing the original operand x "as if" it had the desired type. The last
example shows that if you start with a constant (5), it doesn't magically
turn into an lvalue (which is a good thing.)

Another shot in the dark: perhaps Microsoft is interpreting 3.10/6's use of
the term "nonreference" to mean that, when the argument can be bound to a
(non-const) reference in the function call, the result of the cast is no
longer a "nonreference type" and thus exempt from the requirements of being
an rvalue. But if /Za is used, it battens down the hatches. I just have no
idea.

For what it's worth.
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Jul 22 '05 #7

P: n/a
Victor Bazarov wrote:
Gianni Mariani wrote:
Minti wrote:
I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo
gcc 3.4.0 and VC7.1 also says this.

Not the VC7.1 I have. It still says the same as VC7.0. What version of
the compiler do you have? Mine says

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Do I need to update it somehow?


Nope - It was my mistake ... Getting a bit punchy at 9:00AM !

While in case of VC7.0

In const foo
In non-const foo


I suspect it's a bug in VC7.0.


Jul 22 '05 #8

P: n/a
"Gianni Mariani" <gi*******@mariani.ws> wrote...
Victor Bazarov wrote:
Gianni Mariani wrote:
Minti wrote:

I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo

gcc 3.4.0 and VC7.1 also says this.

Not the VC7.1 I have. It still says the same as VC7.0. What version of
the compiler do you have? Mine says

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Do I need to update it somehow?


Nope - It was my mistake ... Getting a bit punchy at 9:00AM !


Gianni, you were correct, the others suggested that "language extensions"
were turned on, and they were correct. I turned language extensions off
and got the behaviour you described. I wonder how long MSoft is going
to keep "extensions" _on_ by default...

Thanks to all for corrections.

V
Jul 22 '05 #9

P: n/a
Leor Zolman wrote:
On Thu, 20 May 2004 12:45:06 -0400, Victor Bazarov
<v.********@comAcast.net> wrote:

Gianni Mariani wrote:
Minti wrote:

I tried the following code on Borland C++ complier [ 5.5.1 ] and
Microsoft VC7.0 both seem to give conflicting results
void foo(const int& x) { std::cout << "In const foo\n"; }
void foo(int& x) {std::cout << "In non-const foo\n"; }

int main(void)
{
foo(5);
int x = 23;
foo( (const int ) x );
return 0;
}

In case of Borland compiler the result is

In const foo
In const foo
[Snip]

I suspect it is a compatibility "feature" of 7.0 (don't ask me what it is
supposed to be compatible /with/, since VC6 does it "right" by default...)

Using both MSVC 7.0 and 7.1 with /Za, I get both const. Without /Za, I get
the one non-const.

A revealing diagnostic comes out when you compile it with Comeau, though:

test.cpp(10): warning: type qualifier is meaningless on cast type
foo( (const int ) x );

This makes sense, as casts always produce a temporary that is not
assignable, I think. So clearly we have a case of the parameter needing to
be a reference-to-const so that it can bind to a temporary.

None of this explains why VC7.x does it the other way by default. MSVC
works in mysterious ways when it comes to its default compatibility mode...
-leor


I dont know if this sheds any light on why MS would have such a language
extension, but you can use a similar cast on an lvalue in VC7.1 with
language extensions on.

const int c = 4;
int n = 5;
volatile int v = 6;

(const int)n = 6; // Fine in VC 7.1 with extensions
(int)v = 3; // Fine in VC 7.1 with extensions

(int)c = 3; // illegal
(unsigned int)n = 7; // illegal
But still ... why?

- Jake Montgomery

Jul 22 '05 #10

P: n/a
On Fri, 21 May 2004 23:44:08 GMT, Jake Montgomery
<ja******************@yahoo.com> wrote:

I dont know if this sheds any light on why MS would have such a language
extension, but you can use a similar cast on an lvalue in VC7.1 with
language extensions on.

const int c = 4;
int n = 5;
volatile int v = 6;

(const int)n = 6; // Fine in VC 7.1 with extensions
(int)v = 3; // Fine in VC 7.1 with extensions

(int)c = 3; // illegal
(unsigned int)n = 7; // illegal

Yup, that's consistent with my "pet theory" in my reply to Minti above:
this language extension allows a cast to serve as a type modifier on the
actual lvalue operand, rather than necessarily resulting in an rvalue
temporary as the Standard dictates.

But still ... why?
Indeed. The kicker, to me, is that MSVC 6 does not seem to exhibit this
extension (at least not by default).
-leor

- Jake Montgomery


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Jul 22 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.