problem with string::resize

[Roland Pibinger]

In this example reserve() is indeed unnecessary, but I actually use
std::string to store a rather large binary data with predetermined size,
I think it would be a good idea to give std::string a hint to avoid
unnecessary reallocating.

This is not always the case, unfortunately. Consider:

void foo (const string& str) {
string buf;
buf.reserve (str.size() + 1);
buf.assign (str);
buf.append (1, 'X');
// ...
}

The above code is totally inefficient when string uses a ref-counted
implementation. The reserved space is deallocated immediately by
assign() because of ref-counting; append() possibly triggers a
reallocation again.
If you heavily use string you must either program against your current
std::string implementation and hope that your library vendor does not
change it (Microsoft did) or alternatively use another (your own)
string class. In the latter case it's probably better to split the
string functionality into more than one class (see String and
StringBuilder in Java and C#).

Best wishes,
Roland Pibinger

 

[Kai-Uwe Bux]

What about strings that use a reference counted implementation,

those can be done with contiguous memory.

and then there is SGI's "rope" class.

That does not implement the interface of std::string, if I recall correctly.
At least, things like capacity() are faked and will lie to yo.

I personally have a string class that uses
a deque as its representation (the interface is still incomplete though.)

A tricky part is the data() member function. If you need to implement that,
you may as well go for a vector based implementation in the first place.


Best

Kai-Uwe Bux

 

[Larry I Smith]

Larry I Smith wrote in message ...

Not if you give it something else: foo.resize( 10, ' ' );

Yes, that's true, but we weren't talking about the 2 arg
resize() were we?

[snip]
Regards,
Larry

 

[Daniel T.]

those can be done with contiguous memory.

As I said, however things can get tricky if two different strings want
the rep to be two different sizes... I guess that's why resize to
something smaller won't always work...

That does not implement the interface of std::string, if I recall correctly.
At least, things like capacity() are faked and will lie to yo.

Well, that's the question isn't it, how would you as a user of the class
know?

A tricky part is the data() member function. If you need to implement that,
you may as well go for a vector based implementation in the first place.

And by extension the "c_str()" member-function. They can both be
implemented by temporarily creating a block of memory, and filling it
from the representation. That block can be deleted as soon as a
non-const member-function is called. Is this wasteful and slow? Yes, for
large strings it is, but AFAIC, "data()" and "c_str()" mainly exist so
that 'c' code can be called with a string from 'c++'.

So, the real point is to not need to call 'c_str()' or 'data()' on large
strings... I believe the fstream library is the only standard C++ code
that *can't* use strings...