|
Joaquín M López Muñoz:
Thank you. Your reply help me a lot.
marshal
|
|
|
|
|
I wonder do the real world programmer write "precondition"
and "postcondition" in the comment? Because, right now in
my programming class, the instructor requires us to use
it in the comment. For example:
// Precondition: n > 0
// Postcondition: The user has been asked to think of a number
// between 1 and n. The function asks a series
// questions, until the number is found.
void guess_game(int n)
{
int guess;
char answer;
assert(n >=1);
.
.
.
.
}
|
|
|
|
|
Preconditions are very useful, however separating the assertion from the comment explaining the test is a bad idea IMO. Put the comment right above the assertion, so that when the assert fails and the debugger drops you at that line, the comment is right there explaining it.
Also, "n > 0" is a useless comment. No duh. That comment does nothing to explain why n is being tested. Something more useful would be:
void guess_game ( int nChosenNumber )
{
assert(nChosenNumber >= 1);
}As for postconditions, I've never used them. Assertions placed after key blocks of code, as a sanity check that the result isn't something out of the expected range, is more useful, again IMHO. Such a sanity check placed at the end of a function could be seen as a postcondition, I guess.
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released
|
|
|
|
|
So you do use precondition, BUT you do not write "precondition"
explicitly like the one that in my example?
Well, what is the formal difinition of "assertion"? Is it
kind of precondition?
|
|
|
|
|
VW_Red_Jetta wrote:
Well, what is the formal difinition of "assertion"?
I'll provide you a comment from Steve McConnell:
The main difference between "if" tests and assertions is that assertions should test for conditions that you expect *never* to happen; "if" tests are for conditions that you plan to deal with. Assertions should not take the place of normal error-processing code. They should be used to flush out defects in your code. Put differently, an assertion should never fire unless there is a defect.
When I posed a similar question to Steve Maguire (my function had a signature of Foo( LPSTR )), his response was:
The question you should ask is this:
Is it legal for another programmer to call
Foo() with a null pointer?
or phrased differently:
If a programmer passed NULL to Foo(), would
that be a bug in the calling code?
If you decide that getting NULL is an illegal condition (based on how you designed Foo()) and indicates a bug in the calling function, then you should use ASSERT. If, on the otherhand, Foo()'s design makes getting a NULL pointer reasonable, and would not indicate a bug in the caller, then you should be using the "if".
You may want to use both the ASSERT and "if". You'd use both when getting a NULL would indicate a bug, and when you'd still want the code to behave intelligently even when it gets garbage. The typical scenario would be aircraft controller software, or radiation machine software. Bugs in either of these pieces of software could be deadly and so you'd keep the "if" just in case a bug makes it into the final code. Hopefully the ASSERT would alert you to the bug long before then.
Probably the best way to figure out whether to use an ASSERT or an "if" is to follow this guideline:
Completely finish the function as you intend
to ship it. Once you're convinced that you've
got the code as you plan to ship it, _only then_
do you add assertions (and debug code), _without_
changing what your ship code does.
(Remember, debug code is strictly _extra_ code.)
Using this guideline, you can see that if your ship code has to handle NULL pointers, then you have to use an "if" statement to handle the NULL pointer. If the ship code doesn't have to handle the NULL pointer, then you can ASSERT that getting one is illegal so that it alerts callers to their bugs.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Well thank you very much for the formal of assertion. So
do you explicitly write "precondition" and "postcondition"
in the comment?
|
|
|
|
|
VW_Red_Jetta wrote:
So
do you explicitly write "precondition" and "postcondition"
in the comment?
Neither.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hello, everyone!
I know nothing abuot mmap. And are there some tutorials or simple sample codes about mmap? I just want to learn the basic usage of mmap.
regards,
George
|
|
|
|
|
Hi all,
I am attempting to hook the keyboard to allow it to behave as a mouse device. The application works fine on 2K and XP but not on 98 or ME. If the controlling application Window is active all works fine but if it isn't things go pear shaped. This would indicate to me that I am not get a system hook rather a thread one, but that seems improbable given it works on other platforms and the hook code resides in a dll.
Any ideas?
Here is the code I use to hook the event:
/**
* Installs the hook.
*/
KEYHOOK_API bool InstallKeyboardHook()
{
if(g_hKeyboardHook == NULL) {
g_hKeyboardHook = SetWindowsHookEx(WH_KEYBOARD, KeyboardProc, g_hInstance, NULL);
}
// Fail if the hook fails to install
if(g_hKeyboardHook == NULL) {
return false;
}
return true;
}
/**
* Removes the hook
*/
KEYHOOK_API void RemoveKeyboardHook()
{
while(!UnhookWindowsHookEx(g_hKeyboardHook)) {
Sleep(100);
}
g_hKeyboardHook = NULL;
}
/**
* Called by the hook when there is a keyboard event.
*/
KEYHOOK_API LRESULT CALLBACK KeyboardProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if(nCode >= 0) {
// Check to see if the action belongs to the space key, if so we trap it
if(wParam == VK_SPACE) {
// Only perform an action if the space key is being released
if((::GetAsyncKeyState(VK_SPACE) & 0x80000000) != 0x80000000) {
// Determine the controller and perform the appropriate action
if(GetController() == SI_SCANNER) {
SetClicked();
}
else if(GetController() == SI_MOUSE) {
SetState((GetState() + 1) % NUM_STATES);
}
}
// Trap this message
return 1;
}
}
return CallNextHookEx(g_hKeyboardHook, nCode, wParam, lParam);
}
|
|
|
|
|
I have been trying for quite some time now to download the Platform SDK from the msdn website. The mickeysoft program that is supposed to handle the installation keeps crapping out with a "Server Error" message. I can't download the CAB files either because they are coming in corrupted. Is there another way to obtain the SDK?
Thank you,
Eric Sepich
|
|
|
|
|
|
Greetings,
I would like to write a generic CPhaseManagement object, but keep hitting a wall with it being tied to the specific app. The Phases would be something like: InitPhase, IntroPhase, MenuPhase, AppPhase, and ExitPhase with an enumerated type defined in a PhaseSettings.h file !
Each Phase of the App will have it's own specific Phase routines (StartPhase, ProcessPhase and ExitPhase). These of course will be App specific.
So I need to know how to make a pointer to a function so that the PhaseManager can call the relevant PhaseStart/exit etc.
Any pointers (haha) / comments appreciated.
If sex is a pain in the ass, then you are doing it wrong!
|
|
|
|
|
int Foo1( WPARAM, LPARAM )
{
}
int Foo2( WPARAM, LPARAM )
{
}
int (*pFunc)( WPARAM, LPARAM );
if (some_condition)
pFunc = Foo1;
else if (some_other_condition)
pFunc = Foo2;
(*pFunc)(parameter_list);
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
cast to pointer to Function hey !
Who would have thought!
(Obviously not me)
Much Appreciated
If sex is a pain in the ass, then you are doing it wrong!
|
|
|
|
|
Does this mean that I have to create a pointer to a <function with a fixed set of params> ?
As opposed to a pointer to a function with any set of params.
Obviously when I call it, I will have to pass the right param types, but do I have to declare the pointer to have those param types ?
Or am I flogging a dead camel ?
If sex is a pain in the ass, then you are doing it wrong!
|
|
|
|
|
hi,
does anyone know how to retirve information of a particular hardware device?
eg. USB devices(pc Cam)
thanks
|
|
|
|
|
You might look into GetDeviceCaps(), or the WMI functions.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
GetDeviceCaps() a CDC function to get hardware information 
|
|
|
|
|
Doesn't sound quite right, does it? Forget I mentioned it!
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I want to call some code after my dialog has been displayed on the screen. This means I cannot do it in OnInitDialog(). How can I do it?
Thank you.
|
|
|
|
|
More explanation: my dialog contains some data on startup. The user will then click the Update button and an icon is displayed on each line of data as each line is updated. I want the user to see this happen after the dialog appears but there is no message to process after the dialog is displayed. DoModal() just returns.
I think that I can create a modeless dialog instead but that is a lot of work compared to my modal one. Can I create my dialog modeless do my update and then convert to modal instead or must it remain modeless?
Is there undocumented feature which is a function that gets called after the dialog is displayed?
|
|
|
|
|
The most straightforward way is to simply post a user-defined message right before OnInitDialog() returns. This guarantees that the dialog box will be displayed and then the startup code will be executed.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thank you.
Can you tell me how I must do this?
|
|
|
|
|
static const UINT UDM_START_PROCESSING = ::RegisterWindowMessage(_T("UDM_START_PROCESSING"));
BEGIN_MESSAGE_MAP(CMyDialog, CDialog)
ON_REGISTERED_MESSAGE(UDM_START_PROCESSING, OnStartProcessing)
END_MESSAGE_MAP()
BOOL CMyDialog::OnInitDialog( void )
{
CDialog::OnInitDialog();
PostMessage(UDM_START_PROCESSING);
return TRUE;
}
LRESULT CMyDialog::OnStartProcessing( WPARAM, LPARAM )
{
return (0);
}
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
In your OnInitDialog(), just before you return you can show the window and it's descendants. Then you can call your Update button handler, as though the user had clicked it.
...
CDialog::OnInitDialog();
SendMessageToDescendants(WM_SHOWWINDOW, (WPARAM)TRUE);
SendMessageToDescendants(WM_ENABLE , (WPARAM)TRUE);
OnUpdate();
return TRUE;
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
"If you think education is expensive, try ignorance."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
