Archived

This topic is now archived and is closed to further replies.

weird try and catch statement messing up my code...

This topic is 5304 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Edit: After some trying and stuff I have found where the problem is happening. Namely where I create the surfaces, I create the surfaces the normal way(eh ddraw tutorial way )... However I cant see any connection between this and the try and catch statement before this even happends... eh.. any ideas? (im desperate!) I am allocating a bit of memory before I execute my small directdraw library which just initializes a window and setups direct draw, and assign some function pointers and begins the main loop. Think glut but for direct draw. But what is happening is; the resolution changes and then the program quits. However if I remove my memory allocation code it works perfectly fine. eh.. and I have tried surrounding the allocation code with a try and catch statement that outputs whatever error in a messagebox and then exits the application. However it still changes resoultion and then exits the application, without a sign of error. I even tried changing to malloc instead of new, and used an if statement, but no output(the same as before)... Hmm... any ideas? oh, my setup looks basically like this:>
Map map;

void render()
{
}

void createMap(Map* map)
{
     try 
     {
         map->data = new char*[8];
         for(int i=0; i<8; i++)
             map->data[i] = new char[8];

     }catch(...){ throw("Could Not Allocate memory!"); }
}

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    // here is the allocation part happening

    try
    {
         createMap(&map);
    }catch(char* e){
        MessageBox(NULL, e, "Error", MB_OK);
        return 0;
    }
   
    // setup direct draw and resolution

    DDInit(1024, 768, 16);
    DDSetRenderFunc(render);
    DDRun();

    // destroy the map data

    destroyMap(&map);
    return 0;
}
Edit:> I changed the code and remove the allocation part. And put this instead:>
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    int x;
    try
    {
         x++;
    }catch(char* e){
        MessageBox(NULL, e, "Error", MB_OK);
        return 0;
    }
   
    // setup direct draw and resolution

    DDInit(1024, 768, 16);
    DDSetRenderFunc(render);
    DDRun();

    // destroy the map data

    destroyMap(&map);
    return 0;
}
And it gives the same result as the above example... eh.. can someone like tell me whats going on?(im going nuts) edit again: darn source tag messing up when edititing post... [edited by - pag on June 3, 2003 2:39:36 AM]

Share this post


Link to post
Share on other sites
This simply isn''t possible. The allocation part you posted here is just fine, there''s no error in the code, even if the design could be improved.

Try stepping into your program with the debugger and seeing how it gets executed. Seems to me that the problem would be either in a DLL that gets loaded before your program starts (very unlikely) or that the control flow of your program gets upset and something later on causes it to jump back to the start (a bit, but not that much, more likely). The most likely by far, though, is that the error lies elsewhere, in code you haven''t posted. It''s usually something like overwriting an array boundary or dereferencing an invalid pointer.

Share this post


Link to post
Share on other sites
quote:

int x; <- unintialised x
x++; <- undefined behaviour


Not undefined behaviour, just undefined value. And this piece of code cant create an exception.

Anyways, I have debugged the code several times but cant find anything wrong. Either its my bad debugging knowledge, or there is just not anything wrong with the code.
However I have just deleted the god damn files and hope I never gets to see them again. I also has begun rewriting the stuff all over again, and if I get the same problem again im gonna stop programming or somthing, god damnit!

thanks anyways

Share this post


Link to post
Share on other sites
Debugging this should be quite easy:

  • Move the cursor onto the very first line of code in WinMain ("try" in this case).
  • Hit Ctrl-F10 to run to that point.
  • Once there:

    • Hit F10 to execute a line that doesn''t contain a function call.
    • Or F11 to execute one that does (this goes into the function).

  • When the exception occurs, you should either get a message box (if you don''t catch the exception in code) or the cursor will jump to a catch line. Whatever code was being executed when this happened triggered the exception.


Note that that code might not actually have caused it (just triggered it). The exception will have been caused by some code that has been executed up to that point (you should''ve seen it execute). Those are the important things you ought to look at.

Share this post


Link to post
Share on other sites
quote:
Original post by pag
Not undefined behaviour, just undefined value.

Accessing an uninitialised variable results in undefined behaviour.
quote:

And this piece of code cant create an exception.

Undefined behaviour can legally do anything.

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
quote:
Original post by pag
Not undefined behaviour, just undefined value.

Accessing an uninitialised variable results in undefined behaviour.
quote:

And this piece of code cant create an exception.

Undefined behaviour can legally do anything.



