|
This c++ application has two static functions that are used everywhere (about 130+ calls for each function):
incCount()
and
decCount()
At the start of the program the Count = 0, the problem is that once the processing is complete the Count must == 0. The Count can go as high as it needs to, but by the time the application ends each incCount() call must be balanced with a decCount() call.
Currently, the Count == 1 by the time the program ends and I must find out where a decCount() isn't called.
What is the best way to find out which code module isn't balancing the Count properly ?
(this is a C++ 6 application)
|
|
|
|
|
You cannot do this with one variable.
This is usually done by creating many instances of a class.
The class will internally have functions to increment and decrement.
When the class is created you can generate some sort of cookie that is unique across instances.
This was we can log which instance in incrementing and decrementing.
|
|
|
|
|
my current idea is to define the following with #ifdef _DEBUG playing a huge role:
in the class:
#ifdef _DEBUG
static Uint32 incCount (char cModule);
static void decCount (char cModule);
#else
static Uint32 incCount ();
static void decCount ();
#endif
the class where these functions are defined also implements a linked list. For each incCount(char) the char is added to the linked list (if it doesn't yet exist in the list), and for each decCount(char) the char is removed from the linked list.
then for each time the functions are called in the code:
#ifdef _DEBUG
decCount(__FILE__);
#else
decCount();
#endif
At the end of the program I dump what's in the linked list and the __FILE__ that is dumped is where I need to focus on by setting breakpoints.
However, this will touch at least 40 files. Is this the best method or is there a better method ?
For example, it would be incredible if I had programmatic access to the call stack (in a debug build) so that I would only need to edit this one class and add the source file to the linked list that's next in the stack.
|
|
|
|
|
First of all, if you are using multiple threads (explicit ones, or implicit ones such as used by asynchronous events, callback routines, etc), and your counter increment/decrement isn't atomic, it may well be that the number of calls is correct and the value is incorrect.
Assuming you have verified that, you will need to differentiate your function calls; an easy way would be to give them one positive integer parameter, using the same value for matching pairs of incCount(id) and decCount(id).
Then you want to count the operations for different id values in separate accumulators. There are many ways to do so:
- use an array, ranging from 0 to maximum(id);
- if that is not doable, use a smaller array with P elements, and use id%P
(the modulo operator will map any value of id to a valid index for your array).
Special case: if only one decCount() call is missing, you might even try this:
int count=0;
int P=32;
void incCount(int id) {
count^=1<<(id%P);
}
void decCount(int id) {
count^=1<<(id%P);
}
which means each call is toggling one bit in a single counter (assuming P is 32 or less); in the end the bit number of the one non-zero bit gives you the id%P. And you could use additional runs with different P values to find the actual value of id!
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I see, your method uses each bit in P to track a different code module.
That's less work than implementing a linked list and I don't have to edit a load of compiler conditionals.
EDIT:
I counted 43 code modules that need to be ID'd
modified on Wednesday, May 19, 2010 5:29 PM
|
|
|
|
|
if you have a limited number of id values, you can count their calls individually.
if they are many, you fold them to a smaller value.
And you already expect only one mishap, you could take advantage of that.
But first of all, you should inspect the potential multi-threading issue; your observation could simply be wrong!
I would avoid introducing fancy things (such as your linked list idea), as things in there can also go wrong; especially with a list, you would find it either difficult or expensive to get it thread-safe. Whatever code you add, it would better be thread-safe!
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I went with your idea of passing in an ID.
The integer ID is used by the counting functions to track which module the call came from (keeps track with an array).
with this method I can track what modules inc's and dec's don't match up.
|
|
|
|
|
Hi,
If you're using static functions then the functions can only be called from one translation unit - the one that they're defined in. Funnily enough that's the one the balancing won't be happening in. From what you've said there's something a bit more going on - perhaps if you described what you were trying to count someone could give you a suggestion as to how to count it more accurately?
Cheers,
Ash
PS: For example if you're counting objects of a particular class you can use RAII to keep track of your count. If the count's unbalanced because you're not clearing up objects properly then a decent debug heap might be able to give you clue as to what sort of object is still alive when the program terminates. You might have to do something a bit gauche like look at the still allocated block and compare vtable pointers but it's possible.
|
|
|
|
|
Are there the same number of calls to each function in your source code.
Assuming each inc cas a corresponding dec, look for the code section without the missing dec.
If that cannot be done. I would suggest checking all the dec calss to make sure one cannot be bypassed by an early "return" within the function code.
Next I would place breakpoints at given points so you can check the count value at the inc and dec calls. This should allow you to narrow done the rea of code which is not inc/dec correctly.
Are you sure its not a threading issue? Is it multithreaded and how are the numbrs being increemnted/decremented? this is where InterlockedIncrement and InterlockedDecrement can be of help.
If you vote me down, my score will only get lower
|
|
|
|
|
Roger, thanks for your reply.
my initial problem statement is a little bit simplified... in actuality the two calls vary wildly in the project. For example, 110 inc's and 140 dec's.
However, with the aid of some flags and using an array to track which modules are making the calls I have been able to balance the code such that dec count == inc count by the time the executable is finished.
I am actually really pleased with the implementation. So much so that I will keep the code in place and let it trigger only when an environment variable is set so that I can debug this problem if it shows up again
|
|
|
|
|
I want to stop the program run after the message box display
int npoints=(tmax+1000)/sam_interval;
if (npoints>32768) {MessageBox("The sampling time interval is too small. Please select a larger sampling interval.");
}
With the above statement, after I close the message box, the program resumes the run. In fact, I want to stop the program after closing the message box.
Please give me help
Thanks
modified on Wednesday, May 19, 2010 1:16 PM
|
|
|
|
|
How about sending it a WM_CLOSE message?
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thanks.
I use
exit(-1); after the message box. it works.
if (npoints>32768) {MessageBox("The sampling time interval is too small. Please select a larger sampling interval.");
exit(-1);
}
|
|
|
|
|
mrby123 wrote: I use
exit(-1)...
To exit a Windows GUI application? 
Not a good choice.
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
mrby123 wrote: Please select a larger sampling interval.
That message does not make sense if your app is exiting anyway.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
When you program suddenly stop, you may want to inform the use what happen.
Otherwise, the use feels not good.
|
|
|
|
|
I agree, but then you should choose a more accurate message; maybe "next time you run this program, please enter ...".
Although I still think it is rather rude to stop a program just because the interactive user entered something you did not like; you should allow for another chance.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I agree with you, it is better to give user a chance to correct.
I wish to find an interactive message box to allow user to inter a correct value for the parameter.
Do anyone know how to program an interactive dialogue box?
Thanks again
|
|
|
|
|
Assuming you're using MFC...
If (IDYES == MessageBox(_T("Are you sure you want to quit"), _T("Confirm Exit"), MB_YESNO))
{
PostQuitMessage(0);
}
|
|
|
|
|
you may want to implement this pseudo-code:
string s="Please enter a number in the range [a,b]"
for(;;) {
int n=NumericInputBox.Show(s);
if (n==-1) Application.Exit();
if (n>=a && n<=b) break;
s="Sorry, "+n+" is not valid as it is not in the range [a,b]; please try again now (or enter -1 to quit)";
}
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Hi Thanks. I will try it. Another Key is to make sure the app can catch the new value entered in the dialogue box.
Thanks for any specific instructions.
|
|
|
|
|
Well, maybe you should just "return" from the current flow of execution and let the user enter a new interval instead of just closing the application!!
something like :
while (sample not good )
{
enter sampling.
compute value.
validate value.
}
M.
Watched code never compiles.
|
|
|
|
|
I am running MFC C++ application.
Your suggestion is good. I do not know which dialoge box should I use to do such interaction.
Thanks again
|
|
|
|
|
Hi,
As you're using an MFC app look up Dialog Data Exchange (DDX) and Dialog Data Validation (DDV). Between the pair of them you can specify allowed ranges for field in a dialog box and give the user a message if they enter something that's out of the range. Out of the box it's a bit clunky but works okay with a bit of tender loving care.
So if you've got an edit control with the sampling interval in milliseconds (IDC_SAMPLE_INTERVAL) and you want the user to be able to enter something between 10 and 1000ms, you overide DoDataExchange in your dialogue box class as something like:
void CSampleDlg::DoDataExchange( CDataExchange *pDX )
{
CDialog::DoDataExchange( pDX );
DDX_Text( pDX, IDC_SAMPLE_INTERVAL, sample_interval_ );
DDV_MinMaxInt( pDX, sample_interval_, 10, 1000 );
}
where sample_interval_ is the data member containing your er, sample interval.
If the entered interval isn't between 10 and 1000 MFC displays an message box and lets the user choose to abandon the edit or try again.
Cheers,
Ash
PS: Using exit() in a C++ program can be a bad idea one main reason - destructors aren't run for any objects. If those objects are managing a system global resource then that resource can leak. It can also mean that files aren't flushed and closed properly and may not have the contents you expect.
On the other hand exit() can be a quick way to bail out of a misbehaving program with a long shutdown time if that shutdown time is due to a large number of or slow destructors. This is generally regarded as being pretty vile by most C++ experts and only used as a desperate measure.
|
|
|
|
|
a nice program would check the range and ask for a proper value, before saving the value.
-> "Please enter a valid value or quit"
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
