Bug Unmanaged -> Managed

[eXile]

Hi,

I've prepared a little example for my problem. Please take some time to
undestand it ;) OK, here it is:

class ClassA
{
public:
ClassA()
{
// Empty
}

ClassA( int value )
{
m_value = value;
}

int m_value;
};

class ClassB
{
public:
ClassB()
{
// Empty
}

ClassB( int value0, int value1 )
{
m_values[0] = ClassA( value0 );
m_values[1] = ClassA( value1 );
}

ClassA m_values[2];
};

void main()
{
ClassB test( 1, 2 );
}

So, there is a problem. Or let me say there is half a problem ;) When I
compile this code in a normal Win32-Console-Project, it works properly. But
when I compile this code in an Empty Project (.NET), there is a Bug. In the
constructor of ClassB, m_values[1] does not get any values assigned, while
m_values[0] gets the proper value of 1!
How can this happen - especially if it works in an unmanaged project?!

Greetings,
eXile.

[Doug Harrison [MVP]]

On Fri, 15 Sep 2006 08:24:02 -0700, eXile <eX***@discussions.microsoft.com>
wrote:

>Hi,

I've prepared a little example for my problem. Please take some time to
undestand it ;) OK, here it is:

class ClassA
{
public:
ClassA()
{
// Empty
}

ClassA( int value )
{
m_value = value;
}

int m_value;
};

class ClassB
{
public:
ClassB()
{
// Empty
}

ClassB( int value0, int value1 )
{
m_values[0] = ClassA( value0 );
m_values[1] = ClassA( value1 );
}

ClassA m_values[2];
};

void main()
{
ClassB test( 1, 2 );
}

So, there is a problem. Or let me say there is half a problem ;) When I
compile this code in a normal Win32-Console-Project, it works properly. But
when I compile this code in an Empty Project (.NET), there is a Bug. In the
constructor of ClassB, m_values[1] does not get any values assigned, while
m_values[0] gets the proper value of 1!
How can this happen - especially if it works in an unmanaged project?!

How are you determining this? Your program contains no observable behavior
(formally, I/O statements or writes to volatile variables), so the compiler
can reduce it all to nothing. You should also give the compiler version and
specify the options you use to compile this. When I add a printf statement
and compile with /clr and with and without /O2, I don't observe any problem
with VC.NET 2003 or 2005.

--
Doug Harrison
Visual C++ MVP

[eXile]

Ok I did a little research in the last hours.

First, I inserted some code to print the two values of ClassB to the console
(in both projects). Suprisingly, it printed both times "1 2", so the code
really works. However, something must be wrong either: The debugger says 1
and 0 in the .NET-Project, but 1 and 2 in the Win32-Console-Project.

So I changed my Win32-Console-Project this way:
Add /clr
Remove /RTC1
/Gm - /FD
/ZI -> /Zi
/MLd -> /MTd

Which lead to the same result like in the .NET-Project: The debugger states
1 and 0, the consoles prints 1 and 2.

So my conclusion is:
a) These Options deactivate some debugger-features. However, a debugger
should NOT give wrong information to the programmer (1 and 0 although its 1
and 2).
b) There is a bug in the Microsoft Visual Studio 2003 Debugger.

Thanks for the answer!

"Doug Harrison [MVP]" wrote:

On Fri, 15 Sep 2006 08:24:02 -0700, eXile <eX***@discussions.microsoft.com>
wrote:
How are you determining this? Your program contains no observable behavior
(formally, I/O statements or writes to volatile variables), so the compiler
can reduce it all to nothing. You should also give the compiler version and
specify the options you use to compile this. When I add a printf statement
and compile with /clr and with and without /O2, I don't observe any problem
with VC.NET 2003 or 2005.

[Doug Harrison [MVP]]

On Fri, 15 Sep 2006 09:49:02 -0700, eXile <eX***@discussions.microsoft.com>
wrote:

>So my conclusion is:
a) These Options deactivate some debugger-features. However, a debugger
should NOT give wrong information to the programmer (1 and 0 although its 1
and 2).
b) There is a bug in the Microsoft Visual Studio 2003 Debugger.

This is why I believe that observing a problem only in the debugger is
tantamount to not observing it at all. Debuggers are for illuminating
problems you've already discovered, not for verifying correct operation of
your program.

--
Doug Harrison
Visual C++ MVP