pag was correct. This is not undefined behaviour. The value of x is just something we can't rely on, therefore an undefined value. x++ will just increment that value, which is very defined behaviour. This code will not cause an exception, but if you try to use x somewhere, like in an array, then you could have problems.

[edited by - fizban75 on June 3, 2003 1:46:37 PM]

Share this post


Link to post
Share on other sites
quote:

Move the cursor onto the very first line of code in WinMain ("try" in this case).

Hit Ctrl-F10 to run to that point.

Once there:



Hit F10 to execute a line that doesn't contain a function call.

Or F11 to execute one that does (this goes into the function).



When the exception occurs, you should either get a message box (if you don't catch the exception in code) or the cursor will jump to a catch line. Whatever code was being executed when this happened triggered the exception.


I would be glad if I could do just that, however im using borlan c++ 5.5 cmdline blaha.... anyways as I said the files are deleted, and I have just finished rewriting the stuff and it seems this far everything is working fine...

quote:

quote:
--------------------------------------------------------------------------------
Original post by pag
Not undefined behaviour, just undefined value.
--------------------------------------------------------------------------------


Accessing an uninitialised variable results in undefined behaviour.

quote:
--------------------------------------------------------------------------------

And this piece of code cant create an exception.
--------------------------------------------------------------------------------


Undefined behaviour can legally do anything.



edit: oh and this variable is defenetly not uninitialized. If so it would be a pointer pointing to nowhere or anywhere...

How in the world could this happend? The integer is just 32 bits of data. Each of these 32 bits are either set or not and this can in no way cause any undefined behaviour or exceptions, all it can do is give me a random number.
Heh. I could even write this code without it crashing:>

int i;
while(1)
{
i++;
if(getInput()) break;
}


[edited by - pag on June 3, 2003 1:31:34 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by fizban75
pag was correct. This is not undefined behaviour. The value of x is just something we can''t rely on, therefore an undefined value. x++ will just increment that value, which is very defined behaviour.

No it isn''t. The relevant section of the C++ Standard is as follows:

quote:
4.1 Lvalue-to-rvalue conversion
An lvalue of a non-function, non-array type T can be converted to an rvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized , a program that necessitates this conversion has undefined behaviour


That means it is safe to do things like take the address of x, but incrementing the value requires an lvalue-to-rvalue conversion.

The same is implied in footnote 42...

quote:

Using a bool value in ways described by this International Standard as "undefined", such as by examining the value of an uninitialized automatic variable , might cause it to behave as if is neither true nor false.

Share this post


Link to post
Share on other sites
quote:

5.2.6 - Increment and decrement [expr.post.incr]

-1- The value obtained by applying a postfix ++ is the value that the operand had before applying the operator. [Note: the value obtained is a copy of the original value ] The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type or a pointer to a complete object type. After the result is noted, the value of the object is modified by adding 1 to it, unless the object is of type bool, in which case it is set to true. [Note: this use is deprecated, see annex depr. ] The result is an rvalue. The type of the result is the cv-unqualified version of the type of the operand. See also expr.add and expr.ass.



I take that to mean that there is no lvalue-to-rvalue-conversion on x itself. The result of the operation is an rvalue, but x itself is required to be an lvalue and therefore no conversion is done. And since that rvalue is never accessed, I don''t see a necessity for the lvalue-to-rvalue-conversion on the result, and therefore no undefined behaviour. However, if that value were to be accessed like I mentioned above, then the conversion is necessitated and there could be undefined behaviour, such as:

x = v[x++];

I''ve found that in practice, the code:

int x;
x++;

will not cause an exception nor will it cause any other undefined behaviour in the program.

Share this post


Link to post
Share on other sites
quote:
Original post by fizban75
I''ve found that in practice, the code:

int x;
x++;

will not cause an exception nor will it cause any other undefined behaviour in the program.

You do understand the meaning of undefined behaviour, don''t you? It means that anything might happen, including apparently sane behaviour. However, the C++ Standard caters to many architectures, including ones which might trap on access to uninitialised storage. Just because your compiler happens to do what you assume would happen in certain circumstances, does not change that the C++ Standard declares it as undefined behaviour, which has nothing to do with what you''ve observed or what you believe is correct.

Share this post


Link to post
Share on other sites
quote:

You do understand the meaning of undefined behaviour, don''t you?



Sabre, why can''t you just discuss topics in a grown up manner, rather than attacking people? If you''d like to point out my errors in judgement and interpretation, so be it. I welcome it. But you don''t have to put down others in the process.

Now, that aside, I also discussed the 5.2.6 section of the standard in my last post and I''d appreciate your comments on my interpretation. I don''t believe that the code:

int i;
i++;

necessitates an lvalue-to-rvalue-conversion, but if you think otherwise, I''d like to hear your thoughts.

Share this post


Link to post
Share on other sites
I believe that he is telling you just because your compiler does intialize the variable for you does not mean all compilers will. Making it almost impossible to port to another compiler if they are not up todate with pre-processing it.

I do not see where he is putting you down either.
Rather that he is telling you what undefined really means. That they saw it was possible to have issues doing things this way but deciede it would be best left to the developer to correct than make a assumition on the users part. The saw wholes in ways some programmers might program and told the compiler vendors that do what you want (produce compile errors,warnings,default the values) what ever they might have thought was the intended use of the variable.

Share this post


Link to post
Share on other sites
fprintf is your friend. Put fprintfs in your code to see where exactly it crashes. The error is almost certainly in one of your DD* functions and the presence or lack of those memory allocations just happens to change the symptoms.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Share this post


Link to post
Share on other sites
quote:
Original post by fizban75
Now, that aside, I also discussed the 5.2.6 section of the standard in my last post and I''d appreciate your comments on my interpretation. I don''t believe that the code:

int i;
i++;

necessitates an lvalue-to-rvalue-conversion, but if you think otherwise, I''d like to hear your thoughts.


The portion of the standard you quoted says "The value obtained by applying a postfix ++ is the value that the operand had before applying the operator. [Note: the value obtained is a copy of the original value ]". The copying of the operand for assignment implies (to me anyway) an lvalue to rvalue conversion.

Share this post


Link to post
Share on other sites
We are getting a bit from the point, lets try to help the OP instead of bashing each other with the standard.

Anyway, undefined behavior or not, x++ should not throw an char* exception. That is very unlikely. Try to remove ALL other code and leave only a small test program, if this works you have a problem somewhere else in your code:


#include <windows.h>
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
int x = 0;
try
{
x++;
}
catch (...)
{
MessageBox(NULL, "Unknown exception", "Error", MB_OK);
}
return 0;
}


[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]

Share this post


Link to post
Share on other sites
quote:
Original post by afterburn
I believe that he is telling you just because your compiler does intialize the variable for you does not mean all compilers will.

No, that''s not what I''m saying. All correct compilers should initialise variables under the same circumstances, and I''d expect the problem given to always result in an uninitialised variable. What I''m saying is that any attempt to inspect an uninitialised variable results in undefined behaviour. I''m also pointing out that `undefined behaviour'' is not just a colloquial term, but a term that has a definition according to the C++ Standard, so it is not open to interpretation what it actually means. If a compiler chooses to implement this particular behaviour as `take the value represented by the bit-pattern at the uninitialised location and interpret it as a valid value'' then that will not violate the meaning of undefined behaviour. However, some platforms might choose to implement access to uninitialised variables by trapping the access. It is possible the uninitialised bit-pattern constitutes an invalid value for the type - the quote I gave earlier gives the example of an indeterminate boolean. The actual results of uninitialised variable access depend on the platform and compiler being used - which is why the Standard does not impose one particular behaviour, hence it is left `undefined''.
quote:
Original post by fizban75
Sabre, why can''t you just discuss topics in a grown up manner, rather than attacking people?

I''m not attacking you. A lot of people on these forums - probably the majority - do not know what `undefined behaviour'' means. It is very common to see someone take the results of their (usually MS) compiler as being the definitive interpretation of how C++ works, while not realising they are actually witnessing just one valid interpretation of undefined behaviour. Your earlier response made me believe that was what you had done.
quote:

If you''d like to point out my errors in judgement and interpretation, so be it. I welcome it. But you don''t have to put down others in the process.

A put down would be something like `you idiot - you don''t even know what undefined behaviour is!''
quote:

I don''t believe that the code:

int i;
i++;

necessitates an lvalue-to-rvalue-conversion, but if you think otherwise, I''d like to hear your thoughts.

What I''m telling you is the semantics are those of an lvalue-to-rvalue conversion. What goes on under-the-hood is irrelevant to the semantics of the C++ Standard, and the question of whether the C++ Standard defines the results of the operation - it doesn''t.

Share this post


Link to post
Share on other sites