Compiler failure 
Author Message
 Compiler failure

Compiler does not flag bad code as error.

Microsoft Visual C++ .NET   55603-652-0000007-18682 //current
Microsoft Visual C++ .NET   55603-000-0000007-18240 //beta

class t {
    bool PopOne( int* item ) {
    } //no value returned

    bool Pop( int* item ) {
        bool ok = PopOne;  //no arguments supplied
    }

Quote:
};



Sun, 24 Jul 2005 04:43:32 GMT  
 Compiler failure
Jon,

Quote:
> Compiler does not flag bad code as error.

> Microsoft Visual C++ .NET   55603-652-0000007-18682 //current
> Microsoft Visual C++ .NET   55603-000-0000007-18240 //beta

> class t {
>     bool PopOne( int* item ) {
>     } //no value returned

>     bool Pop( int* item ) {
>         bool ok = PopOne;  //no arguments supplied
>     }
> };

Well, it does have two significant error, and another that while it's a
problem, I doubt it's gonna be fixed any soon, since it affects existing
code.

The two errors are, of course, that there's no return statement for either
t::Pop or t::PopOne.

The other problem is, of course, with this line:
bool ok = PopOne;  //no arguments supplied

Now, I don't know what you were expecting it to do. It seems, from your
comment, that you expected an error because there were no arguments supplied
to the call of PopOne. Unfortunately, that's not how it looks to the
compiler. Since there are no parens (()), it presumes you're trying to take
the address of PopOne and applies then a conversion to bool from the
resulting value. The problem is not the latter, but the former, in the sense
that the proper way to take the address of a non-static member function in
C++ is the syntax &t::PopOne.

--
Tomas Restrepo



Mon, 25 Jul 2005 12:01:41 GMT  
 Compiler failure
1)
I read where you can convert pointers to static functions to a bool.
I have never read where you can convert pointers to member functions to a bool.
I though that was just an error.  My mistake.

2)

Quote:
> Well, it does have two significant error, and another that while it's a
> problem, I doubt it's gonna be fixed any soon, since it affects existing
> code.

I don't know about that. The following WILL flag the missing returns as errors.
So why does the compiler flag it in one case but not the other?
The only difference I can see is that the function is being called in the same module.
Very strange.

class t {
     bool PopOne( int* item ) {
     } //no value returned

     bool Pop( int* item ) {
         bool ok = PopOne;  //no arguments supplied
     }

Quote:
};

#pragma managed
public __gc class Test {
public:
    static void Fn() {
        int i;
        Class c;
        c.Pop(&i);
    }

Quote:
};


Quote:
> Jon,

> > Compiler does not flag bad code as error.

> > Microsoft Visual C++ .NET   55603-652-0000007-18682 //current
> > Microsoft Visual C++ .NET   55603-000-0000007-18240 //beta

> > class t {
> >     bool PopOne( int* item ) {
> >     } //no value returned

> >     bool Pop( int* item ) {
> >         bool ok = PopOne;  //no arguments supplied
> >     }
> > };

> Well, it does have two significant error, and another that while it's a
> problem, I doubt it's gonna be fixed any soon, since it affects existing
> code.

> The two errors are, of course, that there's no return statement for either
> t::Pop or t::PopOne.

> The other problem is, of course, with this line:
> bool ok = PopOne;  //no arguments supplied

> Now, I don't know what you were expecting it to do. It seems, from your
> comment, that you expected an error because there were no arguments supplied
> to the call of PopOne. Unfortunately, that's not how it looks to the
> compiler. Since there are no parens (()), it presumes you're trying to take
> the address of PopOne and applies then a conversion to bool from the
> resulting value. The problem is not the latter, but the former, in the sense
> that the proper way to take the address of a non-static member function in
> C++ is the syntax &t::PopOne.

> --
> Tomas Restrepo




Mon, 25 Jul 2005 13:04:43 GMT  
 Compiler failure
Hi Jon,

Quote:
> I don't know about that. The following WILL flag the missing returns as
errors.
> So why does the compiler flag it in one case but not the other?

I think the reason for this is that if you just compile the t class by
itself, there's no one calling it, so the compiler ignores it as long as the
code is not getting called. As soon as you force the call, the compiler will
indeed flag the error.

