std.xml and Adam D Ruppe's dom module

Robert Jacques sandford at jhu.edu
Wed Feb 8 18:49:48 PST 2012


On Wed, 08 Feb 2012 02:12:57 -0600, Johannes Pfau <nospam at example.com> wrote:
> Am Tue, 07 Feb 2012 20:44:08 -0500
> schrieb "Jonathan M Davis" <jmdavisProg at gmx.com>:
>> On Tuesday, February 07, 2012 00:56:40 Adam D. Ruppe wrote:
>> > On Monday, 6 February 2012 at 23:47:08 UTC, Jonathan M Davis
[snip]
>
> 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).

Speaking as the one proposing said Json replacement, I'd like to point out that JSON strings != UTF strings: manual conversion is required some of the time. And I use appender as a dynamic buffer in exactly the manner you suggest. There's even an option to use a string cache to minimize total memory usage. (Hmm... that functionality should probably be re-factored out and made into its own utility) That said, I do end up doing a bunch of useless encodes and decodes, so I'm going to special case those away and add slicing support for strings. wstrings and dstring will still need to be converted as currently Json values only accept strings and therefore also Json tokens only support strings. As a potential user of the sax/pull interface would you prefer the extra clutter of special side channels for zero-copy wstrings and dstrings?


More information about the Digitalmars-d mailing list