I wrote my own simple XML parser a while back, and today I was playing around with writing a program that used the parser to take the data from an XML file and make it into a tree so that my programs could easily access the data. The parser just needs to be subclassed so that it can do things. I've already tested the parser out, and it works fine. However, my TreeParser subclass does not, so I took Visual C++ 2005 Express into debug mode to try and analyze the problem. For some reason, however, when the debugger gets into the Parse() function, it does not register the XML file as being opened. The whole thing is basically a while (file.good()) loop (file is an ifstream), and the debugger just skips past the loop as it evaluates good() as false. The weird thing is, though, that when running the program normally and inserting a statement inside the loop that prints a phrase to a log file, the log file is updated as expected. Thus, it would appear that when running the program normally, good() evaluates to true; when using the debugger, good() evaluates to false under the same conditions. Is there something about the debugger that makes it not handle ifstreams well or something? What could this possibly be?

Are you compiling and running in debug mode? Otherwise there are no debug symbols and the debugger is only making a best guess as to where the instruction pointer is with respect to the typed code.

-me

Yesterday, I had a chunk of code like thus:

I was tracing, and watched the debugger step into the catch, execute the return (but didn't actually return), step out, and keep going...O_o

Quote:I believe Visual C++ uses different working directories when in debug mode, you're file may simply not exist in the relevant directory.

If it is a debug build, wouldn't the directories coincide?

Quote:Original post by _Sigma
I was tracing, and watched the debugger step into the catch, execute the return (but didn't actually return), step out, and keep going...O_o

You can always jump to assembly in those situations to figure out what's actually going on. I've never seen this behavior, however, in a Debug build (i.e. all the symbol generation goodness is turned on, and all the code optimization is turned off).

Sometimes you get freaky stepping with optimization turned on because when optimizing the compiler may take common code out of smaller scopes and pop it up a level of scope or 2. i.e. you'll see some code in the else block executed when it's the then block that's actually executing.

-me

Quote:Original post by Palidine
Are you compiling and running in debug mode? Otherwise there are no debug symbols and the debugger is only making a best guess as to where the instruction pointer is with respect to the typed code.

Indeed, I'm running the Debug build of my program at all times... I don't even think I compiled a Release build yet. The XML file is in the same directory and does work fine, as I tested it with my original parser that simply prints the data to the screen. Again, though, when stepping through that working parser in debug mode, it skips that while loops entirely, resulting in nothing.

Someone mentioned turning off optimization. How do I do that? Also, if the actual debug process (i.e. stepping through the code) uses a different working directory than the Debug build's .exe, where is this directory given? Given the sort of error that's occuring, it does indeed seem as if it just can't find the file when actually stepping through.

I had a weird problem with good() once.

It would work on some files, but fail on others. Same format, different contents. Renaming, moving, testing, commenting, debugging - all zilch.

Then I restarted the computer, and it's worked.

I never found out what the problem was, but good() simply failed due to internal buffer overrun (or EOF-like condition). What's most puzzling, is that it happened based on contents of the file, yet file was never even read (it failed on first call to good(), or any other attempt to read the file).

To this day I don't know what happened.

Okay, I ran another test, and it seems that when stepping through with the debugger, file.fail() will return true, whereas running the .exe does not. However, the only docs I can find simply say that this means there was an internal logic error with ifstream. What does that mean? Why is this breaking? Should I just use the C method of reading in files instead?