|
thank you so much......now i have an idea...
thank you
mazeed
|
|
|
|
|
thank you,
it is work..
i'm using cin.ignore()..
thank you so much...
mazeed
|
|
|
|
|
Why are you using char[] variables with C++ when string variables would be way more efficient? Yeah, it's only a few hundred bytes, but that, coupled with not having to use strcxx(), is a good reason to switch.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi all:
I'm wondering how's the following code snippet could finish returning the final 'nn' to the caller, since I did not explicitly return 'nn' on each recursive call.
int ss(int n)<br />
{<br />
int nn;<br />
if (n)<br />
nn = (n + ss(n - 1));<br />
else<br />
return 0;<br />
}<br />
<br />
int n = ss(4);
|
|
|
|
|
Actually it returns 0 on my system.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
LiYS wrote: I'm wondering how's the following code snippet could finish returning the final 'nn' to the caller, since I did not explicitly return 'nn' on each recursive call.
Compiler should issue warning about return path.
Prasad
MS MVP - VC++
|
|
|
|
|
I guess accumulator register is used to store the return value,
Since the code donot execute the return statement except at the last,
the previous result in the accumulator n+ss(n-1) is taken as return value.
Thus we get the currect value. If you used return 1; instead of return 0;
you get 1 + the result;
Best Regards
Raj
|
|
|
|
|
Yes, I guess you're right, add the following asm statement makes the program result logical to me. But what's the theory behind this?
int sum(int n)
{
int nn;
int dummy = 0;
if (n)
{
nn = (n + sum(n - 1));
__asm
{
mov eax, 0
}
}
else
return 0;
}
|
|
|
|
|
There is nothing theoritical, It depends on the implementation of the compiler.
if _asm::call is the opcode for a function call, then it has to place its return value in some register/memory location;
I guessed it is some where on the return mechanism and verified in code dissassembly.
int n = ss(4); will be something like
push 4
call ss
mov dword ptr [n],eax
After a call, we need the return value, called subroutine places its return value in eax.
Iam not sure, the theory of VC++ compiler is available open, but i believe this depends on the compiler implementation, for instance gcc compiler may not behave the same, hence most compiler flashes warning some thing like "not all code path returns value"
Best Regards
Raj
|
|
|
|
|
simply add some accumulator register involving operation next to nn = (n + ss(n - 1));
like another addition. It won't work as you expected.
|
|
|
|
|
Hi All,
first time building a DLL not to mention C++ program and I'm having a little trouble trying to get the parameters passed to it.
I'm using VC++ 6.0. I created this via a 'Regular DLL using shared MFC DLL'
Upon running it basically creates an application class, then creates a dialog box. This piece works!
Now, I need to pass it three parameters to use though out the program, do I create a new method within the application class to grab these values? (If so can someone give me some example on what I need in this method) Or have I gone the wrong way in trying to build this? All examples I have read are fairly simple DLLs with functions, mine is based on classes.
Any help would be greatly appreciated
Hayden
|
|
|
|
|
Hayden25 wrote: Now, I need to pass it three parameters...
You'll need to do this via an exported function.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
how can i determine wheather the cd door is ejected or not
|
|
|
|
|
nitinmx wrote: how can i determine wheather the cd door is ejected or not
See here[^].
|
|
|
|
|
Rather than guess/query what state it's in, why not simply put it into the state you need? There's no harm in opening a door that's alread open, or closing a door that's already closed.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello,
I have a strange problem. When I use the function _vsntprintf_s in my program. the program finishes without any error messages..
if I use _vsntprintf the whole things works as expected. Has anyone an idea?
I want to use the secure verision because here I have the possibilty to use _TRUNCATE, which I really need...
<br />
dwLen = _vsntprintf((TCHAR*)logEntry.message, sizeof(logEntry.message) / sizeof(TCHAR), szFormatString, args);<br />
dwLen = _vsntprintf_s((TCHAR*)logEntry.message, sizeof(logEntry.message), _TRUNCATE, szFormatString, args);
best regards
Hansjörg
|
|
|
|
|
As it's compiling and the call to _vsntprintf_s is happening then there's really only two possible causes. One is the data/paramters you are passing and the other is that previous lines of code have caused some horrible corruption which is killing the process but has essentially nothing to do with _vsntprintf_s. I'd guess at the former but I agree that this shouldn't be happening. Possibly you've hit some nasty corner case where the CRT simply calls abort(); and for some reason you're not seeing anything in the debug trace. Remember the same code, called by _vsntprintf_s is going to be used to format that debug trace output, so if you trash it badly enough you won't see any debugging info 
I would recommending installing the CRT sources which is an option on your Visual Studio installation, if you didn't already, and then adding the path e.g. C:\Program Files\Microsoft Visual Studio 8\VC\crt\src to the include search path of your project so you can step into the _vsntprintf_s call and debug what's going on. It get's pretty deep in there but it shouldn't take too long to find where it's dropping out. You could always wrap the call in some exception handling as well if you thing the CRT might be throwing at you. Obvious the first port of call is to thoroughly check your parameters but I'm guessing you did that already
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
 i am reading source code, there are lines below :
