basic question about returning strings / char arrays

D

darren

Hi everybody, have a quick look at this code:

=====
=====

int main(void) {

string msg;
makeString(msg);
cout << "back in main, result = " << msg << endl;
return EXIT_SUCCESS;
}

void makeString(string& message){
char theMessage[25] = "Here is a char array";
message = theMessage;
cout << "insdie the makeString func,theMesage = '" << message <<
endl;
}

=====
=====

I would like to write functions that return strings that i can simply
assign to a string (or char*) from my calling function. The above
code achieves the result i want, but it looks a bit strange to me (I
have a java background). I would prefer the makeString function to
return the string, instead of adjusting a reference to a string that
is passed to it. I would rather it not take a variable at all.

The problem i have found is that making the string in the makeString()
function, then returning it does not work because the stackframe for
that function is destroyed when the function ends, so referencing a
tring variable in there makes no sense. I could make a string on the
heap and return a pointer to it, but then do i have manage freeing up
space for that string when i'm done using it in the calling mfunction?
this seems like a lot of extra work.

thank you for any advice.
 
M

Martin York

The problem i have found is that making the string in the makeString()
function, then returning it does not work because the stackframe for
that function is destroyed when the function ends, so referencing a
tring variable in there makes no sense.

If you return an object that is constructed in a function it is copied
out of the function using the copy constructor so everything should
work as expected.


std::string data = getString();

std::string getString()
{
std::string result("Plop");

// The result object is copied out of the function.
return result;
}

If the result had been returned by reference then you would encounter
problems.
 
D

darren

If you return an object that is constructed in a function it is copied
out of the function using the copy constructor so everything should
work as expected.

std::string data = getString();

std::string getString()
{
std::string result("Plop");

// The result object is copied out of the function.
return result;

}

If the result had been returned by reference then you would encounter
problems.

cool, thanks for the helpful info Martin. I didn't know that
returning an object makes a copy of the object to pass back. What
would happen if you returned a reference to an object? If it
referenced something local, would the reference but null since that
stackframe is destroyed?

Also, say i had a statement like this:
char* myCString = "a string"
string myCppString = "another string"

I'm assuming that these string literals are stored on the heap? If so,
do i need to explicitly manage that memory? I thought I read that C++
handles those types of object automatically, but i"m not sure.

Victor: as for why its main(void), i copied some code created by the
Eclipse CDT C++ tool.
 
T

Thomas J. Gritzan

darren said:
cool, thanks for the helpful info Martin. I didn't know that
returning an object makes a copy of the object to pass back. What
would happen if you returned a reference to an object? If it
referenced something local, would the reference but null since that
stackframe is destroyed?

int& reftoInt()
{
int i = 5;
return i; // don't do this!
}

i is an automatic variable that gets invalid when leaving the function,
so you return a reference to a lost object. Bad idea!

int& reftoStaticInt()
{
static int i = 5;
return i; // ok
}

A static variable has 'infinite' lifetime, you can pass a pointer or
reference to it around and can access it until the program ends.

int copyOfInt()
{
int i = 5;
return i; // ok, too
}

Since the return type is not a reference but normal object, the value
(5) will be copied before the local variable will be destroyed.
Also, say i had a statement like this:
char* myCString = "a string"
string myCppString = "another string"

A _string literal_ like "yet another string literal" has 'infinite'
lifetime (= lives until the program ends) just like a static variable.

const char* string1 = "a string";
This is a pointer to a string literal. Its valid until the program ends.

char string2[] = "a string";
This is a character array, initialized from a string literal (the
contents will be copied to the array). Defined in a function, it has
automatic lifetime (until end of function) and returning a pointer to
this array is a bad idea, since the pointer will point to invalid memory.

std::string string3 = "a string";
This is an object of class std::string. Just like string2, it is
initialized from a string literal. When defined locally in a function,
it will be destroyed on its end just like the char array, so returning a
pointer or reference to it is a bad idea, too. But you can return a full
object, so the string will be copied.
I'm assuming that these string literals are stored on the heap? If so,
do i need to explicitly manage that memory? I thought I read that C++
handles those types of object automatically, but i"m not sure.

Victor: as for why its main(void), i copied some code created by the
Eclipse CDT C++ tool.

int main(void) is idiomatic in C but discuraged (because unnecessary) in
C++.
 
D

darren

cool, thanks for the helpful info Martin. I didn't know that
returning an object makes a copy of the object to pass back. What
would happen if you returned a reference to an object? If it
referenced something local, would the reference but null since that
stackframe is destroyed?

int& reftoInt()
{
int i = 5;
return i; // don't do this!

}

i is an automatic variable that gets invalid when leaving the function,
so you return a reference to a lost object. Bad idea!

int& reftoStaticInt()
{
static int i = 5;
return i; // ok

}

A static variable has 'infinite' lifetime, you can pass a pointer or
reference to it around and can access it until the program ends.

int copyOfInt()
{
int i = 5;
return i; // ok, too

}

Since the return type is not a reference but normal object, the value
(5) will be copied before the local variable will be destroyed.
Also, say i had a statement like this:
char* myCString = "a string"
string myCppString = "another string"

A _string literal_ like "yet another string literal" has 'infinite'
lifetime (= lives until the program ends) just like a static variable.

const char* string1 = "a string";
This is a pointer to a string literal. Its valid until the program ends.

char string2[] = "a string";
This is a character array, initialized from a string literal (the
contents will be copied to the array). Defined in a function, it has
automatic lifetime (until end of function) and returning a pointer to
this array is a bad idea, since the pointer will point to invalid memory.

std::string string3 = "a string";
This is an object of class std::string. Just like string2, it is
initialized from a string literal. When defined locally in a function,
it will be destroyed on its end just like the char array, so returning a
pointer or reference to it is a bad idea, too. But you can return a full
object, so the string will be copied.
I'm assuming that these string literals are stored on the heap? If so,
do i need to explicitly manage that memory? I thought I read that C++
handles those types of object automatically, but i"m not sure.
Victor: as for why its main(void), i copied some code created by the
Eclipse CDT C++ tool.

int main(void) is idiomatic in C but discuraged (because unnecessary) in
C++.

thomas, that saved me a lot of reading and searching for answers.
Thanks a lot for your time and help.
 
J

Juha Nieminen

Thomas said:
A _string literal_ like "yet another string literal" has 'infinite'
lifetime (= lives until the program ends) just like a static variable.

So to make things clear, this is ok?

const char* aString() { return "A string"; }
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,189
Latest member
CryptoTaxSoftware

Latest Threads

Top