Re: two coding questions
-
Hi all, I have a couple of quick questions that I really need an answer to. 1.) I have the following code: try { //reads in info from file } catch(ifstream::failure) { //deals with error } How do I MANUALLY throw an exception so it is caught by this code (I don't want to wait for the failbit to be set). 2.) Why does my DirecDraw primary surface back buffer throw up multi-coloured junk when I flip to it using a high resolution and 32 bit display? If I write to this "junk" on the surface, exit the app, delete the code that writes to the surface and then restart the app, the junk is displayed as it was before, even though I haven't written to it (seems like it is accessing same area of memory for back buffer???). The initial surface is fine (plain black) and can be written to and flipped to fine, but the back buffer can't. I don't get any problems using 16 bit display at any res. The code I used is straight out of the DirectDraw SDK docs. I'm just wondering if anyone had the same problem and how they resolved it? Obviously I'd appreciate a full answer to the questions, but any ideas or links to web pages that may answer them would be just as brilliant. Alan. "When I left you I was but the learner, now I am the master" - Darth Vader
-
Hi all, I have a couple of quick questions that I really need an answer to. 1.) I have the following code: try { //reads in info from file } catch(ifstream::failure) { //deals with error } How do I MANUALLY throw an exception so it is caught by this code (I don't want to wait for the failbit to be set). 2.) Why does my DirecDraw primary surface back buffer throw up multi-coloured junk when I flip to it using a high resolution and 32 bit display? If I write to this "junk" on the surface, exit the app, delete the code that writes to the surface and then restart the app, the junk is displayed as it was before, even though I haven't written to it (seems like it is accessing same area of memory for back buffer???). The initial surface is fine (plain black) and can be written to and flipped to fine, but the back buffer can't. I don't get any problems using 16 bit display at any res. The code I used is straight out of the DirectDraw SDK docs. I'm just wondering if anyone had the same problem and how they resolved it? Obviously I'd appreciate a full answer to the questions, but any ideas or links to web pages that may answer them would be just as brilliant. Alan. "When I left you I was but the learner, now I am the master" - Darth Vader
-
hehe, but what parameter do I pass to throw? throw (ifstream::failure) doesn't work, throw (ifstream::failbit) neither and, obviously, neither does throw - where an unhandled exception occurs. Any other bright ideas clever cloggs :)? Alan. "When I left you I was but the learner, now I am the master" - Darth Vader
-
hehe, but what parameter do I pass to throw? throw (ifstream::failure) doesn't work, throw (ifstream::failbit) neither and, obviously, neither does throw - where an unhandled exception occurs. Any other bright ideas clever cloggs :)? Alan. "When I left you I was but the learner, now I am the master" - Darth Vader
throw (ifstream::failure) doesn't work That's expected. First you used a syntax that isn't anywhere close C++, then you tried to throw an exception of a class that needs an argument. You might try
throw ifstream::failure("foo");But I'd say you've got a design error if you want to throw an exception on behalf of someone else like this. Your code is then basically lying (even if it's you that catches that same execption). Step back a second and think: Would you want to maintain that code in two, five or ten years from now? If you're interested in failures, not just the ones that throw "ios_base<...>::failure", why not catch "exception" (as "const std::exception&" of course). Why does my DirecDraw primary surface back buffer throw up multi-coloured junk when I flip to it using a high resolution and 32 bit display? Because you haven't painted into the back-buffer! Check the return values of every call to DirectDraw.