> On Sun, Aug 31, 2008 at 6:00 PM, Adrian Chadd <[EMAIL PROTECTED]> > wrote: >> Do you really want to provide a 'consume' interface for a low-level >> representation of memory? >> >> I think trying to replace MemBuf with this new buffer is a bit silly. >> Sure, use it -in- MemBuf, along with all the other places that buffers >> are used. >> >> What about strtok()? Why would you want to tokenise data? > > I'd like it to be used > - everywhere MemBuf is used > - everywhere a char* is used for a string > - strtok, strchr, strstr, etc to be used in the HTTP parser > > All of the above with increased efficiency both in terms callers' LOC > and performance. > > > Given: > KBuf src="GET http://some.url/ HTTP/1.0\r\nHost: some.url\r\n\r\n" > KBuf out; > > The following are expected to be equivalent: > ==== > u_int32_t pos=src.index('\n'); > out=src.substr(0,pos); > src=src.substr(pos,-1); //to end-of-string > ==== > out=src.consume(src.index('\n')); > ==== > out=src.nextToken('\n'); > ==== >
Nice, that should help the parser re-work quite a bit. Though make sure the nextToken only applies to the src KBuf object. Our biggest existing problems with strtok() is its internal 'static global' design. Amos
