Interop: String or StringBuilder

[Morgan Cheng]

In P/Invoke situation, If some *out* parameter is LPWSTR, I can use
string or StringBuilder. However, there is one problem about
StringBuilder. By default, its Capacity is 16. If the returned string
length is larger than 16. An ArgumentOutOfRangeExceptoin is raised.
However, if string is used, no exception.

I searched this topic. It is said that StringBuilder is preferred in
this case, because the performance is better. I don't think so. The
*out* keyword just means that the return value will be assigned to the
argument. The argument itself is un-initialized in the funciton body.

public static void foo(out string str)
{
Console.WriteLine(str);// it doesn't compile, because str is just a
symbol, not intitalized.
}

IMHO, what actually happens to string or StringBuilder only matters in
the last stage. That is CLR finally compose a LPWSTR and try to assign
to String or StringBuilder. The performance is no different for String
and StringBuilder because is only one shot. No redundant String object
is created. I don't understand why StringBuilder is recommended in
P/Invoke according to some resources.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Check www.pinvoke.net you will have a lot of examples (even maybe yours)

--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Morgan Cheng" <mo************@gmail.comwrote in message
news:11**********************@d34g2000cwd.googlegr oups.com...

In P/Invoke situation, If some *out* parameter is LPWSTR, I can use
string or StringBuilder. However, there is one problem about
StringBuilder. By default, its Capacity is 16. If the returned string
length is larger than 16. An ArgumentOutOfRangeExceptoin is raised.
However, if string is used, no exception.

I searched this topic. It is said that StringBuilder is preferred in
this case, because the performance is better. I don't think so. The
*out* keyword just means that the return value will be assigned to the
argument. The argument itself is un-initialized in the funciton body.

public static void foo(out string str)
{
Console.WriteLine(str);// it doesn't compile, because str is just a
symbol, not intitalized.
}

IMHO, what actually happens to string or StringBuilder only matters in
the last stage. That is CLR finally compose a LPWSTR and try to assign
to String or StringBuilder. The performance is no different for String
and StringBuilder because is only one shot. No redundant String object
is created. I don't understand why StringBuilder is recommended in
P/Invoke according to some resources.

[Willy Denoyette [MVP]]

"Morgan Cheng" <mo************@gmail.comwrote in message
news:11**********************@d34g2000cwd.googlegr oups.com...
| In P/Invoke situation, If some *out* parameter is LPWSTR, I can use
| string or StringBuilder. However, there is one problem about
| StringBuilder. By default, its Capacity is 16. If the returned string
| length is larger than 16. An ArgumentOutOfRangeExceptoin is raised.
| However, if string is used, no exception.
|
| I searched this topic. It is said that StringBuilder is preferred in
| this case, because the performance is better. I don't think so. The
| *out* keyword just means that the return value will be assigned to the
| argument. The argument itself is un-initialized in the funciton body.
|
| public static void foo(out string str)
| {
| Console.WriteLine(str);// it doesn't compile, because str is just a
| symbol, not intitalized.
| }
|
| IMHO, what actually happens to string or StringBuilder only matters in
| the last stage. That is CLR finally compose a LPWSTR and try to assign
| to String or StringBuilder. The performance is no different for String
| and StringBuilder because is only one shot. No redundant String object
| is created. I don't understand why StringBuilder is recommended in
| P/Invoke according to some resources.
|

This same question is answered in your previous post.
No one ever said that a StringBuilder is faster than a String when passed as
argument to another method (and in your case to an unmanaged function using
the managed/native interop layer).
What you have to pass to unmanaged code depends on the semantics, an out
argument doesn't require a StringBuilder, all you need to pass is an
(initialized or uninitialize, doesn't matter) String variable, the marshaler
(default implicit behavior) will correctly marshal the unmanaged buffer to a
String instance and return the reference into the variable.
Whenever you pass a String requiring In/Out semantics, you better pass a
StringBulder. But here again you need to make sure the StringBuilder is
large enough to accommodate the returned string.

Willy.

[Christof Nordiek]

Hi Morgan,

"Morgan Cheng" <mo************@gmail.comschrieb im Newsbeitrag
news:11**********************@d34g2000cwd.googlegr oups.com...

In P/Invoke situation, If some *out* parameter is LPWSTR, I can use
string or StringBuilder. However, there is one problem about
StringBuilder. By default, its Capacity is 16. If the returned string
length is larger than 16. An ArgumentOutOfRangeExceptoin is raised.
However, if string is used, no exception.

I searched this topic. It is said that StringBuilder is preferred in
this case, because the performance is better. I don't think so. The
*out* keyword just means that the return value will be assigned to the
argument. The argument itself is un-initialized in the funciton body.

public static void foo(out string str)
{
Console.WriteLine(str);// it doesn't compile, because str is just a
symbol, not intitalized.
}

IMHO, what actually happens to string or StringBuilder only matters in
the last stage. That is CLR finally compose a LPWSTR and try to assign
to String or StringBuilder. The performance is no different for String
and StringBuilder because is only one shot. No redundant String object
is created. I don't understand why StringBuilder is recommended in
P/Invoke according to some resources.

the performance of the called function certainly wont change, but the
marshalling of the
parameters could perform different. But depending on what the function does
and how
often it is called the difference wouldn't matter much.
Only if the function itself runs very short and is called very often it
would be a performance issue.
In case of doubt you should performance test it for your application.

hth