On Fri, Oct 15, 2010 at 8:47 PM, Ben Kloosterman <[email protected]> wrote:
> I must say the idea is growing on me since it’s an abstraction layer , > the strand reference can be so say a simple char UCS-1 strand with no > 2ndreference tree for small strings and we can intern small strings heavily > when using a GC. > Yes. Further: (1) we can re-optimize the strands at GC-time during the copy phase, and (2) we can observe at read time when it is better to rewrite a strand in a larger size rather than concatenate two strands. > Are you considering a similar hack to .NET where the root char[] is > internal and not a separate object ? > I'm not sure what you are referring to, so probably not. BitC char is simply a scalar type. It isn't an object. > The fact you suggested flags on the array seems to suggest it rather than > typeof() this is worth it as it means your only creating 1 object instead of > 2 . > I'm sorry - I'm not understanding what you are saying here. Can you expand on this? > However wont you need some API for legacy C char[] string code anyway > especially where the code may not have or want a heap or GC. Java and C# > don’t have this but it is probably one of the reason its hard to use for > embedded/systems programming witness all the noHeap stuff and string hacks > in Singularity. > The NoHeap issue is actually very complicated, and the current C# answer isn't very good. One problem with stranded strings is that it's a bit strange to ask what it means to pin them. We will in due course need something like a p/Invoke layer. But the awful truth is that a C char* simply isn't a BitC native string. We need to be able to inter-convert, but we'll almost certainly need some form of NativeString type to really get a handle on this. I have another radical idea as well, but not prepared to talk about that yet. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
