Have you made sure your not leaking memory?
If not you can use this:
//DEBUG CODE
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define DEBUG_NEW new(_CLIENT_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif
int main()
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
This will allow you to see any leaked memory when you close the program
Obliterated every single * pointers (i think) since they caused a bug earlier.
Don't avoid pointers in general, they are fine when they do not own memory. Avoid new and delete.
int a;
int* p = &a; // good
int* q = new int; // bad
Should I replace every array with vector, and can I know the reason why array is unsafe or something? Thanks.
std::vector when the size is dynamic, std::array otherwise.
Arrays are bad, because:
- they don't provide index/iterator checks in debug mode
- they don't have value semantics (you cannot copy, assign, pass to or return from functions)
- they are not very typesafe, since they can be implicitly converted to a pointer
- they don't have size(), begin() or end() member functions
std::array fixes all these problems without any disadvantages. In particular, std::array is not slower than C arrays (in release mode).
Nevermind
You should not avoid the rule of three, but follow it ;) What I meant is that it's rarely necessary to write a user-defined destructor, copy constructor and assignment operator, especially if you apply the RAII idiom. Letting the compiler generate these functions not only saves time, but it also prevents bugs like a forgotten member.
Thanks for the tips!
You're welcome, glad I could help :)
Minor nitpick: <string.h> is standard, as per D.5 and table 154.
Ah, it's inherited from the C standard. But I'd recommend to use <cstring> in C++ (if the C functions are needed at all); then the functions are also accessible via std namespace.
So you mean the rule of zero (http://flamingdangerzone.com/cxx11/2012/08/15/rule-of-zero.html)?
Very good article, thanks!
However, std::unique_ptr and std::shared_ptr are of limited utility when it comes to avoiding the three/five, simply because they don't maintain copy semantics of the surrounding object. In order to cope with these limitations, I have written aurora::CopiedPtr (http://www.bromeon.ch/libraries/aurora/v1.0/tutorial-smartptr.html), a smart pointer I frequently use in Thor. In short, it is able to deep-copy polymorphically:
aurora::CopiedPtr<Base> origin(new Derived);
aurora::CopiedPtr<Base> copy = origin; // invokes Derived copy constructor
Updated the repository, that should fix some of them (mainly return; exit(); and define constants)
I still suck at using const though. I can't figure out how to make them usable across multiple header files... They can generate errors if two consts over different files have the same name, but they don't work otherwise.
Oh, and
Arrays are bad, because:
- they don't provide index/iterator checks in debug mode
- they don't have value semantics (you cannot copy, assign, pass to or return from functions)
- they are not very typesafe, since they can be implicitly converted to a pointer
- they don't have size(), begin() or end() member functions
std::array fixes all these problems without any disadvantages. In particular, std::array is not slower than C arrays (in release mode).
Still working on it, thanks for the information!
Still wondering about the heap corruption thing though. It works fine with me with either builds, and Have you made sure your not leaking memory?
If not you can use this:
//DEBUG CODE
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define DEBUG_NEW new(_CLIENT_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif
int main()
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
This will allow you to see any leaked memory when you close the program
doesn't show anything, apparently.
I need to get another machine to test it out.