Jump to content

  • Log In with Google      Sign In   
  • Create Account

Error Log Help


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 02:08 PM

Hello,

I am learning SDL and i thought it would be helpful to make an Debug log to tell me if something is working or not. I am doing the project as a stand alone just to see if it works and then implement it in my SDL projects. So i have played a round with it a little but i cannot get the program to work. I am trying to make a class that handles all the debug stuff for me using the fstream to make a file telling me what happened. I cannot seem to get this to work, can anyone give me some hints? anything would be much appreciated.

Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8947

Like
0Likes
Like

Posted 21 October 2012 - 02:18 PM

Let me just grab my crystal ball... seriously, if you want help on your code, you might want to post said code, otherwise there's not much to go on. We're not psychic Posted Image

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 02:58 PM

Sorry i thought i linked the project.
Main.cpp
[source lang="cpp"]#include "stdafx.h"#include "DebugLog.h"int main (){DebugLog debug("DebugLog.txt");debug.~debug();return 0;}[/source]
DebugLog.h
[source lang="cpp"]#include "stdafx.h"#include <fstream>#include <iostream>#include <string>using namespace std;class DebugLog {public:DebugLog();~DebugLog();string writeTo(string text);private:string m_Text;string m_Filename;};[/source]
DebugLog.cpp
[source lang="cpp"]#include "stdafx.h"#include "DebugLog.h"DebugLog::DebugLog(){ofstream debugLog("DebugLog.txt");m_Text = "-----Debug Log Starts Now-----\n\n";debugLog << m_Text;}DebugLog::~DebugLog(){m_Text = "-----End of DebugLog-----";debugLog << m_Text;debugLog.close();}string DebugLog::writeTo(string text){m_Text = text;debugLog << text;return;}[/source]

#4 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 03:00 PM

I dont know whats wrong the code isnt right and the site wont let me reply properly.

#5 Bacterius   Crossbones+   -  Reputation: 8947

Like
0Likes
Like

Posted 21 October 2012 - 03:02 PM

Try pastebin.com, the code tags aren't working too well at the moment :(

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#6 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 03:10 PM

DebugLog.h:
#include "stdafx.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;

