Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / July 2005

Tip: Looking for answers? Try searching our database.

VC7.1 Compiler bug?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Tommy Andreasen - 13 Jul 2005 13:27 GMT
Hi,
    I have the following code:

--------------------------------------
#include <iostream>

class MyObj
{
public:
  MyObj()
  {
    std::cout << this << " MyObj constructor called\n";
  }

  MyObj(const MyObj&)
  {
    std::cout << this << " MyObj copy constructor called\n";
  }

  ~MyObj()
  {
    std::cout << this << " MyObj destructor called\n";
  }

  operator bool()
  {
    return true;
  }

  bool isOK()
  {
    return true;
  }
};

class Iterator
{
public:
  MyObj getNext() const
  {
    return MyObj();
  };
};

int main(int, char**)
{
  Iterator iter;

  while (MyObj m = iter.getNext())
  {
    if (m.isOK())
      break;
  }

  return 0;
}

-------------------------------------------

When i run the program, I get the following output:

0012FF54 MyObj constructor called
0012FF54 MyObj destructor called
0012FF54 MyObj destructor called

Looks like the destructor is called twice, once after the break
statement and once after leaving the scope of the while loop.

Tommy -

tommy(dot)andreasen(at)radiometer(dot)dk
Carl Daniel [VC++ MVP] - 13 Jul 2005 14:43 GMT
> Hi,
> I have the following code:

This kind of think comes up frequently, and it's usually because someone's
neglected to consider the compiler-generated copy constructor.  In this
case, you've got that covered.  Unless I'm missing something (entirely
possible, it's early), this is a bug in VC7.1 as well as the most current
builds of VC8.

-cd
Mihajlo Cvetanović - 13 Jul 2005 15:49 GMT
> This kind of think comes up frequently, and it's usually because someone's
> neglected to consider the compiler-generated copy constructor.  In this
> case, you've got that covered.  Unless I'm missing something (entirely
> possible, it's early), this is a bug in VC7.1 as well as the most current
> builds of VC8.

At the same time this won't compile:

while (MyObj m(iter.getNext()))
{
}

Neither will this:

while (bool b)
{
}

But this will compile:

while (bool b = true)
{
}

I don't know what all this means, but it doesn't look like a bug to me.
Tom Widmer [VC++ MVP] - 13 Jul 2005 16:41 GMT
>> This kind of think comes up frequently, and it's usually because
>> someone's neglected to consider the compiler-generated copy
[quoted text clipped - 7 lines]
> {
> }

Nor should it according to standard C++ grammar.

> Neither will this:
>
> while (bool b)
> {
> }

Nor should it according to standard C++ grammar.

> But this will compile:
>
> while (bool b = true)
> {
> }

It should compile according to the standard. Basically, if you have a
declaration, you need an '=' for it to be legal in a for or while statement.

> I don't know what all this means, but it doesn't look like a bug to me.

It does to me. From the C++ standard:

2 When the condition of a while statement is a declaration, the scope of
the variable that is declared extends from its point of declaration
(3.3.1) to the end of the while statement. A while statement of the form

while (T t = x) statement

is equivalent to

label:
{ //start of condition scope
  T t = x;
  if (t) {
    statement
    goto label;
  }
} //end of condition scope

The object created in a condition is destroyed and created with each
iteration of the loop. [Example:

struct A {
  int val;
  A(int i) : val(i) { }
  ~A() { }
  operator bool() { return val != 0; }
};

int i = 1;

while (A a = i) {
  //...
  i = 0;
}

In the while-loop, the constructor and destructor are each called twice,
once for the condition that succeeds and once for the condition that
fails. ]

Tom
Carl Daniel [VC++ MVP] - 13 Jul 2005 16:54 GMT
> Hi,
> I have the following code:

[snip]

> Looks like the destructor is called twice, once after the break
> statement and once after leaving the scope of the while loop.

Please submit a bug report at

http://lab.msdn.microsoft.com/productfeedback/

and post a link to the report here so that others can vote on it.  This bug
is still present in the very latest (two days ago) builds of VC++ 2005.

-cd
Carl Daniel [VC++ MVP] - 13 Jul 2005 20:39 GMT
>> Hi,
>> I have the following code:
[quoted text clipped - 11 lines]
> is still present in the very latest (two days ago) builds of
> VC++ 2005.

I submitted it - here's the link:

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=1d698
f32-327b-4f88-acb7-5b5f9164aa24


-cd
Vladimir Nesterovsky - 13 Jul 2005 17:18 GMT
> When i run the program, I get the following output:
>
[quoted text clipped - 4 lines]
> Looks like the destructor is called twice, once after the break
> statement and once after leaving the scope of the while loop.

I believe it's a bug in the while-break construction when while condition
contains variable declaration.

The following works well:

MyObj m = iter.getNext();

while(m)
{
   if (m.isOK())
       break;
}

Signature

Vladimir Nesterovsky
e-mail: vladimir@nesterovsky-bros.com
home: www.nesterovsky-bros.com


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.