Can't delete static singleton pointer (a deinitialization fiasco)
No I cant see anywhere that I'm freeing anything or doing anything bad. The rest of the code is all operator<< stuff. Working on piping stuff to the streams. Here is CloseIO():
.
inline void CloseIO(void) override
{
if (m_ofs.is_open())
m_ofs.close();
if (m_ifs.is_open())
m_ifs.close();
}
.
Not calling it at the end of main() still produces the error. I am currently scanning http://www.gamedev.net/blog/355/entry-2254834-oh-noes-my-code-is-teh-crash/ to see if it enlightens me towards improving my debugging skills. That book that the previous link explicitly alluded to, at the end, sounds worth getting. I was thinking that maybe boost::archive::textoarchive needed the std::ofstream somehow during its destruction but that theory is out as I stopped the closing of the streams before destruction. I think the boost docs say that it automatically closes the associated stream on exit. But don't qoute me on that.
Good morning...
Ok I've solved it fully and finally...!!!
I was sleeping and in my dream I dreamed that the shared pointer depended on the fstream(s). The static ofstream and ifstream were created after the shared pointers! I simply moved them to the top, et voila, no more access violation.
Thank you Jesus!
Good morning...
Ok I've solved it fully and finally...!!!
I was sleeping and in my dream I dreamed that the shared pointer depended on the fstream(s). The static ofstream and ifstream were created after the shared pointers! I simply moved them to the top, et voila, no more access violation.
Thank you Jesus!
If you can use C++11 in your project, Meyers's singleton is simple, elegant, and thread-safe.
Be careful with the thread-safety part.
Visual Studio 2012+ implements C++11 (well, partially, like many compilers) and thread-safe static initialization is NOT implemented: http://msdn.microsoft.com/en-us/library/s1sb61xd.aspx .
thread-safe static initialization is NOT implemented
So are 'boost::smart_pointers' the key? This guy says they are thread safe. (Qoute from boost docs contained)
Be careful with the thread-safety part.
Visual Studio 2012+ implements C++11 (well, partially, like many compilers) and thread-safe static initialization is NOT implemented: http://msdn.microsoft.com/en-us/library/s1sb61xd.aspx .
Great point, I didn't know that VS has yet to implement this. Also, you get an upvote for knowing and applying the "Know thy standard" rule.
Sometimes you might want to create a smaller log, an object specific to your component rather than being globally accessible, and attach a log listener to it.
Would creating a "log manager" for managing multiple log object instantiations convince you to make the log manager a singleton?
I was sleeping and in my dream I dreamed that the shared pointer depended on the fstream(s). The static ofstream and ifstream were created after the shared pointers! I simply moved them to the top, et voila, no more access violation.
Oh, of course! Your reset calls worked because they released the pointers before the implicit destructor calls.