Re: pseudo-specs for a String class

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?

Adrian

2008/8/31 Kinkie <gkinkie_at_gmail.com>:
>> +1. With a view of re-using MemBuf in the final product. Starting from
>> KinkieBuf. (Joke, me taking a dig at the content filterers again).
>
> I've gotten a bit forward, now I'm a bit at a loss about where to go next.
>
> Current interface:
>
> class KBuf {
> KBuf();
> KBuf(const KBuf &S);
> KBuf(const char *S, u_int32_t Ssize);
> KBuf(const char *S); //null-terminated
> ~KBuf();
> bool isNull();
> KBuf& operator = (KBuf &S);
> KBuf& operator = (char const *S, u_int32_t Ssize);
> KBuf& operator = (char const *S); //null-terminated
> KBuf& append(KBuf &S);
> KBuf& append(const char * S, u_int32_t Slen);
> KBuf& append(const char * S); //null-terminated
> KBuf& append(const char c); //To be removed?
> KBuf& appendf(const char *fmt, ...); //to be copied over from membuf
> std::ostream & print (std::ostream &os); // for operator<<
> void dump(ostream &os); //dump debugging info
> const int operator [] (int pos);
> int cmp(KBuf &S); //strcmp()
> bool operator == (const KBuf & S);
> bool operator <(KBuf &S);
> bool operator >(KBuf &S);
> void truncate(u_int32_t to_size);
> KBuf consume(u_int32_t howmuch); //from MemBuf
> void terminate(void); //null-terminate
> static ostream & stats(ostream &os);
> char *exportCopy(void);
> char *exportRefIKnowWhatImDoing(void);
> KBuf nextToken(const char *delim); //strtok()
> KBuf substr(u_int32_t from, u_int32_t to);
> u_int32_t index(char c);
> u_int32_t rindex(char c);
> }
>
> on x86, sizeof(KBuf)=16
>
> Now I'm a bit at a loss as to how to best integrate with iostream.
> There's basically three possibilities:
>
> 1. KBuf kb; kb.append(stringstream &)
> cheapest implementation, but each of those requires two to three
> copies of the contents
> 2. Kbuf kb; stringstream ss=kb->stream(); ss<< (blah).
> this seems to be the "official" way of extending iostreams;
> performed by making KBuf a subclass of stringbuf.
> extends sizeof(KBuf) by 32 bytes, and many of its calls need to
> housekeep two states.
> 3. Kbuf kb; stringstream ss=kb->stream(); ss << (blah)
> performed by using an adapter class. The coding effort starts to
> be quite noticeable, as keeping the stringbuf and the KBuf in sync is
> not trivial.
> 4 Kbuf kb<<(blah). requires kbuf to be a subclass of an ostream.
> there's a significant coding effort, AND baloons the size of KBuf
> to 156 bytes.
>
> What's your take on how to better address this?
>
>
> --
> /kinkie
>
>
Received on Sun Aug 31 2008 - 16:00:31 MDT