Archived

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

stupid dll's and ofstream

This topic is 5333 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

does the fstream class have any specific issues when used with a dll? here is some code that reproduces the error:
  
//

//:::::::::::::::::::::::::

//      TESTDLL.H

//:::::::::::::::::::::::::

//

#include <fstream.h>
#ifdef TESTDLL_EXPORTS
#define TESTDLL_API __declspec(dllexport)
#else
#define TESTDLL_API __declspec(dllimport)
#endif

// This class is exported from the TestDLL.dll

class Debugger
{
public:
	TESTDLL_API Debugger(void);
	TESTDLL_API ~Debugger(void);
	TESTDLL_API void AddError(char loc_error[], char error_message[], DWORD error_number);
	TESTDLL_API void AddError(char error_message[], DWORD error_number);
	TESTDLL_API void Add(char message[]);
	ofstream	debugfile;
};



//

//:::::::::::::::::::::::::

//     TESTDLL.CPP

//:::::::::::::::::::::::::

//

#define TESTDLL_EXPORTS
#include <fstream.h>
#include "testdll.h"
TESTDLL_API Debugger::Debugger()
{
	debugfile.open("test.txt");
};
TESTDLL_API Debugger::~Debugger()
{
	debugfile.close();
};
TESTDLL_API void Debugger::AddError( char loc_error[], char error_message[], DWORD error_number)
{
	debugfile << "### Error ###";
		debugfile << endl;
	debugfile << "Location: ";
		debugfile << loc_error;
		debugfile << endl;
	debugfile << "Description: ";
		debugfile << error_message ;
		debugfile << endl;
	debugfile << "Erro Number: " ;
		debugfile << error_number ;
		debugfile << endl;
	debugfile << endl;
};
TESTDLL_API void Debugger::AddError(char* error_message, DWORD error_number)
{
	debugfile << " ### Error ###\n";
	debugfile << "Description: " << error_message << endl;
	debugfile << "Erro Number: " << error_number << endl;
	debugfile << endl;
};
TESTDLL_API void Debugger::Add(char* message)
{
	debugfile << " ### Other ###\n" << message << endl;
	debugfile << endl;
};


/*
    Compile testdll.cpp as a DLL file.
*/



//

//:::::::::::::::::::::::::

//     TEST.CPP

//:::::::::::::::::::::::::

//  Compile this as an executeable file....

//  Include testdll.lib


#include <fstream.h>
int main()
{ 
     Debugger dbg;
     dbg.Add("TEST!");
};

  
And you get some bullshit error... I wrote this code on the fly so it may have some compile errors. I have it so that it compiles fine, but is part of a larger project so i did not include all of the code. If there are some compile errors, just fix them real quick... ================== My (soon-to-be) Cherished Cookie of Appreciation: -- MattB - for WinSock advice --

Share this post


Link to post
Share on other sites
You''re probably using the wrong version of the runtime library. I think you need to link with the multithreaded dll version (someone correct me if I''m off here, I''m no dll/multithreading expert). Usually choosing the library is done via a compiler switch, or if you''re using an IDE like Visual C++ it''s probably an option somewhere in the project settings. The options will be like:

single threaded
multi threaded dll
single threaded debug
multi threaded dll debug

Share this post


Link to post
Share on other sites
Use the standard #include <fstream> instead of the deprecated #include <fstream.h>.

You don''t need all those TESTDLL_API, you only need one at the top of the class:

  
class TESTDLL_API Debugger
{
public:
Debugger();
...
};


Check the runtime library you are using (as Dobbs said).

What _exactly_ are the error message you get?



Update GameDev.net system time campaign - success at last

Share this post


Link to post
Share on other sites
when using an fstream or stl vector/ect in a dll, you should still get a warning (4215 if im not mistaken).. but it should still compile fine. if im understanding you correctly, you''re getting a runtime error?

