parameter passing and EAX register

Your example should work:
http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx

if you don't want to worry about it, make just few changes, for example:
const static LPCWSTR s_szTest = L"Test";
LPCWSTR getstring()
{
return m_szTest;
}

main()
{
//everything works.
}

or make getstring as, for example:
BOOL getstring(LPWSTR szText, DWORD nCapacity)
{
wcsncat(szText, L"Test", nCapacity - 1);
return TRUE;
}

If you know about EAX - check yourself - put a breakpoint before getstring() call, "Go to assembly".

evilrix, I'm posting after you, sorry - but I have typed it. :)

It will be great, if you will continue here - I remember your artcile about it?

>> evilrix, I'm posting after you, sorry - but I have typed it.
All good views and info are welcome, there is no need to apologize

>> It will be great, if you will continue here - I remember your artcile about it?
The person we really want is Infinity08 as he does assembly programming... it is not my area of expertise.

Here is almost nothing about the assembly programming.
You already paid attention that I have to analyze huge amounts of code written by other people. So I saw this style in the code and see that it works. But, anyway, it is not something I want to use in my applications.
I remember problems when it was like:
LPCWSTR getstring()
{
   CString str;
   str = L"hello";
  return (LPCWSTR)str;
}
with CString getstring() it works. The object exists on stack. But, even with the RVO, if we will talk about the performance.... str = L"hello" means memory allocation. Example bool getstring(wchar_t* p, unsigned int n) does not allocate additional memory.

>> Here is almost nothing about the assembly programming.
At the moment I am awaiting clarification of point 3 since I'm not sure I know what the asker wants to know and I've already given the best answer I can to 1 and 2.

I attached a short app demonstrating the question - it works.

#ifndef WINVER				// Allow use of features specific to Windows XP or later.
#define WINVER 0x0501		// Change this to the appropriate value to target other versions of Windows.
#endif
 
#define _AFXDLL
 
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS	// some CString constructors will be explicit
 
#include <afx.h>
 
CString getstring()
{
	CString str;
	str = L"bye";
	return str;
}
 
