Re: [boost] Re: static sized strings

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-14 12:19:54

From: "Reece Dunn" <msclrhd_at_[hidden]>
> Rob Stewart wrote:
> >From: "Reece Dunn" <msclrhd_at_[hidden]>
> > > Rob Stewart wrote:
> > > >From: John Nagle > Reece Dunn wrote:
> 
> I have revised my initial idea of supporting both null-terminated and 
> non-terminated string buffers in response that (a) boost::array< char, N > 
> is a good candidate for hte latter, and (b) adding a boolean template 
> parameter to select null termination and the associated code made the logic 
> too complex.

Ah, I didn't realize that you did that.

> >You're right that using boost::array doesn't offer any string
> >facilities.  Perhaps what we need is a string library that uses
> >all namespace scope functions and type generators to generalize
> >the notion of a string (this is not unlike Thorsten's
> >CollectionTraits library).  Then, a boost::array<char,N>, a
> >std::string, even a C string can be treated generically as a
> >string.  With such a facility, boost::array would work just fine
> >for the file signature example and char_string would be relieved
> >from needing to handle the "no terminator" case.
> 
> Doesn't the string algorithms library do just that?

I don't know, does it?

> > > [2] How do you deal with wide-character strings? My update generalizes 
> >to
> > > support char and wchar_t based buffers, but with a virtual base class, 
> >you
> > > are limited to char buffers.
> >
> >That's true only if the character type is encoded in the base
> >class.  Why would it be?
> 
> You need to know the character type you are operating on in the base class. 
> This is the basic idea that John Nagle's approach takes:
> 
>    class char_string_base
>    {
>       public:
>          virtual std::size_t length() const;
>          virtual const char * c_str() const;
>          virtual void copy( const char * );
>    };

It depends upon the purpose of the base class.  I was thinking
more along the lines of a hook permitting them to be stored
heterogeneously, but a little while after I sent my last reply,
it occurred to me that there would be no good way to regain the
derived type to do anything with the object.  Thus, John's
approach is the only one that would be useful.

> But I agree with John's comments that it may be necessary to have a 
> wchar_string_base to support wide characters.

Definitely.

> > > [3] One of the reasons for having a virtual class is to supply custom 
> >string
> > > operations, e.g. using Windows-specific string functions instead of the
> > > standard library ones. This can also be solved with a policy template 
> >like
> > > that found in basic_string. My current version uses this approach, 
> >improving
> > > interoperability with basic_strings.
> >
> >You can certainly design an ABC with many pure virtual functions
> >that the derived types implement, but that was never the intent
> >of the base class idea.

Actually, it was his idea.

> >Your policy approach will permit a lot of custimization, but
> >perhaps the better approach is to externalize all operations.
> 
> Can you expand on what you mean by externalize.

Just the idea that you would use size(s), append(s, t),
etc. rather than mfs.  That approach means that s and t can be of
many different types unified under a single syntactic umbrella.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;