-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
quote:
Original post by eldee
you should still get a warning (4215 if im not mistaken

Compiler Warning (level 1) C4215 - nonstandard extension used : long float?



Update GameDev.net system time campaign - success at last

Share this post


Link to post
Share on other sites
as Dobbs said, the usual cause of weird runtime errors when you move things to Dlls is that your Dlls and project are not set to use the same runtime library ... under Visual C++, go to project settings/properties for both your Dll and you Application and check that "C++/CodeGenerattion/Runtime Library" for both the Dll and App are the same (each debug should match, and each release version too ... and if you are using something like the SDL or Xerces-C binary release then they MUST be Multithreaded Dll versions).

Share this post


Link to post
Share on other sites
quote:
Original post by dalleboy
[quote]Original post by eldee
you should still get a warning (4215 if im not mistaken

Compiler Warning (level 1) C4215 - nonstandard extension used : long float?



Update GameDev.net system time campaign - success at last

ah well, loooks like i was mistaken after all


-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
Well, as I said, it should compile perfectly fine with no errors at all (as mine does). That is not the problem. The problem is that while the program is running, any time I use a function imported from a DLL that has anything to do with disk IO, I get a runtime error. The error says that the actual .exe caused the error. That is a really big bullshit error that I'm getting, and I can't really do much about that. However, upon commenting out any lines that call Debugger::Error() or Debugger:Add(), at all runs just peachy. Are DLL's not allowed to access files?

I compile the =EXACT= same code that I posted here, and I get NO warnings at all.
I get similar runtime errors on Win98, WinME, and WinXP.

As for multithreaded/single-threaded DLL, my app is entirely single-threaded. Maybe it has something to do with how it is compiled. When first creating the project (the DLL and the Console 32-bit App) I choose the options to have NO code added whatsoever (just a Win32 Dynamic-Link Library and a Win32 Console Application -- both with "An Empty Project" selected).

The Error I Get:
=================
TEST caused an invalid page fault in
module KERNEL32.DLL at 017f:bff87ede.
Registers:
EAX=c00301a8 CS=017f EIP=bff87ede EFLGS=00010216
EBX=0065fdec SS=0187 ESP=0055fffc EBP=00560068
ECX=00560220 DS=0187 ESI=8177d16c FS=45ef
EDX=bff76855 ES=0187 EDI=00560248 GS=0000
Bytes at CS:EIP:
53 56 57 8b 30 83 7d 10 01 8b 4e 38 89 4d f8 75
Stack dump:

What MSVC++ Debug Tells Me:
===========================
Preloaded symbols may not match 'test\debug\test.exe'.
Loaded 'C:\WINDOWS\SYSTEM\KERNEL32.DLL', no matching symbolic information found.
Loaded 'test\debug\thedll.dll', no matching symbolic information found.
First-chance exception in test.exe (KERNEL32.DLL): 0xC0000005: Access Violation.
First-chance exception in test.exe: 0xC0000005: Access Violation.
First-chance exception in test.exe (KERNEL32.DLL): 0xC00000FD: Stack Overflow.
First-chance exception in test.exe: 0xC0000005: Access Violation.
The thread 0xFFF5C747 has exited with code -1 (0xFFFFFFFF).
The program 'test.exe' has exited with code -1 (0xFFFFFFFF).

Note: The Access Violation error at 0xC0000005 was repeated several hundred times [\b]. I cut it out down to once before and after the Stack Overflow error.

[edited by - zackriggle on May 8, 2003 2:31:53 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by zackriggle
Well, as I said, it should compile perfectly fine with no errors at all (as mine does). That is not the problem.

Have you read any of our posts? Dobbs post in perticular?



Update GameDev.net system time campaign - success at last

Share this post


Link to post
Share on other sites
zackriggle what''s with the obstinacy? The solution to your problem was given. I explained the problem and solution roughly, and Xai gave the specific way of fixing it in MSVC. What more do you want? You are right that it isn''t a compile time error per se, but it does require you to make changes before compiling to fix it.

Share this post


Link to post
Share on other sites