------------------------------------------------
...
WNDCLASSEX wcx;
...
wcx.cbWndExtra = sizeof(TextView *);
...
...
TextView *ptv = (TextView *)GetWindowLongPtr(hwnd, 0);
....
SetWindowLongPtr(hwnd, 0, (LONG)ptv);
....
-------------------------------------------------
i have never seen pass "0" to GetWindowLongPtr, what it means?
And another question:
MSDN says:"Valid values are in the range zero through the number of bytes of extra window memory, minus the size of an integer."
It means ((zero ~ Num of Bytes) - sizeof(int)) or (zero ~ (Num of Bytes - sizeof(int)) ) ??? What is it used for?
How to store and access the userdata associated with a window instance.
|
|
|
|
|
zhongwenjia wrote: i have never seen pass "0" to GetWindowLongPtr, what it means?
It means that extra window memory has been specified by setting the cbWndExtra member of WNDCLASSEX, and then using SetWindowLongPtr(hwnd, 0, (LONG)ptv); to store a value in that memory, at offset 0.
|
|
|
|
|
OK ! then, what are GWLP_USERDATA and DWLP_USER used for ???
What`s the difference!!!
Their offset are not zero.
Thank you very much!!!
|
|
|
|
|
GWLP_USERDATA (and DWLP_USER) are LONG_PTR-sized slots that you get for free.
If you need additional space you need to reserve some with the "cbWndExtra member of WNDCLASSEX"
as mentioned by Hanz.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hi all:
int WINAPI _tWinMain(HINSTANCE hinstExe, HINSTANCE, PTSTR pszCmdLine, int) {
char szBuf[100];
szBuf[10000] = 0; // Stack underflow
return(0);
}
It was said that the above code snippet will cause stack underflow, but since we got 1MB of thread stack space, we're only trying to access to 10000 byte of memory, I believe you got stack underflow when you trying to access the area beyond the stack's origin, right? Or this is because of you're trying to access to a address space which is not reserved to be exactly, instead of stack underflow.
|
|
|
|
|
Hi,
Compiler will set up a "stack frame" whenever a function is called. "stack frame" is a memory area that holds function arguments, local variables.
1 MB is the default "stack" size of a thread not the "stack frame" size, it is the total memory area of all the "stack frame" (allocated for each function) in a call graph. when this limit is exceeded you will get "stack overflow". Try a infinite recursive function to get this exception.
you in your code exceeded the "stack frame" size.
Best Regards
Raj
|
|
|
|
|
Hi, thanks for the reply,
Rajkumar_R wrote: you in your code exceeded the "stack frame" size.
sounds suspicious to me, I believe exceeded the stack will causes an access violation instead of *stack frame*, besides isn't the stack frame has variable size? and it can grows from the begining of frame to near the bottom of the stack, but in this situation, _tWinMain is the one of the first frame on the stack and I figure count from 1000 byte there's still enough space to the bottom of the stack. In addition how this is causing stack *underflow*?
-- modified at 4:20 Thursday 7th June, 2007
|
|
|
|
|
The stack grows from high memory locations to lower ones; arrays are indexed from low memory locations to higher ones; local variables are placed on the stack. Thus your code is likely to access memory "below" the bottom of the stack. While I personally wouldn’t technically class this as a stack underflow (because nothing is being popped off) it has much in common with one.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
