C / C++ / MFC

Kiran Kumar Singani wrote:

U can set the dialog into the ur property page 3 dynamically

Return 0 to allow the wizard to go to the next page. Return -1 to prevent the wizard from changing pages. To display a particular page, return its dialog resource identifier.

Michael Dunn wrote:

To display a particular page, return its dialog resource identifier.

RockyJames wrote:

How to get Current Color Scheme of the System.I am working on Widnows Xp.How to get the current Color Scheme that is selected .

RockyJames wrote:

How to get Current Color Scheme of the System.I am working on Widnows Xp.How to get the current Color Scheme that is selected .

rbid wrote:

All this code runs under the same thread

A_Laxman wrote:

rbid wrote:
All this code runs under the same thread

Create the seperate synchronised threads for the large calculations
and which is not much dependent on each other

Saurabh.Garg wrote:

ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Saurabh.Garg
Date:4:32 20 May '06

If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations.

If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem.

Hope this helps.

-Saurabh

Saurabh.Garg wrote:

ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Saurabh.Garg
Date:22:21 20 May '06

Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using

#pragma optimize( "", off )
.
.
.
#pragma optimize( "", on )

Saurabh.Garg wrote:

ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Saurabh.Garg
Date:22:36 21 May '06

So were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems.

-Saurabh

• Writing Efficient C and C Code Optimization[^]


• Look forAssume No Aliasing, Assume Aliasing Across Function Calls in the MSDN documentation (I could not find the internet link)

Ryan Binns wrote:

ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Ryan Binns
Date:7:53 20 May '06

I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile.

Ryan Binns wrote:

ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Ryan Binns
Date:20:38 20 May '06

One other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area.

Ryan

Ray Hagstrom wrote:

ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Ray Hagstrom
Date:14:46 20 May '06

Sounds a lot like scientific programming.

Ray Hagstrom wrote:

1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.)

Ray Hagstrom wrote:

2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.)

• First I added to the beginning and end of all source files (not header files) the following line:
  

  // Add at the beggining of the file:
  #pragma optimize( "", off )
  ...
  // Add at the end of the file:
  #pragma optimize ("", on )



• Then file by file, once a time I removed the pragma to see if the problem appears, if yes, mark the file as problematic and continue to the next file.(restoring the #pragma to the beggining of it)


• Once I finished with all files, and ending with a pair of problematic files, I started to do the same for isolating the "functions" that caused the problem.



// Add before the function body:
#pragma optimize( "", off )
...
// Add after the function closinc brace:
#pragma optimize ("", on )



• At the end, I found that only a small number of functions were the ones that caused the problem, and the reason was variable aliasing.