VC Language - Operator=() Compilation Question

Author

Operator=() Compilation Question

Tyler

2006-05-23, 7:11 pm

The following snippet of code from a class I am working on compiles when I
compile with STLport, but when I do not use that library, I get a
compilation error (correctly identifying that the function doesn't return a
value). Is anyone able to explain how compiling with STL this might make
the compiler accept the code?

CTest& operator=(CTest const &rfvRHS)
{
if (this != &rfvRHS)
{
iviValue = rfvRHS.iviValue;
}
}

The following are the compiler flags I am using - the compiler is the one
shipped with Visual Studio 2003:
-Zd -GX -D_REENTRANT -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -D_X86_=1 -D_WINNT
-D_WIN32_WINNT=0x0400 -D_WIN32_IE=0x0300 -DWINVER=0x0400 -D__WINDOWS__ -D__WIN32__
-DWIN32 -D_UNICODE -DUNICODE -G5 -W3 /EHa -I.\ -J -c -MD

Thanks, Tyler

Victor Bazarov

2006-05-23, 7:11 pm

Tyler wrote:
> The following snippet of code from a class I am working on compiles
> when I compile with STLport, but when I do not use that library, I
> get a compilation error (correctly identifying that the function doesn't
> return a value). Is anyone able to explain how compiling with STL
> this might make the compiler accept the code?

Actually, not returning a value is supposed to be a warning, no?
Could it be that compiling with STL disables this warning somehow?

>
> CTest& operator=(CTest const &rfvRHS)
> {
> if (this != &rfvRHS)
> {
> iviValue = rfvRHS.iviValue;
> }

Why don't you make your compiler _accept_ this code by adding

return this;

here? :-)

> }
>
> The following are the compiler flags I am using - the compiler is the
> one shipped with Visual Studio 2003:
> -Zd -GX -D_REENTRANT -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo
> -D_X86_=1 -D_WINNT -D_WIN32_WINNT=0x0400 -D_WIN32_IE=0x0300 -DWINVER=0x0400
> -D__WINDOWS__ -D__WIN32__ -DWIN32 -D_UNICODE -DUNICODE -G5 -W3
> EHa -I.\ -J -c -MD
>
> Thanks, Tyler

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Doug Harrison [MVP]

2006-05-23, 7:11 pm

On Tue, 23 May 2006 14:51:57 -0400, "Tyler" <TylerS@newsgroups.nospam>
wrote:

>The following snippet of code from a class I am working on compiles when I
>compile with STLport, but when I do not use that library, I get a
>compilation error (correctly identifying that the function doesn't return a
>value). Is anyone able to explain how compiling with STL this might make
>the compiler accept the code?
>
>CTest& operator=(CTest const &rfvRHS)
>{
> if (this != &rfvRHS)
> {
> iviValue = rfvRHS.iviValue;
> }
>}
>
>The following are the compiler flags I am using - the compiler is the one
>shipped with Visual Studio 2003:
>-Zd -GX -D_REENTRANT -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -D_X86_=1 -D_WINNT
> -D_WIN32_WINNT=0x0400 -D_WIN32_IE=0x0300 -DWINVER=0x0400 -D__WINDOWS__ -D__WIN32__
> -DWIN32 -D_UNICODE -DUNICODE -G5 -W3 /EHa -I.\ -J -c -MD

Search the STLport source for something like the following:

#pragma warning(disable:xxxx)

where xxxx is the error message you get in its absence. Also, the -J option
should be avoided unless you're porting code developed under the
(misbegotten) assumption of unsigned plain char. I'm surprised you don't
get a warning about the use of -GX and -EHa, which should be mutually
exclusive, as -GX implies -EHs. Be careful with -EHa, because catch(...) as
will greedily swallow bugs when it is in effect.

--
Doug Harrison
Visual C++ MVP

Tyler

2006-05-23, 7:11 pm

Thank you to both Doug and Victor.

I didn't think it was possible to suppress a compile error with a #pragma
warning, but in this case it appears that was the case because defining
#pragma warning(disable:4716) makes the compile error go away. The expected
value is returned even without the expected "return" statement ... but I
have added the missing "return" statement to ensure that I'm not relying on
some chance compiler functionality that may one day change.

Thanks again, Tyler

Code Jockey

2006-05-23, 7:11 pm

"Tyler" <TylerS@newsgroups.nospam> wrote in message
news:uBev4npfGHA.4892@TK2MSFTNGP02.phx.gbl...
> The following snippet of code from a class I am working on compiles when I
> compile with STLport, but when I do not use that library, I get a
> compilation error (correctly identifying that the function doesn't return
a
> value). Is anyone able to explain how compiling with STL this might make
> the compiler accept the code?

Because when it is compiling with STLport, the code with the error that you
think is being compiled, is not.

Ulrich Eckhardt

2006-05-24, 4:16 am

Tyler wrote:
> I didn't think it was possible to suppress a compile error with a #pragma
> warning, but in this case it appears that was the case because defining
> #pragma warning(disable:4716) makes the compile error go away.

You are misunderstanding something. The function is in fact valid C++ that a
compiler must compile. Only when invoked it causes 'undefined behaviour'.

> The expected value is returned even without the expected "return"
> statement ... but I have added the missing "return" statement to ensure
> that I'm not relying on some chance compiler functionality that may one
> day change.

The fact that the correct value seems to be returned does not change the
fact that the code is broken. Adding the return statement was the only
right thing to do.

Uli

Tamas Demjen

2006-05-24, 7:10 pm

Ulrich Eckhardt wrote:

> You are misunderstanding something. The function is in fact valid C++ that a
> compiler must compile. Only when invoked it causes 'undefined behaviour'.

No it doesn't compiler, it really generates an error. In VC++ 2005 if
your function has a return type other than void, and you don't have a
return statement, you get an error message, not just a warning.

// this is an error in VC++
int f()
{
}

In other compilers this just generates a warning.

On the other hand, if not all paths return a value, that's treated just
a warning, not an error:

// this generates a warning only
int f2(int a)
{
if(a < 0) return 0;
}

I think it's rather inconsistent. Either both should err out, or none of
them.

Tom

Igor Tandetnik

2006-05-24, 7:10 pm

Tamas Demjen <tdemjen@yahoo.com> wrote:
> No it doesn't compiler, it really generates an error. In VC++ 2005 if
> your function has a return type other than void, and you don't have a
> return statement, you get an error message, not just a warning.
>
> // this is an error in VC++
> int f()
> {
> }
>
> In other compilers this just generates a warning.
>
> On the other hand, if not all paths return a value, that's treated
> just a warning, not an error:
>
> // this generates a warning only
> int f2(int a)
> {
> if(a < 0) return 0;
> }
>
> I think it's rather inconsistent. Either both should err out, or none
> of them.

The reason you get a warning in the second case is that the compiler
often cannot be sure this is an actual error. Consider:

int f(int x) {
assert(0<= x && x <= 2);
switch (x) {
case 0: return 123;
case 1: return 456;
case 2: return 789;
}
// (1) Warning here: not all control paths return a value
}

You know that f() should only ever be passed 0, 1 or 2 as a parameter;
any other value is invalid. Thus, point (1) should never be reached. The
compiler, on the other hand, does not know that. You wouldn't want it to
fail to compile a perfectly valid (if stylistically questionable) code.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Sponsored Links