On Fri, Sep 13, 2013 at 3:26 PM, David Jeske <[email protected]> wrote:
> On Thu, Sep 12, 2013 at 2:04 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> The more interesting challenge is to either (a) get people to use some >> form of StringReader for sequential access to strings >> > > To me this seems the saner route. > > If it meant more flexible ways to handle proper I18N, I would be happy > with a cursor-based string-reader. Here you could get a cursor from > start/end or a saved handle, and then increment/decrement the cursor > position, and save any position or range. You would not be able to > fabricate an arbitrary location like is possible with the a[i] API. > > This would prevent C-style "for (i=0;i<length;i++)" loops, but would > support a an iterator style of the same loop "for(cursor=s.start; > cursor.haschar; cursor.inc)", where inside the iterator you could save off > locations easily. > > Whether other folks would find this acceptable or not is another matter. > I dont really think its an issue .. For most operations and developers its just hidden by the API eg in C# now var str = "Abc123" var index = str.Find("c1"); var substr = str.SubString(index, 2); can become var str = "Abc123" slice substr = str.SubString("c1" , 2); And substring reads it sequentially. There is no way to do c style loops on string - you can get an array but its not a string and the encoding etc is up to you.. also how the stdlib does it internally is not relevant , mono does it mainly with unsafe to eliminate runlength checks and /or to make use of c routine which scans (Find) and copies (Substring) the string in a more efficient manner ( probably using SIMD) . Personally i think this internal code must be native as i dont think you can do Find , Substring etc anywhere near the speed you can with SIMD in all but the shortest strings . For larger strings (and the mechanism undeneath) its not an issue either, at present HtmlPage , XmlPage type classes nearly always have a System.IO.StringReader which reads the UTF8 byte[] data via encoder from native , so a stream based lower level API should not be an issue. Ben On Fri, Sep 13, 2013 at 3:26 PM, David Jeske <[email protected]> wrote: > On Thu, Sep 12, 2013 at 2:04 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> The more interesting challenge is to either (a) get people to use some >> form of StringReader for sequential access to strings >> > > To me this seems the saner route. > > If it meant more flexible ways to handle proper I18N, I would be happy > with a cursor-based string-reader. Here you could get a cursor from > start/end or a saved handle, and then increment/decrement the cursor > position, and save any position or range. You would not be able to > fabricate an arbitrary location like is possible with the a[i] API. > > This would prevent C-style "for (i=0;i<length;i++)" loops, but would > support a an iterator style of the same loop "for(cursor=s.start; > cursor.haschar; cursor.inc)", where inside the iterator you could save off > locations easily. > > Whether other folks would find this acceptable or not is another matter. > > > > _______________________________________________ > 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
