|
I saw the following question as an interview question on one of the sites, Can anyone see if I answered correctly? Thanks
bool Item::SetInt( INT_STAT key, int val, UpdateType update )
{
m_Something->SetInt( key, val );
int i;
bool retval;
byte* buffer = new byte[ 256 ];
if ( update & No_UpdateType == No_UpdateType )
{
return false;
}
if ( update & Private_UpdateType == Private_UpdateType )
{
for ( i = 0; i < m_numEvents; ++i )
{
if ( m_eventFilter[i] == key )
{
retval = true;
}
else
{
retval = false;
}
}
if ( retval ) {
SendPrivateEvent( buffer, key, val );
}
}
if ( update & Public_UpdateType == Public_UpdateType )
{
for ( i = 0; i < m_numEvents; ++i )
{
if ( m_eventFilter[i] == key )
{
retval = true;
}
else
{
retval = false;
}
}
if ( retval )
{
SendPublicEvent( buffer, key, val );
}
}
delete buffer;
return retval;
}
My Answers:
|
|
|
|
|
With that indentation, it's a bit hard to read, but here are a few:
buffer will not be deallocated it the if statement after its assignment fires.
update & Private_UpdateType == Private_UpdateType is equivalent to
update & (Private_UpdateType == Private_UpdateType) which is probably not intended.
The for-loops does not add any value. There should probably be a break statement after retval = true; and retval = false; could be moved to before the loop.
...and to name relevant software principles: Code with bugs don't work as expected.
|
|
|
|
|
Heh, I wish I could keep my answers as concise as yours. You've beat me to it. 
|
|
|
|
|
That's quite a novel  Good effort!
|
|
|
|
|
Go, figure:
Apparently the intent of the function is to set a value which is bound to some key, but this functionality may have side-effects or may be varied depending on some flags which are passed with the last parameter.
The flags being handled are No_UpdateType, Private_UpdateType, and Public_UpdateType.
The function returns true or false, depending on whether or not certain tests, depending on these flags, are successful. Apparently the result should be true only if the key exists and the value could be successfully updated, but the implementation does not fully back up this assumption.
Problems and shortcomings:
The (member?) variable m_Something is being dereferenced without testing for 0. (Might be ascertained elsewhere, but the code doesn't indicate any of that) (style, possible error)
There is no (visible) test whether an element exist for the given key value before calling SetInt(). Although that code might be hidden in SetInt(), there should be an indication in case of failure, but apparently there is none. (style, possible error)
retval is not initialized, and not all execution paths assign a value to it. It may be undefined on return. (error)
The first if statement can lead to a premature return. Apart from the fact this is bad style, it will cause a memory leak, due to the fact that buffer will not be released. (style, memory leak)
Also, the flag No_UpdateType which this if statement tests for seems to hint at the possible meaning that no update should actually be performed, so the call to SetInt() right at the start of the function may have been premature. (possible error)
Moreover, the test is wrong: '==' has a higher precedence than '&', so the line
if ( update & No_UpdateType == No_UpdateType ) will be interpreted as
if ( update & (No_UpdateType == No_UpdateType) ) which in turn is equivalent to
if ( update ) . The test requires additional brackets like this:
if ( (update & No_UpdateType) == No_UpdateType ) (error)
The same error is repeated twice below. (error * 2)
The following two if blocks contain code that is partially identical. It would be a good idea to extract this code into a separate function, or at least to pull it out of the individual if blocks to prevent redundancy. (style)
The for loop in these blocks suffer from the following three problems:
1. retval is needlessly assigned once for every iteration (performance)
2. once an element equal to key is found, the loop could be abandoned (performance)
3. After this element has been found, retval is being overwritten with false again (error)
There is one more curiosity revealed in these loops: apparently there is some structure which is supposed to hold all key values, but at the same time, this key is being used to set a particular value within the object m_something. This hints at possibly redundant storage, or at least an inefficient way to store a mapping between some key and value. It would probably be a good idea to use a map or hash_map - this would also eliminate the need to implement your own key-searching and value-setting functions. (stlye, possible waste of resources)
The SendXY() functions use buffer before it is being initialized. (likely error * 2)
The two if blocks may both be executed, in which case the return value might be overwritten yet again. Not to mention that the same for loop would be executed twice. (likely error)
Wrong call to delete (error: should be delete []).
On a sidenote, if the size of the buffer should always be the same, it would be better to define it on the stack in stead of the heap! (style, performance)
Conclusion:
As indicated above, the implementation probably does not set the return value according to its intended meaning. I assume the functionality should be something like this:
bool Item::key_exists(int key) {
}
bool is_set(UpdateType update, UpdateType flag) {
return ( update & flag );
}
bool Item::SetInt() {
bool retval = key_exists(key);
if (!is_set(update, No_UpdateType)) {
retval = false;
}
if (retval) {
byte buffer[256];
m_something->SetInt(key, val);
if (is_set(update, Public_UpdateType)) {
SendPublic();
}
if (is_set(update, Private_UpdateType)) {
SendPrivate();
}
}
return retval;
}
|
|
|
|
|
|
Consider the very simple IDL code that specifies a base and derived interface in CORBA:
module test{
interface Quote{
attribute string symbol;
};
interface SpecialQuote:Quote{
attribute string specialSymbol;
};
interface QuoteSender{
void sendQuote(in Quote stock_quote);
}
};
(This assumes CORBA but should be similar for other middleware). I am interested in being able to:
1. create a derived class "SpecialQuote", fill in specialSymbol
2. upcast to the base class "Quote", fill in symbol
3. send over CORBA interface using "sendQuote"
4. on the receiving end, downcast to SpecialQuote to retrieve specialSymbol
I'm having a hard time performing this because the attributes essentially just translate to empty setters/getters in Java rather than their Primitive Data Types. Thus it requires both the client and server ends to re-implement the setters/getters.
So in short, is inheritance of interface **fields** possible across middleware without requiring a re-implementation in every language? If so in CORBA, any recommendations? If in another middleware, which one?
|
|
|
|
|
Hi!
I've developed a MFC application. It was running fine. Suddenl it stopped running. I didn't change any code. I could not run setup file and from IDE as
well. If I try to run in release mode:
'flash_mfc.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFCLOC_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_15fc9313\mfc90enu.dll',
Binary was not built with debug information.
is displayed in the output window.
If I run in debug mode, application crashes and breaks at
ASSERT(IsWindow(pTemp->m_hWnd));
in the file occcont.cpp.
CreateDlgControls failed during dialog init. Detected memory leaks!
CoCreateInstance of OLE control {D27CDB6E-AE6D-11CF-96B8-444553540000} failed.
Result code: 0x80040154
Is the control is properly registered?
is displayed in the output window. Why it has happened suddenly(without no change in code)? Is this due to ServicePack? I 'm developing using Visual
Studio 2008 under Windows XP. The same project output runs fine at target systems. Here's the debug CallStack:
> mfc90ud.dll!COleControlContainer::FillListSitesOrWnds(_AFX_OCC_DIALOG_INFO * pOccDlgInfo=0x0012f7dc) Line 926 + 0x23
bytes
mfc90ud.dll!COccManager::CreateDlgControls(CWnd * pWndParent=0x0012fabc, const wchar_t * lpszResourceName=0x00000088,
_AFX_OCC_DIALOG_INFO * pOccDlgInfo=0x0012f7dc) Line 413
mfc90ud.dll!CDialog::HandleInitDialog(unsigned int __formal=853834, unsigned int __formal=853834) Line 661 + 0x1f bytes
mfc90ud.dll!CWnd::OnWndMsg(unsigned int message=272, unsigned int wParam=853834, long lParam=0, long * pResult=0x0012f49c)
Line 2018 + 0x11 bytes
mfc90ud.dll!CWnd::WindowProc(unsigned int message=272, unsigned int wParam=853834, long lParam=0) Line 1755 + 0x20 bytes
mfc90ud.dll!AfxCallWndProc(CWnd * pWnd=0x0012fabc, HWND__ * hWnd=0x000d074a, unsigned int nMsg=272, unsigned int
wParam=853834, long lParam=0) Line 240 + 0x1c bytes
mfc90ud.dll!AfxWndProc(HWND__ * hWnd=0x000d074a, unsigned int nMsg=272, unsigned int wParam=853834, long lParam=0) Line
403
mfc90ud.dll!AfxWndProcBase(HWND__ * hWnd=0x000d074a, unsigned int nMsg=272, unsigned int wParam=853834, long lParam=0)
Line 441 + 0x15 bytes
user32.dll!7e418734()
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
user32.dll!7e418816()
user32.dll!7e42927b()
user32.dll!7e42651a()
user32.dll!7e42683e()
user32.dll!7e43f03a()
mfc90ud.dll!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate=0x0016d820, CWnd * pParentWnd=0x00000000,
HINSTANCE__ * hInst=0x00400000) Line 312 + 0x2a bytes
mfc90ud.dll!CDialog::DoModal() Line 576 + 0x20 bytes
flash_mfc.exe!Cflash_mfcApp::InitInstance() Line 194 + 0xb bytes
mfc90ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t *
lpCmdLine=0x00020846, int nCmdShow=1) Line 37 + 0xd bytes
flash_mfc.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t *
lpCmdLine=0x00020846, int nCmdShow=1) Line 34
flash_mfc.exe!__tmainCRTStartup() Line 578 + 0x35 bytes
flash_mfc.exe!wWinMainCRTStartup() Line 403
kernel32.dll!7c817077()
What to do to run the project at my system?
|
|
|
|
|
When a program suddenly stops working, it's often because of the last change you made. Go back to the previous version and see if that runs. If so, compare the current/previous versions to find the bug.
If the previous version doesn't run, either the bug is from a still-earlier version, or something has changed in your environment.
Sometimes the source files get out of sync. Do a Rebuild Solution and rerun.
The message "Binary was not built with debug information." suggests you tried to debug (F5) a release version.
|
|
|
|
|
There is no such thing as a program not running any more in spite of 'not having changed anything', unless there is a hardware problem that causes the problem. According to the call stack this happens during startup however, so I don't think this is caused by hardware failure.
Check what has changed since the last time it did run:
- have you switched to a new system?
- have you rebuild the program?
- have you switched to a new IDE?
- have you applied any patches?
- could the program have been changed by anyone else?
- have you moved the code or executable to another directory?
- have you changed the code, even if it just seems trivial and unrelated to the problem?
If the answer to any of these questions is yes, try to revert the change and see if it works.
|
|
|
|
|
Stefan_Lang wrote: - have you applied any patches?
For other questions my answer is 'no'.
I didn't understand what is "patches". I've created Mutex. But it was working fine with Mutex. Here's my Mutex code:
BOOL Cflash_mfcApp::InitInstance()
{
INITCOMMONCONTROLSEX InitCtrls;
InitCtrls.dwSize = sizeof(InitCtrls);
InitCtrls.dwICC = ICC_WIN95_CLASSES;
InitCommonControlsEx(&InitCtrls);
CWinApp::InitInstance();
AfxEnableControlContainer();
#ifdef _AFXDLL
Enable3dControls();
#else
Enable3dControlsStatic();
#endif
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
Default();
FileRead();
char CurrentPath[_MAX_PATH];
Gen ObjGen;
ObjGen.GetCurrentPath(CurrentPath);
ostringstream OCurrPath;
OCurrPath.str("");
OCurrPath << CurrentPath<<"\\";
CurrPath="";
CurrPath = OCurrPath.str();
if(NULL != ::CreateMutex(NULL, TRUE,_T("CSingleInstanceApp")))
{
long dwError = ::GetLastError();
if(dwError == ERROR_ALREADY_EXISTS)
{
EndDialog(NULL,IDOK);
return FALSE;
}
else
{
if(!ObjGen.OnCheckConnection())
{
CError ObjCError;
m_pMainWnd = &ObjCError;
INT_PTR nResponse = ObjCError.DoModal();
return 0;
}
ostringstream oexe;
oexe << "cmd /c del "<<glo_exe_name<<"_* /f/q/a";
WinExec((LPCSTR)oexe.str().c_str() , SW_HIDE);
Update ObjUpdate;
m_pMainWnd = &ObjUpdate;
INT_PTR nResponse = ObjUpdate.DoModal();
AfxGetApp()->m_pMainWnd = NULL;
TerminateThread(Retry::ThreadExec, 0);
TerminateThread(TransferringForm::ThreadExec, 0) ;
TerminateThread(TransferringForm::ThreadExec1, 0) ;
ostringstream os;
os << "cmd /c taskkill /F /IM \"" << glo_exe_name <<"\" /T";
string to=os.str();
WinExec((LPCSTR)to.c_str() , SW_HIDE);
}
}
return FALSE;
}
But my app was working fine with this code.
|
|
|
|
|
Erm, no, I was referring to updates to your IDE, to your version of .NET or to Windows.
The reason for this question is that a change to the MFC dll could be responsible. Not a very likely scenario, but it happens.
|
|
|
|
|
I installed vcredist_x86.exe. Is it possible to uninstall that? If not what are the dlls that nedd to be replaced? Where?
|
|
|
|
|
You may not need to uninstall it, and I'm not sure that would be advisable either.
But since vcredist_x86.exe installs the newest version of MFC, it's possible the lib has changed, and therefore you need to rebuild your application, using the new lib and headers.
Alternately you can force your application to use the old version of the MFC dll by copying that version into the same directory as your executable. Your IDE probably keeps its own copy. For instance on my PC I can find various versions of the MFC under C:\Program Files\Microsoft Visual Studio\VSS\netsetup.x86\VSS\win32
|
|
|
|
|
Please tell me what I am doing wrong because in CStatic I didn't see anything :
BOOL CMyPage::OnInitDialog()
{
CPropertyPage::OnInitDialog();
CBitmap bitmap;
bitmap.LoadBitmap(IDB_BITMAP1));
m_staticIcon.SetBitmap((HBITMAP)bitmap);
return TRUE;
}
Of course m_staticIcon have SS_BITMAP style.
Thank you.
modified on Monday, June 6, 2011 8:06 AM
|
|
|
|
|
My bet is that as the CBitmap is a local object it goes out of scope at the end of the function and its destructor cleans up its memory usage and deletes the bitmap you loaded.
Try making it a member variable instead.
If you vote me down, my score will only get lower
|
|
|
|
|
You are perfectly right ! Thank you very much ! Best wishes !!!
|
|
|
|
|
I don't know why can not modify style at runtime : at design time style of CStatic is Frame , and in OnInitDialog I try :
m_staticIcon.ModifyStyle(0,SS_BITMAP | SS_CENTERIMAGE);
m_staticIcon.SetBitmap(::LoadBitmap(AfxGetApp()->m_hInstance, MAKEINTRESOURCE(IDB_BITMAP1)));
but didn't working at all ( I seen nothing on dialog ) ... what I should to do modify style in SS_BITMAP ?
Thank you.
|
|
|
|
|
My bet is that as the CBitmap is a local object it goes out of scope at the end of the function and its destructor cleans up its memory usage and deletes the bitmap you loaded.
Try making it a member variable instead.
The above is an answer from another question, however I think it applies. Member varibles in the class, tend to be less volitile. If the varible is in your "CMyDoument" class, it is more prone to persistance.
The World as we think we know it Has a lot more to it than meets the eye.
A Mad Scientist who has seen it for himself....
|
|
|
|
|
Try also removing the old style (first parameter of ModifyStyle), however, not every style can be changed at runtime, i don't know which can and can't, you should google it up.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
I use the WSAAsyncSelect now, and then the server use the vector to save the client.
the server has a ListCtrl to show the online's client,and then FD_ACCEPT it will push_back into the vector.
and then FD_CLOSE it will earse from the vector.
but it often not receive FD_CLOSE when the client's power failure.
I found the setsockopt from google, but don't quite understand the Windows Socket TCP Keepalive.
how to use it ?
Thanks for your reply !
|
|
|
|
|
MSDN[^] states:
If a connection is dropped as the result of keep-alives the error code WSAENETRESET is returned to any calls in progress on the socket, and any subsequent calls will fail with WSAENOTCONN.
If keep-alive is enabled for a TCP socket with SO_KEEPALIVE, then the default TCP settings are used for the keep-alive timeout and interval unless these values have been changed by calling the WSAIoctl function with the SIO_KEEPALIVE_VALS option.
Also, here[^] it says:
For TCP, the default keep-alive timeout is 2 hours and the keep-alive interval is 1 second. The default number of keep-alive probes varies based on the version of Windows.
Also, this[^] states:
KeepAliveTime
Specifies how often TCP sends keep-alive transmissions. TCP sends keep-alive transmissions to verify that an idle connection is still active.
This entry is used when the remote system is responding to TCP...
and here[^]:
KeepAliveInterval
Specifies how often TCP repeats keep-alive transmissions when no response is received.
So this whole thing boils down -to me at least- to this:
1. If this is enabled you will receive WSAENETRESET or WSAENOTCONN if you try to read or write the socket in case the "other side" disappeared.
2. By default, the system "pings" the other side every 2 hours, if no answer is received it will start "pinging" it every second who-knows-how many times before giving up. 2 hours is a lot of time, you might want to shorten that.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Code-o-mat wrote: 2 hours is a lot of time, you might want to shorten that.
Dangerous: those timers are expected to be consistent on a very wide number of system, and -because of the way TCP works- there is no need to make it shorter.
The keep-alive is sent on a silent socket to let it be not-anymore silent. But the problem is ... why is it silent?
If there are data to let flow, TCP itself recover transmission error and - if that cannot be done - reports to the soket WSAENETRESET/WSAENOTCONN independently on every keep-alive feature.
If there are no data to let flow for long time, considering servers queue, routing tables, switches cam table, firewall caches, ARP table etc. assuming everything still works the same is risky. Better to close the socket, and reopen it again when furtherly needed, and use some "session layer command or data" (the application should define what the y should be) to track the state of the session or re-sync the client and the server.
In other words, the OP had better to implement a more robust application protocol that uses the underlying socket not just to transfer data, but also to exchange some status information about the existence and activity of the client and the server (this can be done more frequently) if he wants to promptly react to an unexpected event.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
That all might be true but he asked how keepalive works (and correct me if i am wrong in what i answered to that), not how he should design his client/server protocol. 
I agree that instead of relying on keepalive he should implement his own mechanism for detecting if the other side is gone because that would give him a much better control over the whole thing, but of course, that's just my oppinion. To detect if a long-silent connection is silent because the other side doesn't have anything to say OR because someone poured some coffee over the router would require -as far as i know- some kind of "pinging" and "timeouting", and keepalive does exactly that, so the aproach isn't fundamentally flawed.
For the "shortening of the 2 hours thing", as i understood you can set the timings for sockets individually, i meant that, not fiddlign with the system-wide settings.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Koma Wang wrote: how to use it ?
Simple - don't.
No one wants to know if a connection is alive. What they want to know is whether the business logic is still functioning. And the only way to do that is to implement something that actually tests the functionality. The more fully it tests it the better. But at a minimum you can assure that the server is at least still responding to a message enough to return a response.
A simple implementation is to send a do nothing request from the client at a configured interval if no other request has been sent in that period.
And do NOT rely on such functionality to get around error checking legitimate requests. A server can go down right in the middle of a legitimate request.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
