String and std::string
Robert Collins
rbcollins@cygwin.com
Fri Mar 21 12:55:00 GMT 2003
On Fri, 2003-03-21 at 23:12, Alex Tibbles wrote:
> <snip>
>
> > I don't care whether you use std::string, or
> > String++ for any new code,
> > as long as:
> > 1) You don't leak memory (std::string will leak if
> > you use c_str())
> > IIRC.
>
> I've been unable to confirm this. I tried the attached
> program (compiled with gcc -lstdc++ stringleak.cpp)
> and got the following results from top:
Well, your test is flawed for the behaviour I was referring to. A new
one is below.
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM
> 648 alex 14 0 556 556 416 R 56.2 0.2
>
>
> TIME COMMAND
> 3:02 a.out
>
> Am I correct in concluding that std::string::c_str()
> does not leak? I'm interested as I use c_str() a fair
> amount for interfacing C++ with C (I believe that was
> what it was designed for, but I'm only guessing).
>
> ______________________________________________________________________
>
> #include <string>
> #include <iostream>
>
> int main()
> {
> std::string bleg("bleg");
> while (true)
> {
> std::cout << bleg.c_str();
> }
>
> return 0;
> }
the above won't leak, because c_str() returns the internal buffer -
which isn't being altered.
this may well. Look in the g++ library for freeze() (again, IIRC). The
thing I saw when I was reading the source, was that the internal buffer
was not delete[]'d once it was handed out via c_str(). That was with the
libstc++ for gcc 2.95 as well. I've just checked the g++ 3
implementation, and it's different to what I recall from before...
#include <string>
#include <iostream>
int main ()
{
while (true)
{
std::string foo("bar");
foo.append("asdf");
char const *leakingpointer = foo.c_str();
}
return 0;
}
--
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20030321/1bd34583/attachment.sig>
More information about the Cygwin-apps
mailing list