The m_mtime.Format method returns a time formatted according to the local timezone, so it may well be one hour out. You should use one of the alternative methods (see CTime Class[^]) to get the absolute time.
This can occur when files are stored on FAT file systems. NTFS stores all dates in UTC while FAT uses local times. The local time from FAT file systems is converted when getting the time. But this will return wrong values when the time stamp has been written by a system that uses a different time zone than the one used to read the time stamp.
Because you are still using the C library function sprintf for the file name you might use it also for formatting the output. I still prefer this because it is often simpler (e.g. for date and times with leading zeroes).
Actually this is only a part of the code. I have int variables declared and those are also displayed in hex in the logfile.
will it have something to do with the settings while I build the same in Visual C++?
I have a for loop parallelized with openMP. Inside I want to catch possible exceptions. My idea is that the caught exception should be a private variable, as it is possible that several exception occur parallel. But I cannot express this.
#pragma omp parallel for default(none)
for ( int i = 0; i <10; ++ i )
// do something ...
catch ( const std::exception& e )
// handle exception ...
This yields to compiler error:
error C3052: 'e' : variable doesn't appear in a data-sharing clause under a default(none) clause
But I cannot mark the exception variable as private, as I is not known at that scope.
I can bypass the compiler error by changing the default sharing behaviour to shared, but I think this could lead to a runtime error, if two exceptions occur at the same time.
I've got an application which has two dialogs, I use a deque and Direct2D in one dialog within a thread. Now, if I close the application via handling WM_CLOSE I have no problem but when I try and close it by clicking on 'Close Window' in the task bar or using Alt F4 I get a breakpoint triggered on
if (!HeapFree(select_heap(block), 0, block))
I know it's a long shot since I have given so little detail - but seeing as the difference seems to be in the way I close the app down I was hoping there might be a quick and easy fix for this.
*Update since I posted in this it the next door forum, this morning, by mistake: I still get the same error if the thread (and hence the direct2d drawing) isn't running. Perhaps it is something to do with the way I set up the dialogs.