Advertisement

Interesting compiler bug (maybe).

Started by March 07, 2001 12:20 AM
13 comments, last by Dire.Wolf 23 years, 10 months ago
While reading the Topic "Simple question about IFs, ANDs, ORs" I discovered this weird quirk of C++ 9or maybe just the compiler)
  
using namespace std;

class Object
{
	public:
	    bool IsReady() { return true; }
};

int main()
{
	Object* p = NULL;

	if(!p && p->IsReady())
	{

	}

	return 0;
}
  
p->IsReady() should cause an access violation because p is a pointer to NULL. Unfortunately (or fortunately?) because Object''s IsReady method is declared inline, p->IsReady() is replaced by the compiler with the inline code. Should this be considered a bug? Dire Wolf
www.digitalfiends.com
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
It isn't bug.It's too simple.
(I don't know english too good, but I try ask you.)
When you declare class: you take memory for create table of function.
And you already can use your function.(as your example code)
When you create object of class you take memory only for
member-property. Such as:

class Object
{
public:
bool IsReady()
{
return true;
}
bool property1;
int property2;
};

If you write:

if(!p && p->property1)
{}
you see allocation memory error.

Inline and namespace not matter...






Edited by - StarikLesovik on March 7, 2001 3:49:29 AM
Advertisement
This is a C-feature (and since C is a subset set of C++, it will be the same way in C++), C uses lazy evaluation on the operators || and &&, to allow just these things:

if(true || b()) // b() will never be called

if(false && b()) // poor b() won''t be called now either

So it''s not a compiler bug, it''s a feature .
It doesn''t feel like a bug either. It''s the most intelligent way to evaluate such expressions.
Just realised I read it incorrectly (mainly because I hadn''t read the "IFs, ANDs and ORs" (or whatever) topic). Still a test like if(!p && p->Something()) seems a bit odd, it''s a logic-error anyway. But I must say that it''s sematically correct, it is the same as writing if(!p && true) and if(!p), since IsReady() is a constant expression. So I guess my point remains, it''s not a bug it''s a feature .
HA! I got a bug for ya!

It''s In MSVC++ 4. I don''t know if they fixed it.. I haven''t checked.


//-----------------------\\
// Bug Is In The Comment \\
//-----------------------\\
int main()
{
return 0;
}


That does not compile. the \\ Screws up the comment and reads line with int main() on it as blank. So you get a error abour returning without a function..

------------------------------------------------------------I wrote the best video game ever, then I woke up...
Advertisement
Yo Disco Pimp. Whattcha dissin me groove pirate stylee for man. You gotta pay *maximum* respect to the operator at the church o'' newline m'' friend.

Back on the streets a'' Philly, we usa bust asses o'' honkeys like ya who diss the C in a visual style

Try this y commie funk

  //-----------------------// Bug Is In Ma Disrespectful ass//-----------------------int main(){return 0;}  

Yo Disco Pimp. Whattcha dissin me groove pirate stylee for man. You gotta pay *maximum* respect to the operator at the church o'' newline m'' friend.

Back on the streets a'' Philly, we usa bust asses o'' honkeys like ya who diss the C in a visual style

Try this y commie funk

  //-----------------------// Bug Is In Ma Disrespectful ass//-----------------------int main(){return 0;}  

Yo Disco Pimp. Whattcha dissin me groove pirate stylee for man. You gotta pay *maximum* respect to the operator at the church o'' newline m'' friend.

Back on the streets a'' Philly, we usa bust asses o'' honkeys like ya who diss the C in a visual style

Try this y commie funk

  //-----------------------// Bug Is In Ma Disrespectful ass//-----------------------int main(){return 0;}  

Something you should remember about expressions, they''re evaluated from right to left on many compilers, so doing:

  if (!p && p->IsReady()) turns into:if ( p->IsReady() ){  if (!p)  {    ...  }}  



The operators in use can also change the order, which is why you should never write code like the above which assumes every compiler will parse an expression in the same way.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

This topic is closed to new replies.

Advertisement