Thank you Daniel and Bart for the reply!
> In C++, the std::string class does the managing of memory itself under
> the hood.
> The usage pattern of a C++ std::string looks more like Delphi's
> AnsiString than like C-style char* strings.
So does it mean string objects get destroyed automatically when they
go out of scope? I seldom see people delete[] someString in their
program. Is this the reason? There is no reference counting/garbage
collection as in Java?
>
>
>
>
> > I'm compiling using gcc 4.0.1 on Mac OS X, but I am trying to stick
> > to STL and none of the platform-specific facilities.
>
> > First, in C++.. I have this program:
>
> > #include <iostream>
> > #include <string>
>
> > std::string giveMeXyz()
> > {
> > std::string res;
> > res = std::string("Here is Xyz");
> > return res;
> > }
>
> > int main (int argc, char * const argv[])
> > {
> > std::string abc("Abcdefg"), xyz;
>
> > xyz = giveMeXyz() ;
> > std::cout << abc << std::endl;
> > std::cout << xyz << std::endl;
>
> > return 0;
> > }
>
> > This program runs well, but I don't know if there are any memory
> > leaks/unfreed objects.
>
> I can tell you, there are none.
> The only memory/objects that you need to manage yourself (unless you
> explicitly delegate the management) are those that are allocated with
> new, new[] or *alloc().
> As you don't use any of them directly in your program, you don't need to
> worry about cleaning up.
>
> The STL cl***** are well-behaved, in the sense that whatever resources
> they reserve during their lifetime, they will also take care to return
> those resources.
> > So my questions are:
>
> > (1) During compile time, this line
>
> > std::string abc("Abcdefg"), xyz;
>
> > Allocates two strings for two strings already, so I don't need to
> > instantiate another string?
>
> This line creates two std::string objects.
> One of them will, after construction, manage a buffer containing at
> least the 7 characters 'A' 'b' 'c' 'd' 'e' 'f' 'g'.
> The other will probably not manage any buffer yet, or it might manage an
> empty buffer. The difference will not be (easily) observable.
>
> If, at a later time, you assign new contents to one of those std::string
> objects, it is the responsibility of that object to make sure its
> buffer can hold the new contents.
So this code will instantiate a string, is this right?
{
std::string a;
}
How about if I do this?
{
std::string moo; // line 1
moo = std::string("Foo"); // line 2
moo = std::string("Bar"); // line 3
moo = std::string("Mer"); // line 4
}
By the time line 1 is done, a string "moo" will have been
instantiated.
How about when line 2 is executed? so it instantiate another string ..
(*)
(*) contains a buffer "Foo", then it gets copied into moo. How about
(*) itself ? Is it discarded, or... the system now has two copies of
"Foo" ? If this is the case, then the newly-instantiated string (right
hand side in line 2) is now unreferenced? Now if we execute line 3,
4... then.. is it true that more and more strings get unreferenced?
Because the above kind-of looks like malloc() in C... and if you keep
malloc()ing strings but lost track of the pointers, then they are gone/
leaked .. Sorrry I know I should be thinking the C++ way =P...
But say, now this time is some arbitrary class that I'd like to
instantiate (a bit off-topic, but I would really like to know.. sorry!
{
me::BarFoo myYoyo; // line 1
myYoyo = me::BarFoo(param); // line 2
myYoyo = me::BarFoo(1,2); // line 3
myYoyo = me::BarFoo("AnotherOverloadedConstructor"); // line 4
}
Would the above code generate leaked objects? What is a proper way to
get around this? If I was to write this "BarFoo" class, how should I
take care of the assignment = operator to avoid leaked objects?
> Here is the equivalent to your function in C++:
>
> void keepAskingUntilEnd()
> {
> std::string userInput; // ..... (*****)
> std::vector<std::string> someContainer;
> //or: std::list<std::string> someContainer;
>
> do {
> std::cin >> userInput;
> someContainer.push_back(userInput);
> } while (userInput != "END");}
>
> /* No explicit delete: someContainer will clean up all the strings it
> contains automatically */
>
> > I'm hoping to get some way to
> > explicitly "instantiate" a new string object and then either add it to
> > a list..linked-list...etc. When I can overcome this basic issue, I'm
> > hoping to use it on UnicodeString::UnicodeString of ICU.
>
> > ... Or should I just use char* to store the buffer instead?
>
> If you are fond of the nightmares that go with debugging memory leaks
> and/or corruption, go ahead. ;-)
Would it be the same if was to use any arbitrary class rather than
std::string in the line (****) ? Or would I have to go through manual
instantiating new , delete[]... ?
I'm going to try more coding tonight =)
Thanks a million!
|
