return function

[StGuru]

Why do I need char *Function()? I mean, why do I need the * in front of the Function1() ??

Does the * mean pointer?

#include <iostream>
using namespace std;

char *Function1()
{ 
     return "Some text";
     
}

int main()
{
    cout<<Function1();
    
    system("PAUSE");
    return 0;
}

[Speedo]

Why do I need char *Function()? I mean, why do I need the * in front of the Function1() ??

Does the * mean pointer?

Yes. If you only return "char", you are returning a single character. With "char*" you are returning a pointer to the first element in an array of characters, whose end is signified by the character '\0', aka a C-style string.

[VictorN]

1. To make it more convenient to understand I'd rewrite it as:

char* Function1();

Which just means that the function Function1() returns the value of the char* type (a pointer to the character array)

1. Your Function1() implementation is wrong: the char array "Some text" goes out of scope just before this function is returning. So it will always return a pointer to the garbage!

[StGuru]

Thanks for the replies.
@Speedo does the pointer points to the first element of the array? The array itself its a pointer, right?

@VictorN I don't understand why you say my Implementation is wrong?

[laserlight]

Your Function1() implementation is wrong: the char array "Some text" goes out of scope just before this function is returning. So it will always return a pointer to the garbage!

I had the impression that since a string literal is returned that is not so due to static storage duration. What would be wrong is the return type, i.e., it should be const char* instead of just char*.

does the pointer points to the first element of the array?

Yes, assuming that VictorN is wrong and the string literal is not destroyed, in which case the pointer returned would be pointing to something that does not exist.

The array itself its a pointer, right?

No, it is an array.

[Lindley]

An array is always convertible to the pointer of the same type, however, so in effect the array "is" a pointer in a sense.

[StGuru]

Wait are u saying to me that I return pointer which doesn't exists in the function implementation?

[VictorN]

I had the impression that since a string literal is returned that is not so due to static storage duration.

Yes, it is correct.
However, since the OP wrote this "string literal" as "Some text" I was (and still am) afraid, this function is supposed to return any text somehow generated there...

[laserlight]

An array is always convertible to the pointer of the same type

No, an array is always convertible to a pointer to its first element, which certainly is not of the same type as the array

Wait are u saying to me that I return pointer which doesn't exists in the function implementation?

No, what VictorN is saying that by returning a string literal as you do in your Function1() function, the caller (i.e., the main() function) gets a pointer to something that no longer exists since by going out of scope the string literal is destroyed. However, I recall being told differently in the case of string literals, so I am not sure if VictorN is correct. The easiest way out is to simply don't risk it: e.g., return a std::string instead of a pointer.

EDIT:
Read VictorN's reply in post #8.

[StGuru]

laserlight now I understand what are u saying to me. But I don't find I reason, why the code should not work. It is everything correct. It is true that after calling the function Function1 the pointer will be destroyed. But how that changes something?

[laserlight]

But I don't find I reason, why the code should not work. It is everything correct. It is true that after calling the function Function1 the pointer will be destroyed. But how that changes something?

No, the pointer in main() will correctly point to the first character of the string literal. So, in this sense it is much ado about nothing: your code is correct on that point.

Let's look at an example where it is not correct:

#include <iostream>

const char* function2()
{
    char text[] = "hello world";
    return text;
}

int main()
{
    const char* str = function2();
    std::cout << str << std::endl;
}

The problem is that text only exists within function2(). When function2() returns, it is destroyed. Therefore, str would point to something that no longer exists. This is a problem because if it no longer exists, how can you print it? Maybe you do manage to print it, but that would just be "luck".

[StGuru]

I got error [Warning] address of local variable `text' returned.
Anyway, I got the text printed on the screen without altering the code.

btw why u use const?

[VictorN]

I got error [Warning] address of local variable `text' returned.
Anyway, I got the text printed on the screen without altering the code.

Well, try another example:

char* function3()
{
    char text[20];
    strcpy(text, "hello world");
    return text;
}

[Plasmator]

I got error [Warning] address of local variable `text' returned.

That's a good thing.

Anyway, I got the text printed on the screen without altering the code.

Pure luck.

btw why u use const?

const-qualification in this context doesn't matter much. The point of the snippet was to demonstrate what happens when you attempt to read/write to something that no longer exists.

Conversely, const-qualification is very important in your original snippet's context. In fact, implicit convention from const to non-const qualification has been deprecated (for string literals) -- not even mentioning the fact that it's extremely easy to run into undefined behavior by doing this.

[Lindley]

Perhaps this will better demonstrate the problem.

#include <iostream>

int function3()
{
     int vals[] = {42, 23, 64, 1, 0};
     return vals[1];
}

const char* function2()
{
    char text[] = "hello world";
    return text;
}

int main()
{
    const char* str = function2();
    int val = function3();
    std::cout << str << std::endl;
}

The point being that while it was incorrect to access the no-longer-valid str pointer before, there was a good chance it would "work" because nothing was upsetting the state of the stack before it was output. Now there's this other function that tramples all over the stack in between, so the results are less likely to be pretty.