 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
 Posted: Sat Nov 11, 2006 9:04 pm Post subject: std::string bad design???? |
 |
|
<Quote Ref: http://www.cantrip.org/realworld.html?seenIEPage=1 >
The C++ Standard Library offers both good examples (iterators,
algorithms, and containers) and bad (string)
</Quote>
With my limited C++ skill, I am not able to appreciate the statement.
One does not need years to find out how useful an iterator, vector or a
std::string class is.
Can some one help me to understand why author Nathan C. Myers calls
std::string a bad class?
Am I misinterpreting something?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Denise Kleingeist
Guest
|
| Posted: Sat Nov 11, 2006 11:47 pm Post subject: Re: std::string bad design???? |
|
|
Hello!
bestbrain (AT) gmail (DOT) com wrote:
| Quote: | Can some one help me to understand why author Nathan C. Myers calls
std::string a bad class?
|
There are several things wrong with std::string:
- Its interface is "fat": there is rarely a good reason to have
that many member functions. In fact, most of the methods
could be turned into functions entirely independent of the
class and hence be applicable to other representations of
character sequences, e.g. std::vector<char>, too.
- Most of std::string's interface is designed to allow a shared
representation for identical strings, i.e. there is no
direct access to mutate individual characters nor any need
to do so. ... but then tere are also non-const_iterators
and a subscript operator returning references to chars
making it close to impossible to implement std::string
with a shared representation and even if it is possible,
definitely increase the cost of many operations.
- The std::string objects are relatively large and expensive.
Basically, it has to store at least three words (pointers
or integers) for maintenance and allocate memory for the
actual string representation. At the cost of making the
string objects yet bigger, it is possible to avoid the
memory allocation for small strings (an optimization which
seems to work well for many applications). If std::strings
were made essentially immutable, they could be smaller and
avoid memory allocations in many cases, e.g. when passing
them around by value.
Personally, I would prefer a lightweight immutable string
class plus generic string operations operating on [character]
ranges. There are already enough containers which can
be used to manipulate a sequence (e.g. std::vector<char>
or std::list<char> depending on the operations you need to
build up a string). To ease string concatenation which is a
rather common operation, a generic operator+() on stringlike
entities could be provided.
Good luck, Denise.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Ivan Vecerina
Guest
|
| Posted: Sat Nov 11, 2006 11:48 pm Post subject: Re: std::string bad design???? |
|
|
charset="iso-8859-1"
X-Clcppm-Sequence: 24204
X-Original-Date: Sat, 11 Nov 2006 17:53:22 +0100
X-Submission-Address: c++-submit (AT) netlab (DOT) cs.rpi.edu
<bestbrain (AT) gmail (DOT) com> wrote in message
news:1163254759.281952.25380 (AT) b28g2000cwb (DOT) googlegroups.com...
: <Quote Ref: http://www.cantrip.org/realworld.html?seenIEPage=1 >
: The C++ Standard Library offers both good examples (iterators,
: algorithms, and containers) and bad (string)
: </Quote>
:
: With my limited C++ skill, I am not able to appreciate the statement.
:
: One does not need years to find out how useful an iterator, vector
: or a std::string class is.
:
: Can some one help me to understand why author Nathan C. Myers calls
: std::string a bad class?
: Am I misinterpreting something?
You're not.
It is a fact that experts have identified several flaws when
looking back at the specification of std::string in C++98,
and unfortunately it is very difficult if not impossible
to change things now.
In my opinion the two main flaws are:
- Lack of a "const string", whose contents cannot be modified.
std::string was initially thought to use reference-counting
and copy-on-write. However, this prove to be excessively
difficult to implement efficiently, especially in a multi-
threaded environment. As a result, several std::string
implementations have given up on using reference-counting.
Most other languages use non-mutable strings (where one
cannot directly modify a char within the string), which are
easier to optimize (no baggage related to COW or reserved
capacity). [ Kevlin Henney once wrote a full article about
this in CUJ, if I remember correctly... ]
- Excessive number of member functions: std::string has
more members than any other standard library class. Yet it
is far from being complete or satisfactory (e.g. novices
commonly look for trim, split, toupper, etc functions found
in other libraries or languages). The STL has set a nice
precedent by separating algorithms from containers. The
same could have been done with std::string: provide
non-member functions to perform any non-fundamental
string manipulations. This would have set a precedent
allowing uniform extensibility of std::string: for example
we could add a header that provides all internationalization-
related functions, etc. And for basic uses std::string
would remain leader. Now we have a bulky class, and
a dichotomy between a set of member functions and the rest
of the world. This in turn leads many novices to think that
they need to subclass std::string to add operations that
they miss.
Actually saying that std::string is broken remains a matter
of opinion (same as for iostream+stream_buf). But I am sure
that if the first C++ standard was being (re)written today,
std::string would not be the same...
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Earl Purple
Guest
|
| Posted: Wed Nov 15, 2006 6:06 am Post subject: Re: std::string bad design???? |
|
|
Ivan Vecerina wrote:
| Quote: | You're not.
It is a fact that experts have identified several flaws when
looking back at the specification of std::string in C++98,
and unfortunately it is very difficult if not impossible
to change things now.
|
It is not possible to change std::string now but it is possibly to
create a new immutable string class.
| Quote: | In my opinion the two main flaws are:
- Lack of a "const string", whose contents cannot be modified.
std::string was initially thought to use reference-counting
and copy-on-write. However, this prove to be excessively
difficult to implement efficiently, especially in a multi-
threaded environment. As a result, several std::string
implementations have given up on using reference-counting.
|
Lack of a standard layout in my opinion is a major flaw. That means
that I can't write library function to return a std::string if the
other end is not using the same implementation of STL that I am using.
| Quote: | Most other languages use non-mutable strings (where one
cannot directly modify a char within the string), which are
easier to optimize (no baggage related to COW or reserved
capacity). [ Kevlin Henney once wrote a full article about
this in CUJ, if I remember correctly... ]
|
The language could still have one, it just wouldn't be std::string.
| Quote: | - Excessive number of member functions: std::string has
more members than any other standard library class. Yet it
is far from being complete or satisfactory (e.g. novices
commonly look for trim, split, toupper, etc functions found
in other libraries or languages). The STL has set a nice
precedent by separating algorithms from containers. The
same could have been done with std::string: provide
non-member functions to perform any non-fundamental
string manipulations. This would have set a precedent
allowing uniform extensibility of std::string: for example
we could add a header that provides all internationalization-
related functions, etc. And for basic uses std::string
would remain leader. Now we have a bulky class, and
a dichotomy between a set of member functions and the rest
of the world. This in turn leads many novices to think that
they need to subclass std::string to add operations that
they miss.
|
They miss two things, a converter to upper/lower (can be done with
std::transform) and a comparison function that is case insensitive
(could be done with an external predicate). You would expect to find
these perhaps in std::locale but they're not there.
I would like a swap between std::basic_string<E> and std::vector<E>. I
would like a proper efficient char_traits for any primitive integral
type. I would like to be able to get a writable buffer for a
std::string so you wouldn't have to fiddle around with vector<char> in
the first place.
(split that you suggest is missing, is surely just substr(), by the way
?)
back() is also a strangely missing member function. (back() looks a lot
neater than *rbegin() )
| Quote: | Actually saying that std::string is broken remains a matter
of opinion (same as for iostream+stream_buf). But I am sure
that if the first C++ standard was being (re)written today,
std::string would not be the same...
|
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
shablool
Guest
|
|
| Back to top |
|
|
Guest
|
| Posted: Mon Dec 25, 2006 9:16 pm Post subject: Re: std::string bad design???? |
|
|
loufoque wrote:
| Quote: | 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! ] |
|
| Back to top |
|
|
Mirek Fidler
Guest
|
| Posted: Tue Dec 26, 2006 5:43 am Post subject: Re: std::string bad design???? |
|
|
James Kanze wrote:
| Quote: | bestbrain (AT) gmail (DOT) com wrote:
Quote Ref: http://www.cantrip.org/realworld.html?seenIEPage=1
The C++ Standard Library offers both good examples (iterators,
algorithms, and containers) and bad (string)
/Quote
As it turns out, the
iterators and the algorithms are a lot harder to use than what
was claimed.
|
Interesting, I thought I am the only person in this group thinking so :)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Tony
Guest
|
| Posted: Tue Dec 26, 2006 6:54 pm Post subject: Re: std::string bad design???? |
|
|
<lancediduck (AT) nyc (DOT) rr.com> wrote in message
| Quote: | There are many reasons why you would may want to inherit from
std::string
|
Yes, I have at least one class derived from a general string class that
makes it easy to parse out ini-file tokens. It's a class not designed for
the general case of tokenizing though.
| Quote: | For example many programmers design function signatures to take
std::string,
|
I avoid using std::string in function signatures. I use:
typedef const char* ccstar;
That avoids pulling in the string header all over the place and also
makes it more "natural" to pass string literals:
void my_func(ccstar arg):
// call my_func()
//
my_func("passing in this string literal");
So, I consider string classes to be specialized composed types
rather than something I'd want an entire code base (header files
mostly) to be dependent on. To me, the primitive thing to be in
function signatures is ccstar. If somehow strings actually WERE
built-in types, I would probably pass them as function arguments.
Or at least if std::string wasn't such a big pill to swallow (but
then again, I don't even pass my own string class around). If
there is a "string-thing" data member in a class, it very well may
be that it is a good candidate for wrapping via an interface (ABC).
Tony
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Mathias Gaunard
Guest
|
| Posted: Wed Dec 27, 2006 10:10 am Post subject: Re: std::string bad design???? |
|
|
Tony wrote:
| Quote: | I avoid using std::string in function signatures. I use:
typedef const char* ccstar;
That avoids pulling in the string header all over the place and also
makes it more "natural" to pass string literals:
void my_func(ccstar arg):
// call my_func()
//
my_func("passing in this string literal");
|
How is it more natural than
void my_func(const std::string& arg);
my_func("passing in this string literal");
?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Tony
Guest
|
| Posted: Wed Dec 27, 2006 11:15 pm Post subject: Re: std::string bad design???? |
|
|
"Mathias Gaunard" <loufoque (AT) remove (DOT) gmail.com> wrote in message
news:4591d890$0$13749$426a34cc (AT) news (DOT) free.fr...
| Quote: | Tony wrote:
I avoid using std::string in function signatures. I use:
typedef const char* ccstar;
That avoids pulling in the string header all over the place and also
makes it more "natural" to pass string literals:
void my_func(ccstar arg):
// call my_func()
//
my_func("passing in this string literal");
How is it more natural than
void my_func(const std::string& arg);
my_func("passing in this string literal");
?
|
Because you have to convert the string literal to a std::string
first in your example while it isn't necessary for my example.
(I don't know that a string literal will be auto-converted to a
std::string and I don't want to know that (!) because that doesn't
seem "natural" or intuitive either, though the reverse case of
passing a string and relying on a ccstar conversion operator
does seem intuitive/natural). I wouldn't expect your example
to work. Apparently you're implying that it does.
So this:
menu.Add("File");
menu.Add("Edit");
menu.Add("View");
rather than:
std::string s("File");
menu.Add(s);
s = "Edit";
menu.Add(s);
s = "View";
menu.Add(s);
(I'm not suggesting the Menu class design implied above is good.
It's just an example.)
Tony
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Thu Dec 28, 2006 2:49 am Post subject: Re: std::string bad design???? |
|
|
In article <1167221428.024803.299340 (AT) 73g2000cwn (DOT) googlegroups.com>, Mirek
Fidler <cxl (AT) ntllib (DOT) org> writes
| Quote: |
Mathias Gaunard wrote:
Tony wrote:
I avoid using std::string in function signatures. I use:
typedef const char* ccstar;
That avoids pulling in the string header all over the place and also
makes it more "natural" to pass string literals:
How is it more natural than
void my_func(const std::string& arg);
my_func("passing in this string literal");
Well, I am not quite sure about Tony's reasons, but I am using const
char * instead of string quite often as well, everywhere where it is
more likely to be called with literal.
The reason is simple - avoiding string constructor overhead.
Mirek
Then I hope you overload your functions so that they can take strings as |
well. Forcing users to use pointers to arrays of char is not a good way
to go (the standard library is riddled with that problem and it is being
corrected for the next Standard.)
The problems associated with extracting an array of char from an
existing string are far higher.
It looks like premature optimisation to me. Suitable low level overloads
can be added if they prove necessary.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Thu Dec 28, 2006 2:57 am Post subject: Re: std::string bad design???? |
|
|
In article <rcukh.11973$hI.5631 (AT) newssvr11 (DOT) news.prodigy.net>, Tony
<rdnewsNOSPAM2006 (AT) sbcglobal (DOT) net> writes
| Quote: |
Because you have to convert the string literal to a std::string
first in your example while it isn't necessary for my example.
(I don't know that a string literal will be auto-converted to a
std::string
It is |
| Quote: | and I don't want to know that (!) because that doesn't
seem "natural" or intuitive either,
Then I think you need to re-educate your intuition. How do you think |
initialisers work for std::string objects?
| Quote: | though the reverse case of
passing a string and relying on a ccstar conversion operator
does seem intuitive/natural).
Yet you cannot do that. There is no automatic conversion from |
std::string to array of char. It can be done explicitly by using c_str(0
member but that creates a temporary which can disappear at the most
inconvenient moment.
| Quote: | I wouldn't expect your example
to work. Apparently you're implying that it does.
So this:
menu.Add("File");
menu.Add("Edit");
menu.Add("View");
rather than:
|
Cannot imagine why you would want to do that even if the menu was stored
as a vector of std::string (which seems the most obvious solution to me.
| Quote: |
std::string s("File");
menu.Add(s);
s = "Edit";
menu.Add(s);
s = "View";
menu.Add(s);
(I'm not suggesting the Menu class design implied above is good.
It's just an example.)
|
Yes I can see that, and IMHO a pretty poor one. I would normally want to
arrange to read my menu from a configuration file. The cost of the
string ctor in the above is (or should be) minuscule.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Bo Persson
Guest
|
| Posted: Thu Dec 28, 2006 2:57 am Post subject: Re: std::string bad design???? |
|
|
Tony wrote:
| Quote: | "Mathias Gaunard" <loufoque (AT) remove (DOT) gmail.com> wrote in message
news:4591d890$0$13749$426a34cc (AT) news (DOT) free.fr...
Tony wrote:
I avoid using std::string in function signatures. I use:
typedef const char* ccstar;
That avoids pulling in the string header all over the place and
also makes it more "natural" to pass string literals:
void my_func(ccstar arg):
// call my_func()
//
my_func("passing in this string literal");
How is it more natural than
void my_func(const std::string& arg);
my_func("passing in this string literal");
?
Because you have to convert the string literal to a std::string
first in your example while it isn't necessary for my example.
(I don't know that a string literal will be auto-converted to a
std::string and I don't want to know that (!) because that doesn't
seem "natural" or intuitive either,
|
You mean that constructing a string from a string literal is not natural??
:-)
| Quote: | though the reverse case of
passing a string and relying on a ccstar conversion operator
does seem intuitive/natural).
|
IMO 'const char*' is one of the most unnatural things in C++. It is not
anything like 'const int*', which is very confusing!
| Quote: | I wouldn't expect your example
to work. Apparently you're implying that it does.
|
Of course!
Bo Persson
| Quote: |
So this:
menu.Add("File");
menu.Add("Edit");
menu.Add("View");
rather than:
std::string s("File");
menu.Add(s);
s = "Edit";
menu.Add(s);
s = "View";
menu.Add(s);
|
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Mirek Fidler
Guest
|
| Posted: Thu Dec 28, 2006 5:58 am Post subject: Re: std::string bad design???? |
|
|
Francis Glassborow wrote:
| Quote: | In article <1167221428.024803.299340 (AT) 73g2000cwn (DOT) googlegroups.com>, Mirek
Fidler <cxl (AT) ntllib (DOT) org> writes
Mathias Gaunard wrote:
Tony wrote:
I avoid using std::string in function signatures. I use:
typedef const char* ccstar;
That avoids pulling in the string header all over the place and also
makes it more "natural" to pass string literals:
How is it more natural than
void my_func(const std::string& arg);
my_func("passing in this string literal");
Well, I am not quite sure about Tony's reasons, but I am using const
char * instead of string quite often as well, everywhere where it is
more likely to be called with literal.
The reason is simple - avoiding string constructor overhead.
Mirek
The problems associated with extracting an array of char from an
existing string are far higher.
|
Speaking about std::string, you are correct, but I am not using
std::string either and my string class has trivial cast to const char *
(BTW, I consider that a basic requirement for any C++ string class and
I am still not sure why std::string fails to provide one).
Of course, sometimes this can lead to ineffective string->const char
*->string conversion, if speed is concern, I always provide both
interfaces.
| Quote: | It looks like premature optimisation to me. Suitable low level overloads
can be added if they prove necessary.
|
Perhaps you never seen the disassembly.... Passing char literals to
functions defined with (const std::string&) signature is extremely
awful, temporary has to be created, exception cleanup provided.... You
might not care about the speed, but the code bloat is extreme.
Mirek
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Mathias Gaunard
Guest
|
| Posted: Thu Dec 28, 2006 10:10 am Post subject: Re: std::string bad design???? |
|
|
Tony wrote:
| Quote: | Because you have to convert the string literal to a std::string
first in your example while it isn't necessary for my example.
(I don't know that a string literal will be auto-converted to a
std::string
|
It is because std::string::std::string(const char* s) is an implicit
constructor (the default).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
