buffered input

[Nick Sabalausky]

"Jean Crystof" <a at a.a> wrote in message 
news:iijl2t$10np$1 at digitalmars.com...
> Tomek Sowiñski Wrote:
>
>> Andrei Alexandrescu napisa³:
>>
>> > I hereby suggest we define "buffered input range of T" any range R that
>> > satisfies the following conditions:
>> >
>> > 1. R is an input range of T[]
>> >
>> > 2. R defines a primitive shiftFront(size_t n). The semantics of the
>> > primitive is that, if r.front.length >= n, then shiftFront(n) discards
>> > the first n elements in r.front. Subsequently r.front will return a
>> > slice of the remaining elements.
>> >
>> > 3. R defines a primitive appendToFront(size_t n). Semantics: adds at
>> > most n more elements from the underlying stream and makes them 
>> > available
>> > in addition to whatever was in front. For example if r.front.length was
>> > 1024, after the call r.appendToFront(512) will have r.front have length
>> > 1536 of which the first 1024 will be the old front and the rest will be
>> > newly-read elements (assuming that the stream had enough data). If n =
>> > 0, this instructs the stream to add any number of elements at its own
>> > discretion.
>>
>> I don't see a clear need for the two to be separate. Could they fold into 
>> popFront(n, m) meaning shiftFront(n); appendToFront(m) ? Nullary 
>> popFront() discards all and loads any number it pleases.
>>
>> > This is it. I like many things about this design, although I still fear
>> > some fatal flaw may be found with it.
>> >
>> > With these primitives a lot of good operating operating on buffered
>> > streams can be written efficiently. The range is allowed to reuse data
>> > in its buffers (unless that would contradict language invariants, e.g.
>> > if T is invariant), so if client code wants to stash away parts of the
>> > input, it needs to make a copy.
>>
>> Some users would benefit if they could just pass in a buffer and say 
>> "fill'er up".
>>
>> > One great thing is that buffered ranges as defined above play very well
>> > with both ranges and built-in arrays - two quintessential parts of D. I
>> > look at this and say, "this all makes sense". For example the design
>> > could be generalized to operate on some random-access range other than
>> > the built-in array, but then I'm thinking, unless some advantage comes
>> > about, why not giving T[] a little special status? Probably everyone
>> > thinks of contiguous memory when thinking "buffers", so here
>> > generalization may be excessive (albeit meaningful).
>>
>> Contiguous, yes. But I'd rather see front() exposing, say, a circular 
>> buffer so that appendToFront(n) reallocates only when n > buf.length.
>
> I find this discussion interesting. There's one idea for an application 
> I'd like to try at some point. Basically a facebook chat thingie, but with 
> richer gaming features. The expected audience will be 10 - 100K 
> simultaneous clients connecting to a single server. Not sure if DOM or SAX 
> will be better. After seeing the Tango's XML benchmarks I was convinced 
> that the implementation platform will be D1/Tango, but now it looks like 
> Phobos is also getting there, propably even outperforming Tango by a clear 
> margin.
>

I don'r mean to derail the topic, but if I were aiming for that many 
simultaneous users I wouldn't even consider using XML at all. Despite MS's, 
Java's and AJAX's infatuation with it, XML is really only appropriate in two 
situations: 1. When memory/bandwidth/speed/etc don't matter and 2. When you 
don't have a choice in the matter.