Re: [boost] static sized strings

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-06-03 11:50:09

From: "Reece Dunn" <msclrhd_at_[hidden]>
> Martin wrote:
> 
> >1. The abstract base class.
> >---------------------------
> >Having an ABC to handle fixed strings of various lengths is a good idea but 
> >it
> >is not very practical. I understand that the main purpose is to allow fixed
> >strings to be passed to functions without using templates.
> >
> >int countwords(const boost::char_string & str);
> >
> >unfortunatly the ABC makes it difficult to pass anything but fixed strings. 
> >If
> >you want to pass a string literal, a character array or a std::string you 
> >must
> >create a temporary fixed_string<>.
> >
> >countwords(boost::fixed_string<20>("The quick brown fox"));
> 
> This is an unfortunate side-affect of using the ABC technique that affects 
> John's implementation as well. Your proposed solution looks interesting, but 
> I don't know how practical it will be for the string manipulation operations 
> (w.r.t. buffer safety).
> 
> Rob proposed a "make_string" function, which would simplify this a little.

There's nothing to be done here, except to forcibly create an
appropriate derived instance of char_string when calling such
functions.  It doesn't have to be computed manually, though, as
Reece has alluded to.  The make_string() I suggested would cause
the compiler to deduce N for fixed_string<N>.  Unfortunately,
that object would have to be returned by value or via a smart
pointer.  Either way, it would contain a copy of the original
string.

To do more would require that the strings be kept in the free
store.  Then, the base class would contain a pointer to its
implementation object which would be a fixed_string<N>.  Thus,
you could add a parameterized ctor to char_string that could
instantiate the appropriate fixed_string<N> against that pointer.
That's not so terrible, but it doesn't leave fixed_string with
much benefit over std::string!

Martin's suggestion of having char_string maintain a possible
null pointer would entail every function having to determine
whether to forward to the derived class or interact with the
buffer referenced by the pointer.  That would add quite a bit of
overhead to each operation and certainly complicate matters.

> >2. Substrings
> >-------------
> >One of the applications I can see for fixed_string is when you want to 
> >avoid
> >dynamic allocation but still want to use the std::string interface and
> >algorithms. In that perspective it seems strange that substr returns a
> >std::string instead of a fixed_string.

Agreed.

> This is related to the above problem. You cannot create an instance of 
> boost::char_string, etc. and as such cannot implement substr in the usual 
> way (this is the proplem I was having with operator+). The solution would be 
> to defione an alternate substr function in fixed_string, but this would not 
> solve the problem for boost::char_string, etc.
> 
> The alternative would be to use a ranged string (pointer to the fixed_string 
> buffer and length), but the problem with this is null-termination.
> 
> I do not see an easy way around this without removing the ABC design, since 
> it is not possible to do fixed_string< length() > or something similar.

Couldn't substr() be a pure virtual function in char_string that
deferred to the derived class to create a copy of itself?  The
derived class can just create a duplicate of itself, including
the current capacity.  That capacity is guarranteed to be
sufficient to hold any substring requested.

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