|
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
|
|
|
|
|
Stephen Hewitt wrote: The stack grows from high memory locations to lower ones; arrays are indexed from low memory locations to higher ones;
makes perfect sense to me, this way the program trying to access area beyond the origin of the stack (in your term "bottom" of the stack), thus underflow is caused. Thanks.
Stephen Hewitt wrote: While I personally wouldn’t technically class this as a stack underflow
How would you define a stack underflow?
|
|
|
|
|
LiYS wrote: How would you define a stack underflow?
Attempting to "pop" an item from an empty stack. Like Stephen said, you ain't popping, so you ain't underflowing.
"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
|
|
|
|
|
I have seen MSDN for the above but what is the real reason for the usage of GetBuffer/ReleaseBuffer? In the below code the value i comes out to be 3 then what is the intent of 1024 as the arguement in GetBuffer. If I change the value to 2 i still comes out to be 3. Please explain.
CString s;<br />
s = "abc";<br />
LPTSTR p = s.GetBuffer( 1024 );<br />
int i = _tcslen((LPCTSTR)p);<br />
_tcscpy(p, _T("abc"));
ASSERT( s.GetLength() == 3 );
s.ReleaseBuffer();
|
|
|
|
|
When you call GetBuffer with 1024, 1024 bytes will be allocated as an internal buffer but your string is still 3 characters long (it is still "abc", no matter how large the buffer is).
It is the same principle as:
char szBuf[1024];<br />
strcpy(szBuff,"abc");<br />
int Size = strlen(szBuff);
|
|
|
|
|
The function pair exists because CString object deallocates/reallocates internally its buffer.
The argument supplied to GetBuffer is the minumum warranted buffer size NOT the stringh length.
GetBuffer is used whenever you want to perform operation directly with the CString buffer (usually you don't have to do it). The call to GetBuffer gives to you, at least, the requested memory size. On the other hand, you need to call ReleaseBuffer to tell the CString object you've finished with you buffer raw operations, i.e. CString object can freely (and transparently) internally reallocates memory as needed.
Hope that helps.
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.
|
|
|
|
|
|
you'd better get to work on this -- so we can see the result!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>
|
|
|
|
|
Hi,
Can anybody tell me how to convert PLVOID[] into CSTRING?
Its urgent.
Regards
Atul
Atul Bhatt
|
|
|
|