Marshal::StringToHGlobalAnsi and the corresponding overhead

[DaTurk]

Hi,

I have a c# GUI that needs to untimately send its data down to
unmanaged c++. I've decided to do this by having a ref struct in the
CLI layer and have the c# populate this, and then pass it back to the
CLI layer. The CLI layer will then populate the unmanged struct where
the data needs to end up.

Now, my question, I just realized that I'm going to have alot of
strings. I need to have these things end up as char*, but they start
as String^. I'm just thinking about overhead, I was thinking about
Marshalling the strings via Marshal::StringToHGlobalAnsi, but I'm a
little worried about the overhead. Any ideas?

Thanks in advance.

 

[William DePalo [MVP VC++]]

Now, my question, I just realized that I'm going to have alot of
strings. I need to have these things end up as char*, but they start
as String^. I'm just thinking about overhead, I was thinking about
Marshalling the strings via Marshal::StringToHGlobalAnsi, but I'm a
little worried about the overhead. Any ideas?

If you don't plan to modify the strings you can use PtrToStringChars():

http://blogs.msdn.com/slippman/archive/2004/06/02/147090.aspx

IMO, it's only by profiling that you'll be able to determine if your worries
are warranted or if one method is materially better than another.

Regards,
Will

 

[Ben Voigt]

Hi,

I have a c# GUI that needs to untimately send its data down to
unmanaged c++. I've decided to do this by having a ref struct in the
CLI layer and have the c# populate this, and then pass it back to the
CLI layer. The CLI layer will then populate the unmanged struct where
the data needs to end up.

Now, my question, I just realized that I'm going to have alot of
strings. I need to have these things end up as char*, but they start
as String^. I'm just thinking about overhead, I was thinking about
Marshalling the strings via Marshal::StringToHGlobalAnsi, but I'm a
little worried about the overhead. Any ideas?

Most of the overhead there is in Unicode->ANSI conversion. If the client

 

[DaTurk]

Hi,

I have a c# GUI that needs to untimately send its data down to
unmanaged c++. I've decided to do this by having a ref struct in the
CLI layer and have the c# populate this, and then pass it back to the
CLI layer. The CLI layer will then populate the unmanged struct where
the data needs to end up.

Now, my question, I just realized that I'm going to have alot of
strings. I need to have these things end up as char*, but they start
as String^. I'm just thinking about overhead, I was thinking about
Marshalling the strings via Marshal::StringToHGlobalAnsi, but I'm a
little worried about the overhead. Any ideas?

Most of the overhead there is in Unicode->ANSI conversion. If the client
can use byte[] (cli::array<System::Byte>^) instead, it will be faster.
Depends on whether it acts like character strings or raw byte data.

Thanks in advance.- Hide quoted text -

- Show quoted text -

That's interesting, I didn't think about that. There will still have
to be someconversion at some point as the information I'm going to be
using is going to be coming from a WinForm, so it will be of the type
String^ at the presentation layer. SO I huess the question then
becomes, would it be more costly to convert a String^ -> a byte[] at
the presentation layer, or to convert a String^ -> a char* down lower
in the program?

 

[Ben Voigt]

That's interesting, I didn't think about that. There will still have

to be someconversion at some point as the information I'm going to be
using is going to be coming from a WinForm, so it will be of the type
String^ at the presentation layer. SO I huess the question then
becomes, would it be more costly to convert a String^ -> a byte[] at
the presentation layer, or to convert a String^ -> a char* down lower
in the program?

I think the Unicode->ANSI conversion may be implemented differently in .NET
vs native, so that could be a consideration too. Otherwise, I don't see why
either path would be any faster. I would probably hand a String^ to C++ to
keep the presentation layer free from implementation details.

My basic suggestion was that not all char* start life as strings, some are
more "magic numbers". E.g. in SMTP, the "MAIL TO:" command isn't a string
subject to localization, it has to be those exact bytes. Similarly for HTML
tags and the filetype codes used by a lot of programs (GIF does this).
Yours is user-entered though, so you do need the conversion.