Boost logo

Boost :

From: Martin (adrianm_at_[hidden])
Date: 2004-06-03 03:37:24

I have tested the sandbox version of the static sized strings. It works fine
but there are a few inconveniences that I want to point out.

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"));

Don't really have a good solution but maybe the base class could use an
external buffer with constructors from char* and std::string.
class char_string {
  const char* const extbuf;
  size_t len;
  char_string() : extbuf(NULL) {} // not used since derived implements its own
  char_string(const char* c) : extbuf(c), len(strlen(c)) {}
  char_string(const std::string& str) : extbuf(str.c_str()), len(str.length())
  ... // virtual basic_string interface

Don't know how to handle non-const char[].

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.

3. resize
Still missing a method to update the length to reflect the current string
length. I think a resize without arguments would be a good solution.

boost::fixed_string str<10>

4. operator[]
I don't have the standard basic_string interface available but I am pretty
sure that operator[] doesn't throw an exception if the argument is outside

I also looked at the alternative fixed_string implemenatation but since that
version doesn't have full std::string interface I didn't test it. I am not
sure I like the lazy length calculation for two reasons.
- In my view, strlen is normally a "cheap" operation comparable to a function
call. If the lazy evaluation prevents a function from being inlined, the
benefit is lost.
- It is tricky to detect when the length is invalid. With the current
implementation, I can't say if the length is valid or not after "str[4] = str
[5]" since that depends on the order of evaluation of "str[4]" and "str[5]".

Boost list run by bdawes at, gregod at, cpdaniel at, john at