class DebugLog {
public:
DebugLog();
~DebugLog();
string writeTo(string text);
private:
string m_Text;
string m_Filename;
};
Debug.cpp:
#include "stdafx.h"
#include "DebugLog.h"
DebugLog::DebugLog(){
ofstream debugLog("DebugLog.txt");
m_Text = "-----Debug Log Starts Now-----\n\n";
debugLog << m_Text;
}
DebugLog::~DebugLog(){
m_Text = "-----End of DebugLog-----";
debugLog << m_Text;
debugLog.close();
}
string DebugLog::writeTo(string text){
m_Text = text;
debugLog << text;
return;
}
and Main.cpp
{
DebugLog debug("DebugLog.txt");
debug.writeTo("Line 1\n");
debug.~debug();
return 0;

I have an idea about whats going on but not a way to fix it.

#7 Bacterius   Crossbones+   -  Reputation: 8947

Like
0Likes
Like

Posted 21 October 2012 - 03:17 PM

First, don't call destructors like that. Use delete debug instead - and if the class is allocated on the stack instead - like it is here - just let it die when it goes out of scope, its destructor will be called automatically.

Secondly, does this even compile? debugLog is not defined in the destructor or in writeTo(). Basically, you allocate your iostream in the constructor, which is on the stack - as soon as it goes out of scope (i.e. when the constructor returns) the iostream is closed and lost. This iostream exists only in the constructor. If you want to keep a persistent iostream throughout your debug log's lifetime, you want it to exist as a private field in your class. Then you can use it anywhere, and your writeTo() will actually work. Does it make sense?

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#8 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 03:30 PM

If im understanding this right, your saying the ofstream debugLog("DebugLog.txt"); should be in my private: part of the class. When i do this i get an error saying that the "DebugLog.txt" needs an identifier before it. And Im not understanding what your saying about the destructor.

#9 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 03:32 PM

And int the main function it says DebugLog debug("DebugLog.txt"), that isnt supposed to be there sorry i forgot to delete it.

#10 Bacterius   Crossbones+   -  Reputation: 8947

Like
1Likes
Like

Posted 21 October 2012 - 03:52 PM

[source lang="cpp"]class DebugLog {public:DebugLog();~DebugLog();string writeTo(string text);private:string m_Text;string m_Filename;ofstream m_debugLog;};DebugLog::DebugLog(){ m_debugLog.open("DebugLog.txt"); // m_debuglog now belongs to the class, not just the constructor // so it can be accessed in writeTo() as well}[/source]

This means the debugLog object is now attached to your class instead of a specific method, so every method in the class has now access to it. The constructor takes care of creating the stream. Does it make more sense now?

Never mind the destructor stuff for now - you need to understand the concept of class fields before.

Edited by Bacterius, 21 October 2012 - 03:55 PM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#11 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 04:05 PM

Yes it makes sense now, thanks. But when i compiles it a message poped up saying Debug Assertion failed, what does this mean?

#12 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 04:11 PM

Nevermind, i fixed it, but thank you for the help.

#13 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 04:15 PM

Sorry, one more thing, When i compile it i get a message that says

:Unhandled exception at 0x7784ef10 in DebugLog.exe: 0xC0000005: Access violation reading location 0xfeeefef6.

#14 Bacterius   Crossbones+   -  Reputation: 8947

Like
0Likes
Like

Posted 21 October 2012 - 04:19 PM

Whole code, please. Works fine here. You're trying to access 0xfeeefeee, which is a bit pattern written by the Microsoft compiler to indicate memory that has been freed, So either you're not calling the constructor, either you're trying to use the DebugLog after you've freed it.

And int the main function it says DebugLog debug("DebugLog.txt"), that isnt supposed to be there sorry i forgot to delete it.

What did you mean by that?

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#15 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 04:25 PM

In the code i posted above it said in the main function debugLog debug("DebugLog.txt"). I sending the "DebugLog.txt" to the compiler so it name the file, but i changed it to name it in the constructor itself because i wasn't planning on changing the name. And what do you mean by using the Constructor after i freed it and why would it work for you and not for me?

#16 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 04:28 PM

constructor not compiler, and im sorry im posting so much but it wont let me edit my posts

#17 Bacterius   Crossbones+   -  Reputation: 8947

Like
0Likes
Like

Posted 21 October 2012 - 04:38 PM

Sanity check: does this work for you?

[source lang="cpp"]#include < iostream >#include < fstream >using namespace std;class DebugLog {public:DebugLog();void writeTo(string text);~DebugLog();private:ofstream m_debugLog;};DebugLog::DebugLog(){ m_debugLog.open("DebugLog.txt");}DebugLog::~DebugLog(){ cout < < "Closing debug log." < < endl; m_debugLog.close();}void DebugLog::writeTo(string text){ m_debugLog < < text;}int main(){ DebugLog log; log.writeTo("hello world"); // log is about to fall out of scope - destructor should be called return 0;}[/source]

Remove all the extra spaces I had to insert since the source tags are broken. I think we're just having a communication breakdown here.

Edited by Bacterius, 21 October 2012 - 04:39 PM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#18 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 05:14 PM

My code does the same thing yours does, however mine has different names, and when i deleted the Destructor i didnt get the message i got before.

#19 Bacterius   Crossbones+   -  Reputation: 8947

Like
0Likes
Like

Posted 21 October 2012 - 05:19 PM

Yes, you must essentially never call a destructor using the tilde method. If you need to delete it, use the "delete" keyword, and that's only for pointers (e.g. when going DebugLog* log = new DebugLog(), but that's for later). In your case, the destructor will be automatically called (since once you go out of main, your DebugLog is lost and can never be used again, so C++ chooses to destroy it there).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#20 Crusable   Members   -  Reputation: 594

Like
0Likes
Like

Posted 21 October 2012 - 05:29 PM

Thanks for your help




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS