|
UnMangle_symbols returns a char. The line
*final = UnMangle_symbols(...);
assigns the character to whatever final is pointing to, but at that stage final has not been initialised therefore you are writing a character somewhere in memory (could be absolutely anywhere).
The print statement outputs a character string starting at where final points to, i.e. this unitialised memory. Hence garbage.
Try making UnMangle_symbols return a char* (but make sure that the string does not go out of scope (i.e. is not somewhere on the stack)), the assignment then becomes
final = UnMangle_symbols(...);
Graham
My signature is not black, just a very, very dark blue
|
|
|
|
|
I used to use Borland's IDE and they had a cool tool called an object browser (I think) which was analagous to an object-oriented pedigree. It is essentially an image of boxes representing classes and lines representing relationships (vis inheritance). I find it a much simpler way to visualize complex inheritance than the object browser included in MS's product. If there an add-in or this facility built in which I have just not discovered yet?
Thanks.
|
|
|
|
|
|
Take a look at DOxygen: http://www.stack.nl/~dimitri/doxygen
Here is an example of DOxygen graphical output:
http://xml.apache.org/xerces-c/apiDocs/inherits.html
|
|
|
|
|
Hi,
I have a big code base that has been developed for a while. Unfortunately, they did not use exceptions at all for floating point divde by zero. Fortunately, when I was using visual studio 6.0 I was able to get the debugger to jump in when such an exception occurs.
The problem is now we are migrating to visual studio 2003. There is an option to have the debugger jump in when a floating point divde by zero occurs (debug->execeptions or crtl+alt+e), but it does not seem to be working, atleast for a blank console application. Could this be because the application is a console application and not a win32 application? Or can we not rely on the debugger.
This is the simple program I used to test:
int main()
{
double x = 5.0;
double y = 0.0;
double z = x/y;
return 0;
}
What should occur is that the debugger should do something when it see x/y by jumping in. I have the option enabled: c000008e Floating-point division by zero and I set it to break into the debugger if the exception is not handled.
I know that we should be using try catches, but this is to test and algorithm and once again the code base is huge.
-- modified at 17:39 Friday 4th August, 2006
|
|
|
|
|
Ok I have solved the problem. With the following code snipet
#include <float.h>
#include <iostream>
int main( void )
{
_controlfp(0, _MCW_EM);
double x = 5.0;
double y = 0.0;
double z = x/y;
}
This will be caught by the debugger and an exception will be thrown. It seems that I had to unmask this option using _controlfp. I am not too familar with it but it seems to work 
-- modified at 18:42 Tuesday 8th August, 2006
|
|
|
|
|
I declared CMyApp like this:
CWinApp CMyApp;
How AfxGetApp() function locates the address of CMyApp?
|
|
|
|
|
AfxWin1.inl:
_AFXWIN_INLINE CWinApp* AFXAPI AfxGetApp()
{ return afxCurrentWinApp; }
AfxWin.h:
#define afxCurrentWinApp AfxGetModuleState()->m_pCurrentWinApp
AfxGetModuleState() returns a pointer to a MFC internal state structure.
AppCore.cpp:
CWinApp::CWinApp(LPCTSTR lpszAppName)
{
...
ASSERT(afxCurrentWinApp == NULL);
pModuleState->m_pCurrentWinApp = this;
ASSERT(AfxGetApp() == this);
...
}
So basicly the AfxGetApp() pointer is setup in the CWinApp constructor. If you really want to know the internals of MFC then thge best place to look is in the MFC source files. Using the visual studio debugger to step through the sources is the best way.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
When CMyApp is instantiated, the pointer to it is stored in an internal table. AfxGetApp() simply returned.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Does anyone mind briefly explaining what hard wired means in C++???
sorry if im asking childish questions 
Thanks guys 
|
|
|
|
|
This is probably referring to values being 'hard coded'.
So if you have explicitly defined a numeric or string in your code, then it is termed as being 'hard-coded'.
The flip side of this is to construct your coding so that your values are user-defined, or can be obtained from an external source.
#define PI 3.142
float calc(int a, int b)
{
return (a * b * PI);
}
</code>
So in the above example, I have hard-coded the value of pi. In this case the accuracy of my calculations are fixed. If I needed to increase the accuracy of pi at a future date, I need to edit and recompile my code. This may not be a problem now, but can cause some problems in certain circumstances.
Hard coding string values are also widely mentioned and can be extremely difficult for multi-lingual software. In cases where your program messages, logs, reports and UI text may change (due to language changes for example), you do not want to hard-code text strings when writing your code. One way around this is to use the string resource files that de-couple this process.
I Dream of Absolute Zero
|
|
|
|
|
Hardwired[^] is often used to convey the concept of logic (i.e. control flow) that's "unchangeable" or "difficult to change".
/ravi
|
|
|
|
|
Adding to what other have posted, here are some examples of hardwired code:
void main(void) {
double cylinder_volume=5.5*3.1415*3.1415*7.9;
printf("The total cylinder area is %.15g\n", cylinder_volume*4.0);
long total_people_to_invite=10.0;
printf("The total invitations is %d\n", total_people_to_invite);
}
This code is hardwired to the extreme. Compare to the next code example:
#define PI 3.1415912
void main(void) {
double cylinder_radius=5.5;
double cylinder_height=7.9;
double cylinder_top_area=cylinder_radius*PI*PI;
double cylinder_volume=cylinder_top_area*cylinder_height;
double total_cylinders=4.0;
printf("The total cylinder area is %.15g\n", cylinder_volume*total_cylinders);
long singers=1;
long bartenders=3;
long dancers=5;
long cooks=1;
long total_people_to_invite=singers+bartenders+dancers+cooks;
printf("The total invitations is %d\n", total_people_to_invite);
}
This code is not as hardwired. Still, it could be coded to be even more flexible and reusable. For example, the area computation of a circle (used for the cylinder_top_area) could be implemented as a function which takes the radius.
In general, the sense of "hardwired" code is related simultaneously to how clear it is to read it, understand it, change it, and re-use it. The easier it is to acomplish those things *SIMULSTANEOUSLY* the less hardwired the code is.
In the above example all the predefined quantities could even come from some external configuration file, making changes easy even without recompilation. For the above example, this could be too much. So "hardwired" is not a clearly defined concept, but you see that if for such a simple example as the cylinder volume and invitation count external files had to be opened to read configuration parameters then, clearly, reading and understanding would be harder.
I hope this helps,
Rilhas
|
|
|
|
|
Hi,
I am writing a console application when I came across a problem where C++ would allow me to divide by zero when using doubles, but would not through out an exception. Is there anyway I can get the program to throw the divide by zero exception. Here is a sample program I made:
#include <iostream>
int main()
{
double x = 5.0;
double y = 0.0;
double z = x / y;
return 0;
}
The value of z ends up being infinity, but there is no exeception thrown and the program runs to completion.
|
|
|
|
|
You won't get an exception when dealing with floats or doubles. If you want to check for divide-by-zero problems, either check your denominator for values close to 0 or cast it to an int.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
Semantics changed since Visual C++ 7.1; structured exceptions (SEH) are no longer caught
When compiling with /EHs, a catch(...) block will not catch a structured exception (divide by zero, null pointer, for example); a catch(...) block will only catch explicitly-thrown, C++ exceptions.
Check MSDN for more information[^]
SaRath.
"Where I am from, there is no plan B. So, take advantage of today becuase tomorrow is not promised. - 50 Cent"
My Blog | Understanding State Pattern
Last modified: Friday, August 04, 2006 12:11:47 PM --
|
|
|
|
|
kpeng1 wrote: Is there anyway I can get the program to throw the divide by zero exception.
Here is a MFC example.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I guess I kind of phrased things wrong. I actually want the debugger to catch the divide by zero. I tried to enable the break into the debugger option in for floating points divide by zero and it does not break into the debugger. Any ideas?
|
|
|
|
|
Your best solution would be to do something like:
double x = 5.0;
double y = 0.0;
const double epsilon = 0.0001;
if (abs(y) < epsilon)
{
throw "Divide by 0!";
}
double z = x / y;
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Exceptions are expensive. Checking for zero before doing a division operation where zero might be in the denominator is cheap and the preferred method.
(I also add ASSERTS to check for these conditions, which will cause a catchable exception in the debugger.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
strToken is retaining an invalid value.
+ strToken 0xcccccccc <Bad Ptr> char *
unsigned int CSentenceAr::search(const char* strSearch)
{
// initialize local variables
unsigned long iWordCount = 0;
char buffer[MAX_SENTENCE_LENGTH] = {0};
/* Algorithm:
strToken shall initially contain the sentence string.
When strWord is found from the string, this is removed
from the string so that this function checks the rest of the
string for other instances of the word.
*/
char* strToken = {0};
for (int iCurrent = 0; iCurrent < Size; iCurrent++)
// copy to buffer, used as parameter for strstr.
{ memcpy(buffer, Sentences.strSentence[iCurrent], MAX_SENTENCE_LENGTH);
strToken = strstr(buffer,strSearch);
while (strToken !=0 && *strToken != 0)
{
if (strlen(strToken) > 0)
{ iWordCount++;
strToken += strlen(strSearch);
}
if (strToken >= buffer + MAX_SENTENCE_LENGTH)
{break;}
strToken = strstr(strToken, strSearch);
}
}
return (int) iWordCount;
}
Is it declared incorrectly?
Jon
|
|
|
|
|
jon_80 wrote: strToken is retaining an invalid value.
At what point?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Since it is declared (see the code), that's why I said retained. The problem is that since it has an invalid value the program is not going through the while loop.
Jon
|
|
|
|
|
strstr() will return NULL if strSearch is not found in buffer. That would be why the while loop is not entered. You should be able to set a breakpoint on the strstr() statement to confirm this.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
