|
Keep in mind that the c/c++ is case sensitive. I'm looking at this line in particular.
Push(rpn, seq[i]);
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Member 12529159 wrote: This is something a partner gave... Ahh, the classic "copy & paste" bug.
I'm usually the one to get chided for printing off code snippets and retype them line by line into my project. Consequently, I've never been a victim of this type of problem.
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Member 12529159 wrote: There are, I think, some big mistakes Yes, this will not compile, and even if it did, none of this code is going to work. You are reading a string into the array seq and then using Push to copy characters back into the same array. You are also storing everything as characters but when you use Pop, you think you are rectrieving an integer. And you assume that each string will be two digits followed by a mathematical symbol.
|
|
|
|
|
Hi all, I have a variable declared:
CMyDlg* m_pDlg1;
I initialized it as NULL and expected it to change when passed to CallDlg. But it stays as NULL before and after the call, therefore creating new modeless CMyDlg everytime it gets called (instead of bringing up the existing one the foreground).
What did I do wrong? Shouldn't m_pDlg1 point to the newly created dialog?
Please help. Thanks in advance.
void CMyApp::ActivateDlg1()
{
CallDlg(1, m_pDlg1); }
void CMyApp::CallDlg(int nType, CMyDlg* pDlg)
{
if(pDlg) pDlg->SetForegroundWindow(); else
{
pDlg = new CMyDlg(nType);
if(!::IsWindow(pDlg->GetSafeHwnd())) pDlg->Create(IDD_MY_DLG, NULL);
}
}
|
|
|
|
|
Joe Smith IX wrote: I initialized it as NULL and expected it to change when passed to CallDlg. But it stays as NULL before and after the call, therefore creating new modeless CMyDlg everytime it gets called (instead of bringing up the existing one the foreground).
1. I do not see where, how and when you set it to NULL.
2. Did you debug your code to see the "real" values of all the variables?
3. To make debugging easier for yourself you should avoid write the code in the manner
if(pDlg) pDlg->SetForegroundWindow(); but
if(pDlg)
pDlg->SetForegroundWindow();
4. how and where do you delete the m_pDlg1 pointer?
|
|
|
|
|
1. I didn't copy the whole code, just the snippet.
2. Yes, I did. That's how I could state 'it stays as NULL before and after the call'.
3. I do. Thanks.
4. Same reason as number 1 above.
Anyway, I solved it as pointed by CPallini below. I was missing the ampersand symbol to indicate passing by pointer. Thanks anyway.
|
|
|
|
|
If you want to change the passed pointer value then you have to pass its address (because, like any other kind of parameter, pointers are passed by value) ending up with a double pointer or a reference to the pointer. e.g.
void CMyApp::CallDlg(int nType, CMyDlg & * pDlg)
void CMyApp::CallDlg(int nType, CMyDlg * & pDlg)
{
}
modified 17-May-16 15:57pm.
|
|
|
|
|
Ah, you are right. To pass by address, I need the & character. It's working fine now. Thanks so much.
void CMyApp::CallDlg(int nType, CMyDlg* &pDlg)
{
}
|
|
|
|
|
I gave you a flawed code sample, sorry.
Thank you for pointing it out so nicely.
|
|
|
|
|
if I have this code :
char * s =(char*)malloc(10);
and then I write 's="test"' then s will have a different address right ?
why is this happening ?
|
|
|
|
|
You are allocating assigning the address of the string literal "test" to the pointer s thus overwriting the address returned by malloc . You should be using strcpy to copy the four characters into the allocated buffer.
[edit]
better terminology as pointed out by member below.
[/edit]
modified 17-Jun-16 4:11am.
|
|
|
|
|
or, even better, strncpy .
|
|
|
|
|
Absolutely right, but I was trying to KISS.
|
|
|
|
|
Shouldn't that be: "you are assigning the address" instead of allocating?
|
|
|
|
|
|
Member 10964099 wrote: why is this happening ? It append because it designed this way. That is how pointers work.
I recommend to read THE book "the C Language" from Kernigan & Ritchie.
The C Programming Language - Wikipedia, the free encyclopedia[^]
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Because s is a pointer.
char * s =(char*)malloc(10);
s="test"
|
|
|
|
|
What all the others said and more generally rarely if ever do use an equal sign on a string in C at any other time than creation.
There are functions required to add, copy, compare, split and search strings and you can't just use mathematical symbols like "=" and "+" to do things with strings like you can in some higher languages. Strings are not mathematical types and you can't use mathematical functions to do things with them.
Those coming from a coding background in Java or Basic tend to do what you did and you have to unlearn it when using C because "string1" + "string2" will not work either, you will need to use strcat functions. String compares are likewise a function and you can't use mathematical equality signs to compare two strings.
Learning the string functions, it is a requirement of learning the C language.
In vino veritas
modified 14-May-16 12:10pm.
|
|
|
|
|
inside a C function I have this code
printf("%s",final);
I do a fork and this is part of the childs code
the final string is not printed when the execl line is not commented out,nor are any printf calls before it
why is this happening ?
|
|
|
|
|
Without seeing more code it is anyone's guess.
|
|
|
|
|
Probably due to line buffering.
Try
printf("%s\n", final); or add
fflush(stdout); before the execl() call;
|
|
|
|
|
If your on Eclipse it is a known bug (id=173732)
The fflush(stdout); fix is the only way around it as horrible as it is.
In vino veritas
|
|
|
|
|
Windows 7 UAC prevents my application to write log data in the installation folder. The original text log file exists from the very beggining, but its empty.
When I start my app with the -L parameter to start logging, it does not write anything due the UAC control. If I rum my app with Admin Priviledges then it works.
As you can understand I can not suggest my client to run the app with right click and "run as an Administrator".
Is there any solution for that ?
Best Regards,
sdancer75
|
|
|
|
|
Yes - don't try to write files in the installation folder. Your application will not have permission to do so.
Instead, create a folder for your application under one of the AppData locations - CSIDL_APPDATA, CSIDL_LOCAL_APPDATA or CSIDL_COMMON_APPDATA - and write the log files to that folder.
CSIDL (Windows)[^]
SHGetFolderPath function (Windows)[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you
Is that backward compatible with windows xp/vista ?
I think that win Xp does not support AppData. Is that correct ? What to do in this case ? Check the os and take a path decision specifically for it ?
sdancer75
|
|
|
|