istream::good() in a dll

  • Thread starter Thread starter Andreas Hildebrandt
  • Start date Start date
A

Andreas Hildebrandt

Hi all,

we are trying to port a fairly large c++ library to windows using
Visual Studio.net 2003, and are running into some unexpected problems
with the stream handling. Since our development is more or less
Unix-based, I am afraid I am quite a novice to all Windows - specific
stuff, so please excuse my naive terminology. :-)

In our library, we have a string handling class, which contains the
following piece of code:

inline
std::istream& String::getline(std::istream& s, char delimiter)
throw()
{
static char line_buffer[8192];
s.getline(line_buffer, 8191, delimiter);
set(line_buffer);

return s;
}

If I compile the library as a static .lib, and write a program using the
following code:

int main(int argc, char **argv)
{
std::ifstream f("bla", std::ios::in);
String line;

while (f.good())
{
line.getline(f);
std::cout << line << std::endl;
}

return 0;
}

everything works perfectly. But as soon as I compile the library as a dll,
f.good() does nothing. It always returns true, no matter where in the stream
I am. Leading, of course, to abnormal program termination since it reads one
line past the end. The same happens with f.eof(), f.fail(), or f.bad()

I have been told that strange things might happen if you compile the library
and the executable with different versions of the CRT, but as far as I can
see, both use the same: both compilations set a compiler swith /MD

Anyone got any idea what is happening here? And why it works when using a
static lib but not when using a dll?

Thanks a lot,

Andreas Hildebrandt
 
Andreas Hildebrandt said:
I am afraid I am quite a novice to all Windows - specific
stuff, so please excuse my naive terminology. :-)
Click to expand...

Roger that.
In our library, we have a string handling class, which contains the
following piece of code:
...
everything works perfectly. But as soon as I compile the library as a dll,
f.good() does nothing.
Click to expand...

What is probably happening is that the execuatble and the DLL are built
against different instances of the runtime. If you want to share runtime
"widgets" across a DLL boundary then the executable and DLL must be built
against the same "flavor" of the DLL BASED runtime. By "flavor" I mean that
you must use the same debug/nodebug and single/multithreaded version in
each.

Regards,
Will
 
William said:
Roger that.


What is probably happening is that the execuatble and the DLL are
built against different instances of the runtime. If you want to
share runtime "widgets" across a DLL boundary then the executable and
DLL must be built against the same "flavor" of the DLL BASED runtime.
By "flavor" I mean that you must use the same debug/nodebug and
single/multithreaded version in each.
Click to expand...

He's already building everything with /MD (he thinks). Must be something
else (unless he's not really building everything with /MD).

-cd
 
Carl Daniel said:
He's already building everything with /MD (he thinks). Must be something
else (unless he's not really building everything with /MD).
Click to expand...

My bad.

Andreas: as pennance for not reading your message all the way through <g>,
and if you have checked the settings and _are_ really building with the
proper options, then if you like you can send me a the source to the
function that you are trying to export. I'll try building the DLL and its
executable client here with VS.Net 2003.

Regards,
Will

P.S. You can delete the obvious attempt at obfuscation from my email address
but please don't post it here. I have all the offers for Viagra and Cialis I
could ever want. ;-)
 
Back
Top