Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Debug vs Release Configuration

Debug vs Release Configuration

Scheduled Pinned Locked Moved C / C++ / MFC
visual-studiodebuggingquestionannouncementworkspace
5 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • O Offline
    O Offline
    Oliver123
    wrote on last edited by
    #1

    I have a program working fine when active configuration is set to debug-I build it, then execute. When I change the configuration to release, it compiles OK, but when I execute it the background of the dialog turns black, and buttons that displayed integers display nothing. The buttons are set with GetDlgItem(IDC_BUTTON14)->SetWindowText(newText) Ideas? Thanks.

    D 1 Reply Last reply
    0
    • O Oliver123

      I have a program working fine when active configuration is set to debug-I build it, then execute. When I change the configuration to release, it compiles OK, but when I execute it the background of the dialog turns black, and buttons that displayed integers display nothing. The buttons are set with GetDlgItem(IDC_BUTTON14)->SetWindowText(newText) Ideas? Thanks.

      D Offline
      D Offline
      David Crow
      wrote on last edited by
      #2

      Compare your debug vs. release settings for both the compiler and linker.


      "A good athlete is the result of a good and worthy opponent." - David Crow

      "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

      O 1 Reply Last reply
      0
      • D David Crow

        Compare your debug vs. release settings for both the compiler and linker.


        "A good athlete is the result of a good and worthy opponent." - David Crow

        "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

        O Offline
        O Offline
        Oliver123
        wrote on last edited by
        #3

        I'm not experienced enough to totally understand what you mean, but I gave it a try. I looked at PROJECT SETTINGS, and toggled between "Settings for Debug" and Settings for Release." Under tab LINK, GENERATE DEBUG and LINK INCREMENTALLY are checked. Under tab RELEASE, neither is checked. I didn't know where to look to check the settings for COMPILER. I did manage to solve the background color problem by setting the background in InitDalog, but the disappearing integers in the button text still have me stumped. thanks.

        _ 1 Reply Last reply
        0
        • O Oliver123

          I'm not experienced enough to totally understand what you mean, but I gave it a try. I looked at PROJECT SETTINGS, and toggled between "Settings for Debug" and Settings for Release." Under tab LINK, GENERATE DEBUG and LINK INCREMENTALLY are checked. Under tab RELEASE, neither is checked. I didn't know where to look to check the settings for COMPILER. I did manage to solve the background color problem by setting the background in InitDalog, but the disappearing integers in the button text still have me stumped. thanks.

          _ Offline
          _ Offline
          _AnsHUMAN_
          wrote on last edited by
          #4

          Do you check that the variables have been initialized properly. A variable may have a different value in the release and in the debug build, causing the differing behaviour. And if you go back and see where the value of that variable is set, you will most probably find out that it isn't: You simply forgot to initialize that variable. The reason why the debug build seemed to work is that the debug version of the runtime library initializes dynamic memory and stack variables to known values (in order to track down memory allocation and overwrite errors), while the release version of the runtime library doesn't.

          Somethings seem HARD to do, until we know how to do them. ;-)_AnShUmAn_

          D 1 Reply Last reply
          0
          • _ _AnsHUMAN_

            Do you check that the variables have been initialized properly. A variable may have a different value in the release and in the debug build, causing the differing behaviour. And if you go back and see where the value of that variable is set, you will most probably find out that it isn't: You simply forgot to initialize that variable. The reason why the debug build seemed to work is that the debug version of the runtime library initializes dynamic memory and stack variables to known values (in order to track down memory allocation and overwrite errors), while the release version of the runtime library doesn't.

            Somethings seem HARD to do, until we know how to do them. ;-)_AnShUmAn_

            D Offline
            D Offline
            dharani
            wrote on last edited by
            #5

            Hello

            _AnShUmAn_ wrote:

            A variable may have a different value in the release and in the debug build, causing the differing behaviour

            Well , to add to it I say you most probably have a code optimization problem in the section of code which looks suspecious to you . You may find the values of variables in release by classical AfxMessageBox(value) displays . I have come across a situation where in release mode a string = "systarg" was represented in stack as "g|a|sys|t" which resulted in change of code flow . I did the following to solve it Try this add the following pramas around the section of code which looks problamatic #ifndef _DEBUG #pragma optimize("", off) #endif ..... your code which works fine in debug #ifndef _DEBUG #pragma optimize("", on) // désactivation de toutes les optimisations #endif

            redindian

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups