Thread: Text (const char*)

Usually, variables are deleted when out of scope.

Code:

int *pointer;
{
  int number = 5;
  pointer = &number;
}
// now, outside the brackets, pointer points to freed memory and should not be used.

Am I right so far?


Text have the type (const char*), so I figured that text are arrays of chars stored in memory, and that (const char*) points to the first element.

That's all good.
But take a look at this code:

Code:

const char *pointer;
{
  const char *text = "This is a text";
  pointer = text;
}
// What about pointer(outside of brackets) here?

Isnt text freed when out of scope in C?
If so, is this because text-constants are created using malloc, behind the scences?
And if so, If i were to create a program with LOTS of text, wouldnt I need to manually free memory taken from text-constants?

Literal constants are normally not "freed" - if you had

Code:

char text[] = "Something";

then the storage for the text is lost once you leave the block [or some time later on, but certainly by the end of the function - there is no guarantee that the end of a block ACTUALLY frees the memory - if it was C++ and an object was leaving it's scope, the destructor would be called at that point, however].

Edit: A related case would be:

Code:

const char *somefunc()
{
   return "Hello";
}

Obviously, "Hello" doesn't disappear when the function returns. Your original code is essentially just finding the pointer of a constant string, and then assigning a different pointer with the address of the constant string - it's perfectly legal and an acceptable thing to do.

--
Mats

hmm... I tried searching for this in the 1999 edition of the C Standard but did not get a definitive answer that I could understand. On the other hand, Herb Sutter's GotW #9: Memory Management - Part I states that "the const data area stores string literals and other data whose values are known at compile time. No objects of class type can exist in this area. All data in this area is available during the entire lifetime of the program."

Now, I have read criticism that Sutter's use of terms in that article may be biased/misleading/etc, but if he is correct on that point, then I suspect that the string literal is not destroyed, even though the text pointer itself goes out of scope.

Originally Posted by Drogin

// Would it still be legal and safe to assume pointer still reffer to "This is a text"?(outside of brackets) I would guess so, but that would mean
// text-constants are guaranteed not to get overwritten even when out of scope.

Based on what I understand and on Herb Sutter's article, I would say that yes, the lifetime of a string literal is the lifetime of the program, so pointer still refers to the string literal.

Preamble: I am not a language lawyer, so I do not know what the language standard actually says in this matter.

Answer: I would have no qualms about writing something like that myself. In fact I have often used things similar to that in my code - in particular setting a pointer to a constant and then returning the resulting string to another function.

It is possible that some compilers, under very special circumstances, may decide that a string is no longer needed, and discard it. A particular case that I can think of was in Turbo Pascal, where you had overlays, and a constant string in one module would be replaced with the code of another function when the second function got called - and any constant in the original code was now replaced along with the function itself. That's not C or C++, but I guess there may be similar features in some compilers (perhaps for embedded use) that do the same thing.

--
Mats

Originally Posted by Drogin

Does this create a char-array and copies each char from the (const char*)"This is a test", to the array?

Yes, at least in terms of how you can think of it.

Originally Posted by Drogin

Or does the "test" variable simply become a pointer to the (const char*)"This is a test" ?

No, which is why it would not be wrong to write what you wrote instead of:

Code:

const char test[] = "This is a test";

Note that test really is an array, not a pointer, though it is easily converted to a pointer to its first element.

Originally Posted by Drogin

Interesting.

What happens at this line?

Code:

char test[] = "This is a test";

Does this create a char-array and copies each char from the (const char*)"This is a test", to the array?

Or does the "test" variable simply become a pointer to the (const char*)"This is a test" ?

Laserlight has answered the exact questions above, but this is definitely a case where returning or otherwise referring to the address of "test" outside of the scope is not going to work out in all circumstances.

Originally Posted by itCbitC

scope of a variable is related to its visibility in the various functions and/or source files that makeup the entire program.

Is it really?
I suspect it is more than that. Variables that go out of scope are destroyed in the eyes of the language.

freed is a misnomer in this case as pointer is an automatic variable (if local to a function); it exists until overwritten.

Again, incorrect. The variable is indeed destroyed, in the eyes of the language.
Whatever else happens is up to the OS. In case of Windows, it is as you say.

to say freed would be incorrect, the variable still exists but gets overwritten by another function invocation.

Same as above.

Originally Posted by C_ntua

The advantage of C++ string though is that you don't have to worry about the size. If you give a string litteral greater than 10 you would get an error. But otherwise the string won't get discarded by any compiler

Correction: undefined behavior.

Originally Posted by Elysia

Is it really?
I suspect it is more than that. Variables that go out of scope are destroyed in the eyes of the language.

I would differentiate between scope and lifetime. For variables with automatic storage duration scope and lifetime is the same, but say, a static variable in a function may exist at function scope, but its lifetime could exceed that of the function call.