Member Avatar for jack1234

I am using Visual Studio 2005.

Following two programs has the same code, just that one is CLR Console application and the other is Win32 Console application.

I set a break point at int i=1 for both program, for CLR Console application, and when run to the break point, in the local windows,
I have seen none of the value set for the array beans;but for Win32 Console application, the value has been set correctly.

What is the reason for this different?
====CLR Console application====

#include "stdafx.h"

int main(array<System::String ^> ^args)
{
      double beans[3][4];
      beans[0][0] = 0;
      beans[0][1] = 1;
      beans[0][2] = 2;
      beans[0][3] = 3;
      beans[1][0] = 10;
      beans[1][1] = 11;
      beans[1][2] = 12;
      beans[1][3] = 13;
      beans[2][0] = 20;
      beans[2][1] = 21;
      beans[2][2] = 22;
      beans[2][3] = 23;
      double (*pbeans) [4] =beans;
      pbeans++;
      int i=1;
}

====CLR Console application End====


===Win32 Console application=====

int main(){
      double beans[3][4];
      beans[0][0] = 0;
      beans[0][1] = 1;
      beans[0][2] = 2;
      beans[0][3] = 3;
      beans[1][0] = 10;
      beans[1][1] = 11;
      beans[1][2] = 12;
      beans[1][3] = 13;
      beans[2][0] = 20;
      beans[2][1] = 21;
      beans[2][2] = 22;
      beans[2][3] = 23;
      double (*pbeans) [4] =beans;
      pbeans++;
      int i=1;
}

===Win32 Console application End=====

This is what I see for CLR Console App when debugging
http://tinyurl.com/5jq4yb
This is what I see for Win32 Console App when debugging
http://tinyurl.com/69xzmb

I am using debug configuration, and
is what appeared in Projects>TestCLR Properties>Configuration Properties>Command Line
/Od /D "WIN32" /D "_DEBUG" /D "_UNICODE" /D "UNICODE" /FD /EHa /MDd /Yu"stdafx.h" /Fp"Debug\TestCLR.pch" /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /Zi /clr /TP /errorReport:prompt /FU "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.XML.dll"
under Active(Debug) configuration.

  • 3 Contributors
  • 6 Replies
  • 760 Views
  • 3 Months Discussion Span
  • Latest Post Latest Post by Ancient Dragon

Dani AI

Generated

Short summary tied to the thread: the difference in what the Locals window shows for the CLR build versus the Win32 build is a debugger/display issue when the project is compiled with /clr, not a corruption of the array itself. As discovered, installing Visual Studio 2005 SP1 fixed the problem; was correct to suspect the debugger rather than the code.

Why this happens: C++/CLI (/clr) produces mixed-mode frames and different debug information/formatters than a pure native build. The managed expression evaluator and the native debugger use different formatters and symbol interpretations, so C-style stack arrays can fail to be formatted in the Locals pane even though memory holds the right values. This is a presentation artifact rather than a runtime error.

Practical troubleshooting and workarounds:

  • Ensure a Debug build with full debug info (/Zi) and optimizations off (/Od), and confirm the .pdb for the module is loaded in the Modules window.
  • Apply Visual Studio service packs/hotfixes (VS2005 SP1 or later) to get expression-evaluator fixes.
  • When the Locals view is unreliable, inspect raw memory (Debug -> Windows -> Memory) or add a short runtime dump (Console/printf) to verify values.
  • For more reliable debugger display under /clr, prefer managed containers for data you want to inspect (example in C++/CLI):
cli::array<double,2>^ beans = gcnew cli::array<double,2>(3,4);
beans[0,0] = 0;
System::Console::WriteLine(beans[0,0]);
  • If heavy native inspection is required, keep critical native code in a pure native module (or build a native debug configuration) so the native debugger shows values predictably.

On the WinForms question from : WinForms is a managed (.NET) UI; native Win32/GDI is lower-level and can be faster for tight, pixel-bound rendering, but for typical apps the productivity and safety of managed WinForms/WPF outweigh raw speed. A common approach is managed UI with native-optimized libraries for the small performance-critical pieces.

Recommended Answers

All 6 Replies

Member Avatar for Ancient Dragon

Maybe its a compiler debugger bug -- I used VC++ 2008 Express and the CLR version displays the values the same way your link shows for the win32 console program.

Member Avatar for jack1234

Hi Ancient Dragon,
I have updated my VS to Service Pack 1, now CLR Application Console looks normal again!
As you have mentioned, the problem may related to VS debugger itself.
Thanks :)

Member Avatar for serkan sendur

actually i was going to ask the question on title of this thread that is what is the difference between clr console application and win32 console application. how are they different in use etc.

Member Avatar for Ancient Dragon

Very briefly, clr is managed, .NET, program. Win32 console is not.

Member Avatar for serkan sendur

ok i understand what you mean, can you do the same for windows forms development? can you write unmanaged windows forms development so that it can operate faster?

Member Avatar for Ancient Dragon

what makes you think managed code runs faster than unmanaged code? Faster is a relative word -- top speed is not an issue with programs that require human interaction.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.