> > > It isn't a problem with existing text string implementations? Correct. > What is a problem is that the requirement that indexing or slicing by > codepoint or code unit is O(1) is overly broad. This weaker requirement > allows people to solve the actual problem (described) with any underlying > representation, utf-8 or Rope or SillyString... And so Bennie stops > worrying about all that null. >
I stopped worying 10 posts ago when i worked out we could implement a runtime variable fixed type object by hijacking string as the internal storage and using an unsafe pointer in the new standard lib - im not convinced by a string object thats a reference to another object , it may work but would need bechmarks and what if the benchmarks were poor. (, slices are diffirent because they frequently avoid the string copy / creation cost ) . Without a more efficient string implimentation your not going to do much better than C# and Java especially in terms of memory usage and your fighting C ASCII benchmarks. I also think if BitC goes for the CLR (as seems wise) even as an "interim" than it will succeed or fail by how well it does on the CLR and it will be compared to Java , C# ,C++ and C a change of string seems an easy way to gain a lot in the PR department especially memory usage.. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
