[Mono-dev] Could String constructors be redirected to managed methods?
kornelpal at gmail.com
Mon Jul 10 20:46:01 EDT 2006
I know that the string is allocated by the constructors but the managed
implementation could use InternalAllocateStr as demonstrated by the
previously attached diff file. (The code probably won't compile but you can
examine it to see how I would like to use these methods.)
The methods have the same signature as the constructors, they are instance
methods to have this parameter and return a newly allocated string.
So I think that they could be used instead of the current unmanaged methods.
----- Original Message -----
From: "Zoltan Varga" <vargaz at gmail.com>
To: "Kornél Pál" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Monday, July 10, 2006 6:42 PM
Subject: Re: [Mono-dev] Could String constructors be redirected to managed
String ctors are handled specially by the runtime, since the size of
which needs to be allocated is dictated by the parameters of the ctor, so we
can't do the usual 'allocate an object, then call its ctor' stuff, the
has to allocate the string object. This is why these ctors are implemented
On 7/10/06, Kornél Pál <kornelpal at gmail.com> wrote:
> The following methods are currently implemented using unmanaged code:
> unsafe public extern String (sbyte *value);
> unsafe public extern String (sbyte *value, int startIndex, int length);
> unsafe public extern String (sbyte *value, int startIndex, int length,
> Encoding enc);
> They all should use Encoding classes (overloads without encoding
> should use Encoding.Default). I think they could be implemented more
> and probably much faster using managed code.
> I attached a patch draft that contains CreateString methods that should be
> called instead of unmanaged code to show an example why this could be
> and faster.
> Is it possible to redirect these constructors to CreateString methods
> instead of unmanaged functions? If possible how could this be implemented?
> Thanks for your help.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list