System::String * and string literals

[Ioannis Vranos]

When we assign a managed or unmanaged string literal to a String *, is a new String
created implicitly in the managed heap?


Or in other words, what happens when we assign a string literal to TextBox::Text and then
writing in this TextBox?

 

[ismailp]

First of all, in unmanaged code, if you assign a constant string to a
char*:

const char* szText1 = "Hello";
const char* szText2 = "Hello";

compiler generates one "Hello" and both szText1 and szText2 point the
same location.

Very same rule applies to managed applications as well.

What happens when you "type" inside the textbox deals with Windows.
After all, it is a Windows "EDIT" control. Read GetWindowText on MSDN
to learn more about how windows manage their window texts.

So,

String* pString1 = "Hello";
String* pString2 = "Hello";

will point the same location - no new string is created for pString2.
However, a new String object is constructed, and these two pointers
will be pointing to that object. (Write a sample, and open
disassembler, see "mov ecx,.." sections. ECX is "this" pointer.)

Any new assignment will change the pointer.

String* pString = "Hello";
// somewhere in your application
pString = textbox->Text; // pString points to a new object - old one is
still in GC heap!!
textbox->Text = "Hello"; // points to above "Hello"
// somewhere in your program, assume that pString is a
// line app read from a file - a new object
textbox->Text = pString; // textbox->Text points a new object

Open disassembly window (and registers) to see what's happening to ecx.

Ismail

 

[Ioannis Vranos]

First of all, in unmanaged code, if you assign a constant string to a
char*:

const char* szText1 = "Hello";
const char* szText2 = "Hello";

compiler generates one "Hello" and both szText1 and szText2 point the
same location.

Actually it is not guaranteed that they point to the same location on this. A compiler is
free to optimise them to one string literal, however this is not guaranteed, and we should
not rely on this. If we want to make sure that they point to the same place, we must make
a pointer comparison.

Very same rule applies to managed applications as well.

What happens when you "type" inside the textbox deals with Windows.

Actually when we type in a .NET TextBox, our characters get added to the System::String
pointed by the Text property. My question was if a new String object gets created
implicitly, or in effect, we are on the string literal in this case.

After all, it is a Windows "EDIT" control. Read GetWindowText on MSDN
to learn more about how windows manage their window texts.

I assume this is some Win32 API function. However I do not know Win32 API.

So,

String* pString1 = "Hello";
String* pString2 = "Hello";

will point the same location - no new string is created for pString2.
However, a new String object is constructed, and these two pointers
will be pointing to that object.

If implicit String creation takes place, I do not think both of these will be pointing to
the same object, the same as the case


String *pString1= __gc new String("Hello");
String *pString2= __gc new String("Hello");


or the case of standard C++:


string s1= "Hello";

string s2= "Hello";


The above two string objects are not the same one.

(Write a sample, and open
disassembler, see "mov ecx,.." sections. ECX is "this" pointer.)

..NET has its own assembly language and .NET assembler/disassembler. And I do not know IL
assembly so far.

 

[Carl Daniel [VC++ MVP]]

When we assign a managed or unmanaged string literal to a String *,
is a new String created implicitly in the managed heap?

A managed string literal IS a string on the managed heap. If you assing it
to a String^ (or __gc String* in MC++), you're just aliasing an existing
string.

Or in other words, what happens when we assign a string literal to
TextBox::Text and then writing in this TextBox?

Assigning to TextBox::Text will alias the managed string (make a new
reference to it), and also create an unmanaged copy that gets passed to the
edit control, which probably makes another copy of that. When you type in
the text box, the edit control is managing the contents of that native
string - I would expect it keeps a large enough buffer that it doesn't need
to re-allocate every time you type a character.

When you subsequently access the .Text property of the TextBox it will
re-fetch the text from the native textbox and make a new manged copy of it.

Remenber that managed strings are immutable - whenever something changees
the value of a string, it's really creating a new string and abandoning the
old one (which may yet be referenced by another handle).

-cd

 

[Ioannis Vranos]

A managed string literal IS a string on the managed heap. If you assing it
to a String^ (or __gc String* in MC++), you're just aliasing an existing
string.

Just to mention here that under C++/CLI there is no special 'S' prefix to a string
literal, that is I think all string literals are considered managed, at least when
assigned to String ^, implicitly probably.

Remenber that managed strings are immutable - whenever something changees
the value of a string, it's really creating a new string and abandoning the
old one (which may yet be referenced by another handle).

Right. So if I get it right, for a TextBox named TextBox1, if we do:


TextBox1->Text= "Some text";


and then type in the text box, it will generate its own Strings as usual and will not
overwrite the literal.

 

[ismailp]

exactly. TextBox1->Text will point a new string. As Carl mentioned, it
could be something like following code:

__property void set_Text(String* pStr)
{
const wchar_t __pin * lpszText = PtrToStringChars(pStr);
SetWindowTextW(m_hwnd, lpszText);
}

__property String* get_Text()
{
int nLen = GetWindowTextLength(m_hwnd);
LPWSTR lpszText = (LPWSTR)LocalAlloc(LPTR, sizeof(wchar_t) * (nLen +
1));
GetWindowTextW(m_hwnd, lpszText, nLen + 1);
String* pStr = new String(lpszText);
LocalFree(lpszText);
return pStr;
}

That allocates a new String* and return it.

When you debug your managed code with, you can see normal x86 assembly
instructions - not MSIL. I guess, JIT debugging happens during
MSIL-to-native conversion. So you can still see "ecx".

Ismail