[Dev-C++] Correction to "Bug report: problems with gdb & <string>'s getline"

[Richard H. <rf...@ya...>]

It now appears that the problem discussed in the message "Bug report:
problems with gdb & <string>'s getline" I sent yesterday (to
min...@li... ) is not a problem with gdb or
<string>'s getline.  

But rather the problem appears to be with the seemingly arbitrary,
capricious way that Dev-C++ switches the working directory from my
normal project directory to C:\Dev-Cpp when the debugger is invoked.  I
suspected that this might be happening when I reflected on earlier
experience with mpatrol which I used when I thought the problem might
be due to a memory bug (because the errors only occurred when I invoked
the debugger in Dev-C++).  In that earlier experience I found that
mpatrol.log was written to my normal project directory when I executed
the application without invoking the debugger.  But when I invoked the
debugger for the project in Dev-C++, I found that mpatrol.log was
written to C:\Dev-Cpp, where, incidentally the project's .dev file
(which presumably contains all the settings for the project) is stored.
 Incidentally, the problem does not arise when I invoke gdb and the
application together in a cygwin-bash command-processing window.  (I
verified with 'which' and 'where' commands that the gdb in
C:\Dev-Cpp\bin is the one that is used and in fact the only gdb that is
visible.)

I verified that Dev-C++'s working directory is C:\Dev-Cpp (when the
debugger is invoked) by copying "getline_input.txt" to C:\Dev-Cpp and
testing the operation of Dev-C++ with the debugger and the test
application both before and after I copied the file.  The Dev-C++ setup
works as expected after copying the file.

It would be nice if there were some way of setting the working
directory in the Dev-C++'s project's dialog boxes and perhaps even
having the default directory for the .dev project file be independent
(after initial project setup) of the default directory for other files
to be opened with "Alt-F ....".

Also, it would be nice if the "Send command to GDB" input control in
the "Debug > Output" tab at the bottom of the screen were functional. 
If that control were operable, theoretically at least, one could send a
"cd ...." command to gdb to set the working directory, although it
would be a bit of a nuisance to have to do this every time the debugger
is started.

The foregoing problem of switched directories never arose in earlier
development because, in normal execution, the attempt to open the
relevant file only occurred if the relevant file existed the current
working directory and the Windows Explorer context window were opened
to select the application for that file, and, furthermore, other IDEs I
used never made such a capricious switch of the working directory as
Dev-C++ does.

But to protect myself from Dev-C++'s capriciousness I replaced the
"is.clear();" statement (in the test example), which really wasn't
needed anyway, with:
  if(!is.good()){
    cerr << "File '" << filename << "' not found." << endl;
    system("PAUSE");
    return EXIT_FAILURE;
  }

And in the original application, where I first discovered this problem,
I replaced the "is.clear();" statement with:
  if(!is.good())
    throw e_heading_error((string)"File '" + filename + "' not
found.");

Finally, it would be nice if the debugger in Dev-C++ could be made to
stop skipping display-updates of steps executed.  The display-update
skipping tends to be rather bedeviling at times.

Richard Haney

P.S.:

In reply to my 

>   ifstream is(filename);
[...]
>   string linebuf;
>   bool sentry_state;
[...]
>   while(sentry_state = (bool)getline(is, linebuf)){

--- Greg Chicares <chi...@co...> wrote:

<quote>
I'm not really sure what this does. Try rewriting it in a
more conventional way; does the problem remain?

Consider:
  while(getline(is, linebuf))
IIRC, that works because of an implicit conversion via
std::basic_ios::operator!() that just calls fail(). [...]
<endquote>

Actually there now seems to be a definition of operator bool() in
template class basic_istream (defined in header <istream>), and istream
is simply defined in header <iosfwd> by "typedef basic_istream<char>
istream;"; so the (bool) cast above was to be sure I was getting the
sentry state and not depending on some indirect, unknown-to-me
conversion operation.  But I suppose the bool() operator would be used
even in implicit conversion because that seems to be the most direct
conversion possible.

Thanks for the suggestions as to hints for useful debugging techniques.
 Even though the general source of the problem seems now to be
resolved, these suggestions should prove useful in other contexts.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com