Connecting Tech Pros Worldwide Help | Site Map

basic question about returning strings / char arrays

darren
Guest
 
Posts: n/a
#1: Jun 27 '08
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.
Victor Bazarov
Guest
 
Posts: n/a
#2: Jun 27 '08

re: basic question about returning strings / char arrays


darren wrote:
Quote:
Hi everybody, have a quick look at this code:
>
=====
=====
>
int main(void) {
Ugh... Drop the 'void' between the parentheses. If you need nothing
there, there should be nothing.
Quote:
>
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.
So, what's stopping you from defining your 'makeString' function like this:

std::string makeString() {
return "Here is a char array";
}

and using it accordingly?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Martin York
Guest
 
Posts: n/a
#3: Jun 27 '08

re: basic question about returning strings / char arrays


On May 20, 10:05 am, darren <minof...@gmail.comwrote:
Quote:
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.
darren
Guest
 
Posts: n/a
#4: Jun 27 '08

re: basic question about returning strings / char arrays


On May 20, 12:37 pm, Martin York <Martin.YorkAma...@gmail.comwrote:
Quote:
On May 20, 10:05 am, darren <minof...@gmail.comwrote:
>
Quote:
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.
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.
kwikius
Guest
 
Posts: n/a
#5: Jun 27 '08

re: basic question about returning strings / char arrays



"darren" <minofifa@gmail.comwrote in message
news:2d8e27d7-45e6-461f-93ae-fe26c78bd5c1@s21g2000prm.googlegroups.com...

<...>
Quote:
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?
The best option to answer all these questions is to read the clc++ faq.

http://www.parashift.com/c++-faq-lite/index.html

regards
Andy Little


Thomas J. Gritzan
Guest
 
Posts: n/a
#6: Jun 27 '08

re: basic question about returning strings / char arrays


darren wrote:
Quote:
On May 20, 12:37 pm, Martin York <Martin.YorkAma...@gmail.comwrote:
[...]
Quote:
Quote:
>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?
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.
Quote:
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.
Quote:
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
darren
Guest
 
Posts: n/a
#7: Jun 27 '08

re: basic question about returning strings / char arrays


On May 20, 4:01 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
wrote:
Quote:
darren wrote:
Quote:
On May 20, 12:37 pm, Martin York <Martin.YorkAma...@gmail.comwrote:
[...]
Quote:
Quote:
If the result had been returned by reference then you would encounter
problems.
>
Quote:
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.
>
Quote:
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.
>
Quote:
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.
>
Quote:
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
thomas, that saved me a lot of reading and searching for answers.
Thanks a lot for your time and help.
Juha Nieminen
Guest
 
Posts: n/a
#8: Jun 27 '08

re: basic question about returning strings / char arrays


Thomas J. Gritzan wrote:
Quote:
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"; }
Thomas J. Gritzan
Guest
 
Posts: n/a
#9: Jun 27 '08

re: basic question about returning strings / char arrays


Juha Nieminen schrieb:
Quote:
Thomas J. Gritzan wrote:
Quote:
>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"; }
Yes.

--
Thomas
Closed Thread