|
I once saw a program that allocated a huge array on startup. When a certain out of memory condition occurred, it freed the array, then performed a shutdown (hoping that the newly available memory would suffice).
I was quite frightened.
Failure is not an option - it's built right in.
|
|
|
|
|
I can just imagine that guy sitting there thinking, "Out of memory... PROBLEM SOLVED!!!111!11one"
|
|
|
|
|
|
catch(OutOfMemoryException ex) {
Ram r = new Ram(RamDualChannelMode.Enabled, 512, 512);
r.Install(RamInstallMode.HotPlug);
}
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe - but not a personality. - Charlie Brooker
My Blog - My Photos - ScrewTurn Wiki
|
|
|
|
|
I think the "new Ram()" call will fail, hence installation would be impossible...
How unfortunate!
|
|
|
|
|
Wow, run out of memory and just keep going as if nothing happened
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
Regards,
Satips.
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Walk beside me, and just be my friend. - Albert Camus
|
|
|
|
|
Found in C++ code of one of my colleagues several years ago:
if (x == 0)
{
y = 0;
}
else
{
y = x;
}
Asad
|
|
|
|
|
I would wonder whether or not it was originally something like:
if (x == FALSE)
{
y = 0;
}
else
{
y = x;
}
(With FALSE being 0 of course.)
|
|
|
|
|
Something similar:
if (x == false)
{
return false;
}
else
{
return true;
}
Jeff Clark
Systems Architect
JP Clark, INC.
Columbus, Ohio
|
|
|
|
|
Your example is from someone not knowing (or being reluctant to use) boolean logic:
return (x != false); would have been the same.
Failure is not an option - it's built right in.
|
|
|
|
|
Or just:
return x;
Jeff Clark
Systems Architect
JP Clark, INC.
Columbus, Ohio
|
|
|
|
|
Sure.
That would convert X's type (maybe BOOL?) implicitly to bool, whereas the operator!= I used does this explicitly.
It probably doesn't matter.
Failure is not an option - it's built right in.
|
|
|
|
|
PIEBALDconsult wrote: (With FALSE being 0 of course.)
No longer. C# is getting stricter. You have to explicitly do a type cast to escape the compiler wrath and whip.
|
|
|
|
|
Does it make more sense if x is of type signed int and y of type unsigned int ?
|
|
|
|
|
No...
---
single minded; short sighted; long gone;
|
|
|
|
|
|
Wasn't thinking, and had to wait for a window to dispose properly before redisplaying it (long story)
I was about to code this when my first cup of coffee hit me:
public void redisplay ()
{
try
{
}
catch (Exception e)
{
Thread.Sleep (100);
redisplay();
}
}
|
|
|
|
|
Great coding
Regards,
Sylvester G
|
|
|
|
|
To be honest, I find the general catch more disturbing than the recursion.
|
|
|
|
|
Slightly less bad than having an empty catch, imo
|
|
|
|
|
Regards,
Satips.
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Walk beside me, and just be my friend. - Albert Camus
|
|
|
|
|
One of my early coding activities was to customize the CFileDialog. One of the requirements was that the user should not be able to navigate to any other folder...so this is what I came up with:
<br />
if(pNmhdr->code == CDN_FOLDERCHANGE )<br />
{<br />
char szChFol[_MAX_PATH];<br />
CommDlg_OpenSave_GetFolderPath(GetParent(m_hDlg),szChFol,FILEPATH_LENGTH);<br />
<br />
CString theDir = lpstrInitialDir;<br />
<br />
if(StrCmpI(initDir, szChFol))<br />
{<br />
::SetFocus( GetDlgItem(GetParent(m_hDlg),0x47c));<br />
::SetWindowText( GetDlgItem(GetParent(m_hDlg),0x47C), theDir );<br />
::keybd_event( VK_RETURN, 0x45, KEYEVENTF_EXTENDEDKEY, 0 ); <br />
}<br />
}<br />
as if it wasn't a bad enough workaround already, I'm achieving it by setting text in the edit field and sending a keyboard event to it...;P
|
|
|
|
|
;P
Regards,
Sylvester G
sylvester_g_m@yahoo.com
|
|
|
|
|