delete[] problem with release config...

This is a discussion on delete[] problem with release config... within the C++ Programming forums, part of the General Programming Boards category; I have a problem with trying to "delete[]" a pointer. I use MSVC++, and I know that we can call ...

  1. #1
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114

    delete[] problem with release config...

    I have a problem with trying to "delete[]" a pointer. I use MSVC++, and I know that we can call without any problem (normally) "delete[]" on a pointer that isn't being allocated to something, example:
    Code:
    int* a = 0;
    delete[] a;
    a = new int[100];
    Though that worked, until today, when I changed my application's settings to "release", (instead of "debug") so it would get more optimized... But then it doesn't work anymore. Is this possible that "delete[]" on "release" configuration will not check for if the variable was already assigned to something? Is this possible that a "#define" for configuration might check in that delete function what is the configuration? Or am I unlucky?

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,431
    Could you post the smallest and simplest compilable (or what you think should be compilable) code that demonstrates the error? Stating which version of MSVC used may also be useful for testing.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >Is this possible that "delete[]" on "release" configuration
    No, in all configurations, delete[] is required to do nothing if given a null pointer. The only possible way this could happen, aside from a compiler bug, is if the global operator delete[] is replaced with a function that fails to perform this check. I would wager that your problem is somewhere else and only causes trouble at that point in your code.
    My best code is written with the delete key.

  4. #4
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    Well, it seem that I figured out something else in the meanwhile, but for MSVC version, I have MSCV++ .NET... Well, so my piece of code comes from a class I was building, that looks something like this:

    Code:
    class Image {
    	private:
    		UINT	Width,
    				Height,
    				*Pixels;
    	public:
    		Image() {
    			Pixels = 0;
    		}
    		void Load_Image(string File_Name)
    		{
    			ifstream	File;
    			File.open(File_Name.c_str(), std::ios::in | std::ios::binary);
    			File.read((char*)&Width, 4);
    			File.read((char*)&Height, 4);
    			delete[] Pixels;
    			Pixels = new UINT[Width * Height];
    			//all sort of other things...
    		}
    };
    Note that I have only placed the beggining of the loading function, not to worry with all my other lines. So what I'm doing is a kind of image class, to load image in a file that I create myself, just for learning purposes... So I placed a "delete[]" where it should be when you would need to load a second image, just deleting in the same time the previous one stored in memory. Altough that some people would prefer placing the delete in another class's method, I just wanted to leave it there...

    So this works to what I have concluded if the project is done in "debug" options, or under "release", if and only if the constructor is called AND if the class is used with a pointer. To all other tries I made, I get a "user breakpoint error at the "delete" line...

  5. #5
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    I would wager that your problem is somewhere else and only causes trouble at that point in your code.
    Saddly, I know that this is too much often true, but in those cases the error takes soo much time to find out. (At least for me, though...)

  6. #6
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >in those cases the error takes soo much time to find out. (At least for me, though...)
    For all of us. Memory bugs that don't show up until well after the corruption are among the most painful. Sometimes all you can do is watch the pointer and step through your program.
    My best code is written with the delete key.

  7. #7
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    It is strange indeed. Are you sure you aren't deleting the pointer somewhere else?

    EDIT: The class destructor will do that for you. But I reckon that is not what is happening, is it? I mean, you are calling Load_Image() repeatedly on the same instance.
    Last edited by Mario F.; 08-21-2006 at 09:53 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I'm pretty sure that MSVC++6 crashed when deleting a NULL pointer. Maybe .Net 2002 (the first .Net) still exhibits the same behaviour?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    You're going to have to paste a compilable and complete program which demonstrates the problem (try and make it as small as possible if you want people to actually look).

    Whilst the problem shows up here, it is almost certain that the problem is down to mis-use of any prior allocated block, and without seeing the whole thing which crashes, there's no way to tell which one it might be.

    Start by examinining all your new calls to check the sizes are correct.

    Also, in a debug build, use crtdbg.h to assist with finding typical things which go wrong
    - using uninitialised data
    - use before alloc
    - use after free
    - double free
    - freeing what wasn't allocated
    - writing past the end of the buffer
    http://www.amanjit-gill.de/articles/vc6_debug.html
    http://msdn.microsoft.com/library/de...ngFeatures.asp
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Results in Debug and Release mode are different
    By jaro in forum C Programming
    Replies: 11
    Last Post: 05-27-2006, 11:08 AM
  2. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 05:24 PM
  3. Mesh Release() Problem
    By Morgul in forum Game Programming
    Replies: 6
    Last Post: 03-07-2006, 01:50 PM
  4. Replies: 5
    Last Post: 11-07-2005, 10:34 PM
  5. half ADT (nested struct) problem...
    By CyC|OpS in forum C Programming
    Replies: 1
    Last Post: 10-26-2002, 08:37 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21