--
Tomas Restrepo



Wed, 27 Jul 2005 11:48:42 GMT  
 Compiler failure
What possible purpose is there in not generating error messages just because your code is only called from other compilation units.

Since you usually are writing object that are in separate compilation units, the above condition is the norm.

I still consider this a compiler failure that needs to be fixed.


Quote:
> Hi Jon,

> > I don't know about that. The following WILL flag the missing returns as
> errors.
> > So why does the compiler flag it in one case but not the other?

> I think the reason for this is that if you just compile the t class by
> itself, there's no one calling it, so the compiler ignores it as long as the
> code is not getting called. As soon as you force the call, the compiler will
> indeed flag the error.

> --
> Tomas Restrepo




Wed, 27 Jul 2005 21:12:08 GMT  
 Compiler failure
Functions marked inline (or implicitly marked inline because they are
defined inside the class definition) don't go to this code path in the
compiler in their definition, but only in the places where they are used.
You can make a perfectly valid argument that it would be better to do the
check even for inline functions at their definition point, but that is not
what actually happens in the current compiler which is why we have the
issue.

Ronald Laeremans
Visual C++ team


Quote:
> What possible purpose is there in not generating error messages just

because your code is only called from other compilation units.
Quote:

> Since you usually are writing object that are in separate compilation

units, the above condition is the norm.
Quote:

> I still consider this a compiler failure that needs to be fixed.




Quote:
> > Hi Jon,

> > > I don't know about that. The following WILL flag the missing returns
as
> > errors.
> > > So why does the compiler flag it in one case but not the other?

> > I think the reason for this is that if you just compile the t class by
> > itself, there's no one calling it, so the compiler ignores it as long as
the
> > code is not getting called. As soon as you force the call, the compiler
will
> > indeed flag the error.

> > --
> > Tomas Restrepo




Thu, 28 Jul 2005 10:34:31 GMT  
 Compiler failure

Quote:
> What possible purpose is there in not generating error messages just
> because your code is only called from other compilation units.

> Since you usually are writing object that are in separate compilation
> units, the above condition is the norm.

> I still consider this a compiler failure that needs to be fixed.

It sounds like you don't understand what/why this is happening.  These
functions cannot be called from another compilation unit without having
their definition available in that other compilation unit (they are inline.)
If an inline function isn't called, code isn't generated for it (and if code
isn't generated you will only see diagnostics generated during parsing.)  If
you look in the generated object file, you'll see these functions were not
emitted into it (and therefore they clearly cannot have been called from
another translation unit without having been compiled seperately in that
other compilation unit.)

This is how inline functions work.



Thu, 28 Jul 2005 14:52:42 GMT  
 Compiler failure
Thanks guys for the straighten this out for me..


Quote:


> > What possible purpose is there in not generating error messages just
> > because your code is only called from other compilation units.

> > Since you usually are writing object that are in separate compilation
> > units, the above condition is the norm.

> > I still consider this a compiler failure that needs to be fixed.

> It sounds like you don't understand what/why this is happening.  These
> functions cannot be called from another compilation unit without having
> their definition available in that other compilation unit (they are inline.)
> If an inline function isn't called, code isn't generated for it (and if code
> isn't generated you will only see diagnostics generated during parsing.)  If
> you look in the generated object file, you'll see these functions were not
> emitted into it (and therefore they clearly cannot have been called from
> another translation unit without having been compiled seperately in that
> other compilation unit.)

> This is how inline functions work.



Fri, 29 Jul 2005 01:02:45 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. help - midl compiler failure

2. midl compiler failure !!

3. C1001: INTERNAL COMPILER ERROR (compiler files 'msc1.cpp', line 2844)

4. C# compiler's compiler ?

5. Migration from HP Cfront compiler to HP aCC compiler

6. Need of an old compiler like Microsoft C Compiler V 6.0

7. Why Pascal/Java compilers are faster than C and C++ compilers

8. fortran to c compiler (f2c) compiler

9. Does C compiler equal C++ compiler ?

10. Sun C Compiler vs. Gnu C Compiler

11. C compiler internals, a account of implementation of C compiler

12. C compiler internals, a account of implementation of C compiler

 

 
Powered by phpBB® Forum Software