Not sure , i have seen the mono string creation code and what really makes me ask this , is unlike many systems you dont tell the CLR how big the object is it works it out itself. They would not do this hack ( for string) unless they needed to ..
I dont think place it at the end works .. ( i do remember it in C++ with malloc and C# to interop unions but cant find it for variable arrays ) it works for unmanged or stack with value objects but the GC will just allow an object to be placed after the object. Im particularly interested in variable size known only at run time . Without it i dont think its possible to have fast string and i think fast string is a huge win for middle tier servers and mobile devices. Actually we could do another trick but it would only work for fast string ... just hijack string - use string as the data storage Option 1) Change create fast string to create as string and cast as faststring ( also illegal but can do it in CIL ) can do this for any variably type as long as the constructor works ( and there is an unsafe sbyte* constructor as well which can be wrapped ) Redirect methods to static calls with a this prt for the string . Option 2: Fixedstring extends String . This should all work unfortunately sealed on string is present in the CLR , it should work but is against spec. You could patch the CIL Corlib and MsCorlib but the sighning will be different so it wont work on strongly signed assemblies. BTW Fixed is not supported in classes , while there is no practical reason as Shap has said what does fixed offer over [MarshalAs(UnmanagedType. ByValArray, SizeConst = 128)] which can be used on classes and generates this CIL .field public marshal(fixed array[128]) char[] fixedBuffer ? Ben On Fri, Aug 30, 2013 at 2:17 PM, Jonathan S. Shapiro <[email protected]>wrote: > On Thu, Aug 29, 2013 at 11:13 PM, Bennie Kloosteman <[email protected]>wrote: > >> No reason we couldnt say variable sized types need to be sealed.. >> > > But no reason we need to either. You're over-thinking this. > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
