Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / February 2007

Tip: Looking for answers? Try searching our database.

Converting const char * -> System::String^ without gcnew.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
DaTurk - 22 Feb 2007 23:02 GMT
Hi,

I have several interfaces in CLI that I access via c#.  My problem is,
is that down in the unmanaged c++, which the CLI lies on top of, I
have a lot of c_str() happening.  But all of my methods in CLI return
System::String^.  I originally just gcnew'd System::String^ passing in
the c_str().  But I can't really have as many gcnew's as I'm using for
overhead and for fear of leaks.

So my question is this, how can I get the char* coming from c_str()
call to return as a System::String^ without actually calling gcnew?
The reason this is an issue is that these libraries are pushed quite
hard, maybe having string coming through in excess of 100 time a
second and will most likely never be turned off.  Any ideas?

THanks in advance.
Tamas Demjen - 22 Feb 2007 23:43 GMT
> I originally just gcnew'd System::String^ passing in
> the c_str().  But I can't really have as many gcnew's as I'm using for
> overhead and for fear of leaks.

There is no leak, System::String^ is garbage collected. Even if you
wanted to, you couldn't control the memory deallocation of managed
strings. It's always managed by the .NET framework.

The overhead is given, you can't avoid that. char* is an unmanaged 8-bit
per character string, while System::String is a managed 16-bit per
character string. At the minimum, the string's value must be copied
between those two classes, you can't avoid that. Even when you assign
one std::string to another, a byte-for-byte copy has to be made. Even
std::string calls malloc and free internally, which are typically slower
than gcnew. When you have enough memory available, gcnew can be as fast
as incrementing a pointer.

> So my question is this, how can I get the char* coming from c_str()
> call to return as a System::String^ without actually calling gcnew?

You can not.

> The reason this is an issue is that these libraries are pushed quite
> hard

If the native->unmanaged transition is proven to cause a major
performance problem, you have to write your code 100% managed, or 100%
native. In fact, std::string itself is not nearly as fast as working
with char* directly (see strncpy, itoa, snprintf, etc.).

Tom
Ben Voigt - 23 Feb 2007 00:14 GMT
>> So my question is this, how can I get the char* coming from c_str()
>> call to return as a System::String^ without actually calling gcnew?
>
> You can not.

So what if you can't make a String without gcnew, you can do even better.

Require your caller to pass you either a preallocated System::Char[]
(cli::array<wchar_t>^) or a StringBuilder.  Then you needn't reallocate
memory on each call.

But memory allocation in .NET is optimized and should be a very cheap
operation, unless you are allocating large objects in a loop (using
String::Concat iteratively to slowly build a large string is very bad, use a
StringBuilder instead for that sort of thing and preserve a sufficient
Capacity).

> If the native->unmanaged transition is proven to cause a major performance
> problem, you have to write your code 100% managed, or 100% native. In
> fact, std::string itself is not nearly as fast as working with char*
> directly (see strncpy, itoa, snprintf, etc.).

But of course you may work directly with a managed array and interior
pointers with no extra overhead, and only a little extra if you need to
pin_ptr it to pass to a native function.
Tamas Demjen - 23 Feb 2007 01:46 GMT
> Require your caller to pass you either a preallocated System::Char[]
> (cli::array<wchar_t>^) or a StringBuilder.

That sounds reasonable. It still requires a copy operation, which could
be slower than what you save by eliminating gcnew from the loop.

> But of course you may work directly with a managed array and interior
> pointers with no extra overhead

I like this idea. So you recommend returning an IntPtr to the char*:

// C++/CLI library:
struct Unmanaged
{
   Unmanaged() : some_string("test") { }
   std::string some_string;
};

public ref class Lib
{
public:
   Lib() : unmanaged(new Unmanaged()) { }
   ~Lib() { this->!Lib(); }
   !Lib() { delete unmanaged; }
   IntPtr GetString() { return &unmanaged->some_string[0]; }
private:
   Unmanaged* unmanaged;
};

// C# application:
unsafe void ProcessString()
{
   using(Lib lib = new Lib())
   {
      IntPtr ip = lib.GetString();
      byte* c = (byte*)ip.ToPointer();
      // access Unmanaged::some_string's characters directly from C#
   }
}

This can only be used with the unsafe keyword and the /unsafe compiler
switch.

Tom
Ben Voigt - 23 Feb 2007 14:52 GMT
>> Require your caller to pass you either a preallocated System::Char[]
>> (cli::array<wchar_t>^) or a StringBuilder.
>
> That sounds reasonable. It still requires a copy operation, which could be
> slower than what you save by eliminating gcnew from the loop.

How?  gcnew will require the same copy operation, as well as creating an
additional garbage collected object.  But the C++ code can most likely work
with unicode directly, and avoid the copy operation.

>> But of course you may work directly with a managed array and interior
>> pointers with no extra overhead
>
> I like this idea. So you recommend returning an IntPtr to the char*:

No, I recommended totally avoiding any allocation inside the function, and
having the caller provide an existing buffer, so that one buffer allocation
can serve multiple calls into the C++ code.

Let the caller pass in a (C#) byte[] if working with ASCII data, or a char[]
if working with Unicode.  Getting a System::String of the data eventually
involves a new instance, because String objects are immutable -- each
distinct content requires a distinct instance.  Of course, you can also try
to share string instances across multiple calls that return the same content
(this also helps future comparison).
DaTurk - 23 Feb 2007 19:14 GMT
> >> Require your caller to pass you either a preallocated System::Char[]
> >> (cli::array<wchar_t>^) or a StringBuilder.
[quoted text clipped - 21 lines]
> to share string instances across multiple calls that return the same content
> (this also helps future comparison).

What about MArshaling?  What if you Marshal the c_str to a
std::string.  Then can't you just do something of the nature String^
test = std::string test?
Ben Voigt - 23 Feb 2007 21:35 GMT
>> >> Require your caller to pass you either a preallocated System::Char[]
>> >> (cli::array<wchar_t>^) or a StringBuilder.
[quoted text clipped - 32 lines]
> std::string.  Then can't you just do something of the nature String^
> test = std::string test?

One, a std::string is not compatible in any way with a System::String^, the
conversion is first to char*.  Secondly, Marshaling is an expensive
operation that requires multiple copies, and would only be appropriate for
interprocess communication.  With C++/CLI, the managed and unmanaged code
share the same process, the same memory space, even the same thread, so
marshalling is definitely not needed.

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.