Re: std::string bad design????
loufoque wrote:
shablool wrote:
See:
http://strinx.sourceforge.net/strinx.html#appendix-b-what-is-wrong-with-the-standard-string
From the five points this gives, only one (the first) is pertinent. And
still, monolithic objects are more appreciated than free functions by
some people. This is still a debate.
Inheriting from a string makes no sense to begin with. So the fact that
you can't derive from a string is irrelevant.
The standard doesn't force anything related to small string optimization
or COW. A lot of implementations use one or both of those. (actually I
know none that use both)
And this document says COW is essential for passing strings by value,
but you shouldn't pass something by value unless you want it to be
copied anyway. We have references in C++. That point is pure nonsense.
Finally exceptions are part of the C++ language and are the idiomatic
way to report errors in those cases.
The fact that it is not allowed to customize the way errors are handled
in std::string is not a flaw at all. That doesn't mean, though, that it
would be totally useless. It may make sense in some very specific
application where reallocating a string has high chances of failure. But
such an application probably doesn't want to use any standard containers
at all anyway.
I think the real problems are different:
- you cannot choose the data structure used. Being able to choose
between vector, deque, rope or other user-defined alternatives could be
handy. Being able to choose whether to enable COW or not could be
interesting, but that really looks like it should be implementation
dependent.
- the interface is not as good as it could be. Some things need to be
removed, others need to be added. I actually think it is better to have
them as member functions and not free functions because in some cases
they may be more efficient than algorithms working on iterators.
(especially when working with unicode)
- it has no support for unicode and the current design of char_traits,
locales, etc. does not allow for a good unicode string. Actually, even
among the existing unicode strings in other libraries, none is really good.
I think Unicode is the way to represent text and should be what a string
type uses.
It seems a lot of people are asking for toupper/tolower. Such things
shouldn't be added carelessly, this is actually a rather complicated topic.
There are many reasons why you would may want to inherit from
std::string
For example many programmers design function signatures to take
std::string, but users of those functions want more type saftey than
std::string provides:
To wit , a design of a particular system may look like
/**
@function setaccountname
@param accountname -- desired new accountname
@precondition accountname cannot be more than 30 chars long, no
whitespace,not empty
**/
void setaccountname(std::string const&accountname);
You don't want to keep these rules in your head, so instead of
memorizing them, you use your compiler to keep track for you
class AccountName:public std::string
{
static void check(std::string const& _t ){
if( _t.size()>30 || _t.find_first_of(" \t\n")!=npos ||
_t.empty())
raise_error();
}
public:
AccountName(const char*_a):std::string(_a){
check(*this);
}
//other constructors, and modifiers you want
void operator+=(std::string const&_r);
{
std::string _tmp(*this);
_tmp+=_r;
check(_tmp);
swap(*this,_tmp);
}
private:
//hide problem modifiers that you really don't need for AccountName
void replace();
void assign();
void append();
};
Now to use
void foo(){
AccountName an("JohnDoe");
setaccountname(an);//implicit conversion
AccountName an1("John Doe");//oops!!!
//an.assign(" INvalid); //Nope
}
There are better ways to do this, and I am not a fan of implicit
conversions in any case. But for small and medium size projects this
fits the bill -- easy to implement, easy to use, solves more problems
than it creates.
I think most of the problem with std::string is people expectations of
it, rather than the design itself. std::string was largely designed as
a *utility* for character sequences. But most developers want to use
string as if it were a built - in type, just like virtually all other
languages. And when you start using string like a built in type, all
sort of complaints arise. But as a utility it seems to do the job fine.
But would you try use a utility as a way to pass values? Or in module
interfaces? Certianly not. Perhaps C++ needs a string class that is
suitable for this use: std::string hardly fits this bill.
On my projects I acually use something very similiar to Alexandrescus
flexstring, but I add in exception policies. After a while it is hard
to tell just WHICH string threw an error, and with exception stack
tracing a la Java, finding the problem can be torturous. Adding more
info to the exception helps dramatically. (i.e. catch std;:exception,
then do a typeid, and print)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]