Am Wed, 08 Feb 2012 00:29:55 -0800 schrieb Jonathan M Davis <[email protected]>:
> On Wednesday, February 08, 2012 09:12:57 Johannes Pfau wrote: > > Using ranges of dchar directly can be horribly inefficient in some > > cases, you'll need at least some kind off buffered dchar range. Some > > std.json replacement code tried to use only dchar ranges and had to > > reassemble strings character by character using Appender. That sucks > > especially if you're only interested in a small part of the data and > > don't care about the rest. > > So for pull/sax parsers: Use buffering, return strings(better: > > w/d/char[]) as slices to that buffer. If the user needs to keep a > > string, he can still copy it. (String decoding should also be done > > on-demand only). > > That's why you accept ranges of dchar but specialize the code for > strings. Then you can use any dchar range with it that you want but > can get the extra efficiency of using strings if you want to do that. > > - Jonathan M Davis But spezializing for strings is not enough, you could stream XML over the network and want to parse it on the fly (think of XMPP/Jabber). Or you could read huge xml files which you do not want to load completely into ram. Data is read into buffers anyway, so the parser should be able to deal with that. (although a buffer of w/d/chars could be considered to be a string, but then the parser would need to handle incomplete input)
