RE: [boost] static sized strings
Martin wrote:
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.
I have been writing a series of test cases (boost-sandbox/libs/test) and fixing several bugs. Have you tried these? Also, what compiler(s) are you using?
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.
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.
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.
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> strtime(str.buffer()); str.resize();
I'll add this soon. I have mainly been focusing on getting documentation and the test cases up.
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 max_size().
This is a deviation from the standard. If i > capacity() then the index will be out of the string buffer range and a buffer overrun can occur. This generates an exception to prevent the overrun. I should add this to the docs. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo
From: "Reece Dunn" <msclrhd@hotmail.com>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (2)
-
Reece Dunn -
Rob Stewart