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.
I don't know, to be honest. The problem was occurring when I AltF4ed or clicked on Close Window but not when I clicked on my 'Exit' button. However, it looks like it was a corrupt memory problem I had with a member variable I'd assigned to the heap and was using to pass data between threads.
I've changed the communication to the following:
In the sending thread:
ControlDlg * pParent = (ControlDlg *) this->GetParent();
ColourAlphaEnvelope * s = new ColourAlphaEnvelope;
*s = m_ColourEnvelope;
I bet there are dozens of better ways of doing this (not least since a quick Google reveals that auto_ptr is depracated) but I haven't had a crash and the compiler isn't telling me there is a memory leak.
i am developing client program using WSAAsyncselect() in Winsock2.
i have few queries regarding FD_WRITE.
i understood that when client is connected to server. There will be FD_WRITE event posted stating that we can send the data to server. However, i want to send data to server based on some other events that the application is interested in. i am not quite sure how the FD_WRITE event will be fired when i want send data to server.
here is the pseudo.
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
// collect the data. we need to send collected data to sever (right now data is stored in a list). break;
// how to fire this event when application wants to send data ?case FD_WRITE:
Your application will receive an FD_WRITE event shortly after a connection is made. If your "write" operation receives a WSAEWOULDBLOCK result, your application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
Last Visit: 31-Dec-99 18:00 Last Update: 10-Apr-21 2:15