int main()
{
	CString str;
	str = L"Hello";
	wprintf(L"test string %s\r\n", str);
	wprintf(L"getstring %s\r\n", getstring());
 
	char p[16] = { 0 };
	wcstombs(p, getstring(), 16);
 
	str = p;
	wprintf(L"converted unicode>mb->unicode %s\r\n", str);
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:

Hi pgnatyuk , thanks for posting the instructions.

As per my understanding,  the highlighted line in the image file - copies the getstring return value to some unnamed pointer and that will be passed to wcstombs() ..?

sorry if you could explain the flow..that would be of great pgnatyuk.

thanks

i guess...my intial question is not clear....

I will just paraphrase it ....

when a reference of a functions returned value has been passed to another function [ unnamed ?] , then what is scope of that memory ? who will take care of that unnamed memory? is this memory safe?
when will it be cleared and by whom ? what happens in assembly level for this kind of coding ?

Hi evilrix ...
thanks for your immediate response...couldnt reply u as was in vacation...

1. I am using visual studio 6.0 , winXP SP2, intel core 2 duo.
3. I have given other coding style in the below snippet. is this better or safer  than the above ? and why ?

CString getstring()
{
CString str= _T("test");
return str;
}
 
main()
{
wchar_t * l_wcs;
CString l_cs;
l_cs = getstring();
mbstowcs( l_wcs ,l_cs, 4);
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

I can say how I understand it. It helps me, but the desciption will be neither full, nor correct.
From my undestanding all these objects are created and destoyed on stack (as a local variable in a scope of a function). So you are asking not about an unnamed memory but about the stack.
More info:

http://stackoverflow.com/questions/1083215/returning-c-stack-variable

http://stupefydeveloper.blogspot.com/2008/10/c-rvo-and-nrvo.html

I think, CString object confuses us. Check the example below.

#include <iostream>
using namespace std;
 
class CTest
{
	int x;
public:
	CTest() : x(0)
	{
		cout << "CTest::CTest()" << "x = " << x << endl;
	}
 
	~CTest()
	{
		cout << "CTest::~CTest()" << endl;
	}
 
	int& X() { return x; }
 
	void test()
	{
		cout << " x = " << x << endl;
	}
};
 
CTest get_test()
{
	CTest test;
	test.X() = 1;
	return test;
}
 
void Test(int n, CTest test)
{
	for (int i = 0; i < n; i++)
	{
		test.test();
		test.X() += i;
	}
}
 
int main()
{
	Test(5, get_test());
	return 0;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:

>> is this better or safer  than the above ? and why ?
Both of your examples will crash since l_wcs is just a pointer with no allocated storage.
http://www.cplusplus.com/reference/clibrary/cstdlib/mbstowcs/

And I'm afraid I still don't really understand the point of the question. Like I said before, from the point of view of the compiler you cannot generlise about the kind of assembly code it will produce, this will vary between compilers and will be different using the same compiler with different levels of optimization.

Do you mean the example from ID:25400494 will crash?
So from where I took the code?

evilrix,  i didnt add those memory allocation code....plz never mind....

the difference i wanted to show was between line no's 10,11,12 in 2nd example and line no #10 in my first example..

highlighted those in attached png. especially the way 2nd parameter of the mbstowcs() call has been passed.

>> he difference i wanted to show was between line no's 10,11,12 in 2nd example and line no #10 in my first example..
Ignoring the memory allocation issue the first is more efficient since the second takes a copy of your string before passing it to mbstowcs. The temporary CString returned by getstring will live for the life of that 1 line making it safe to pass the return value into mbstowcs directly. If you want it to last longer than 1 line you must bind it to a const reference and then it'll last for the lifetype of the reference.

CString const & l_cs = getstring();
mbstowcs( l_wcs ,l_cs, 4);


Taking a reference doesn't make a copy but the reference MUST be const (although Visual Studio allows it not to be it's not portable since the C++ Standard demands that temporary r-values can only be bound to const references).

pgnatyuk ,
-->From my undestanding all these objects are created and destoyed on stack (as a local variable in a scope of a function).

true. But what will happen to the value which is not assigned to some variable in the caller? the called function will put the return value in EAX regsiter and clear its stack [ or caller might clear it] and control come backs to the caller.
thought it is not assigned to another variable, will the caller moves this value from EAX to its stack ?

>> But what will happen to the value which is not assigned to some variable in the caller?
Didn't I just explain that? :)

{http:#25401053}

>> will the caller moves this value from EAX to its stack ?
Also, you really need to forget about this as a EAX value. Like I said, there is no guarantee this is how the value will be returned, it is totally up to the compiler. You just need to know how it works at a C/C++ level. If you worry about the assembly level (unless you have a specific need to) you are just over-complicating things needlessly.

Absolutely!
Also the source code will look better and it will be much easier to debug it. :)

thanks evilrix .
>> The temporary CString returned by getstring will live for the life of that 1 line making it safe to pass the return value into mbstowcs directly. If you want it to last longer than 1 line you must bind it to a const reference and then it'll last for the lifetype of the reference

this is what making me worry..! how does this value life is 1line? if we have const reference, then it will be in the stack and will get cleared along with other stack variables. isnt it ?
 but if we didnt take const reference, what happens ? when I say a scope of a variable is local i can understand that the memory will be allocated in stack after  "{" and will be cleared from stack before "}" . but for this  variable of 1 line life, can I say that it will be in stack of the caller after this function call and will be cleared in the next line ? isnt confusing ?
 I tried to understand the behavior in vc compiler ....couldnt. So moved to assembly level and trying to understand it.  How it gets cleaned in next line ..?

>> how does this value life is 1line?
Any temporary created will live for the lifetime of the expression that created it.


>> if we have const reference, then it will be in the stack and will get cleared along with other stack variables. isnt it ?
Like I said, "bind it to a const reference and then it'll last for the lifetype of the reference"
So, if the reference goes out of scope so does the temporary that it bound to it

>> but if we didnt take const reference, what happens ?
Then the temporary is destroyed when the expression that created it ends (basically the current line)

>>  can I say that it will be in stack of the caller after this function call and will be cleared in the next line ?
If not bound to a const reference, that is exactly what will happen -- it goes out of scope.

>> isnt confusing ?
Not really, the life time rules of C/C++ are pretty trivial really :)

>>S o moved to assembly level and trying to understand it.
I promise you that will confuse you more... since the compiler will generate different code depending upon optimization. Forget assembly, concentrate on the lifetime rules of C/C++.

>> How it gets cleaned in next line ..?
Dunno... you don't need to -- that's the compilers job... you just need to know that a temporary only lives for the lifetime for the expression that created (simplest to think of it as the current line) it unless it is bound to a const reference.

thanks evilrix..

its really detailed and solved most of the puzzles.. :)

>> Dunno... you don't need to -- that's the compilers job... you just need to know that a temporary only lives for the lifetime for the expression that created

I Agree. I just was worrying about the safety of the program. If I give that memory reference of such a short scoped value to other function ...suppose if that function is asynchronus... wont it be an issue ?
As c++ being converted to assembly instructions and then to binary..wont it be worth knowing it ?

http://www.informit.com/blogs/blog.aspx?uk=30-C-Tips-in-30-Days-Tip-28-the-lifetime-of-a-temporary-object-bound-to-a-reference

c++ is great as it doesnt hide the details as .net does....!
though I agreed,  I couldnt accept evilrix point as I always understand c++ in relation with asm.