On Sun, Sep 1, 2013 at 11:01 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sun, Sep 1, 2013 at 8:23 PM, Bennie Kloosteman <[email protected]>wrote: > >> 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. >> > > I think you are obsessing over a very difficult problem that has no > business being in the runtime layer. > > Can I ask you to define "fast string". What are the complexities of the > following operations: > > Get next character in sequence > Get character at (arbitrary) index i > I do think Bennie is obsessing a bit. However, the tricky problem their runtime interned string is solving is variable-size fixed-arrays embedded in the object -- without reinstantiating any code parametrics. Generally solving this involves more than just fixed-size arrays, it requires run-time specified sizes for a fixed-size-array which doesn't cause code-re-instantiation. Without any field-position-indirection, I think this can provably only be done for a single fixed-size-array (appended at the end of the struct). Anything else would require either field-location indirection, or per-size code-instantiation. I think a general runtime mechanism for this would have to accept that a struct can only have a single runtime-variable sized array like this, and to do so it must be a sealed (non-derivable) class. 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 ? "unsafe fixed char fixedBufferA[128];" allows you to embed multiple fixed-size arrays in a single contiguous and cache-efficient value-type-record. Your ".field public marshal(...) char[] fixedBuffer" is a reference type array pointed to by the class, located somewhere else in memory.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
