Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > basic question about returning strings / char arrays

Reply
Thread Tools

basic question about returning strings / char arrays

 
 
darren
Guest
Posts: n/a
 
      05-20-2008
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.
 
Reply With Quote
 
 
 
 
Martin York
Guest
Posts: n/a
 
      05-20-2008
On May 20, 10:05 am, darren <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
 
 
 
darren
Guest
Posts: n/a
 
      05-20-2008
On May 20, 12:37 pm, Martin York <(E-Mail Removed)> wrote:
> On May 20, 10:05 am, darren <(E-Mail Removed)> wrote:
>
> > 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.
 
Reply With Quote
 
kwikius
Guest
Posts: n/a
 
      05-20-2008

"darren" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

<...>

> 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


 
Reply With Quote
 
Thomas J. Gritzan
Guest
Posts: n/a
 
      05-20-2008
darren wrote:
> On May 20, 12:37 pm, Martin York <(E-Mail Removed)> wrote:

[...]
>> 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.

> 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
 
Reply With Quote
 
darren
Guest
Posts: n/a
 
      05-21-2008
On May 20, 4:01 pm, "Thomas J. Gritzan" <(E-Mail Removed)>
wrote:
> darren wrote:
> > On May 20, 12:37 pm, Martin York <(E-Mail Removed)> wrote:

> [...]
> >> 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.
>
> > 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


thomas, that saved me a lot of reading and searching for answers.
Thanks a lot for your time and help.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      05-22-2008
Thomas J. Gritzan wrote:
> 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"; }
 
Reply With Quote
 
Thomas J. Gritzan
Guest
Posts: n/a
 
      05-23-2008
Juha Nieminen schrieb:
> Thomas J. Gritzan wrote:
>> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
returning char arrays from a function Robert Smith C Programming 19 03-30-2006 05:36 PM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
returning list of strings from Python COM to Visual basic 6 Philippe C. Martin Python 2 07-21-2005 12:42 AM
Arrays.asList() returning java.util.Arrays$ArrayList Alexandra Stehman Java 5 06-17-2004 06:04 PM



Advertisments