String questions

[gamehack]

Hi all,

I've been designing a program which would need to have a function to
replace values in a string.
For example I could have a string:
"<circle x="%" y="%">" and then I would replace the % with actual
values. But I cannot think of a way to convert an integer(say 5643) to
a NULL terminated string. I'm thinking of writing a function like:
char* get_circle(int x, int y)
{
}

But that would return a char* and not the actual string. So I would
need to dynamically allocate the string(not on the stack) so it is not
deleted automatically after the function ends. Then the code which is
using the result is responsible to free it, isn't it? Any ideas how to
go about implementing this function? I'm not asking for code, just for
directions. Thanks.

PS.
Say you use some function which returns a char* and you have some code
like:
char* c;
c = somefun();
Then surely somefun(); returns a char* which is saved in memory
temporarily and then this is assigned to c. But where does the
temporary value go? Who's responsible for freeing it?

 

[Ben Pfaff]

I've been designing a program which would need to have a function to
replace values in a string.
For example I could have a string:
"<circle x="%" y="%">" and then I would replace the % with actual
values.

C already has a function that does something similar to that. It
is call sprintf().

But I cannot think of a way to convert an integer(say 5643) to
a NULL terminated string.

You can also do that with sprintf().

I'm thinking of writing a function like: char* get_circle(int
x, int y) {
}

But that would return a char* and not the actual string.

I'm puzzled how a char *, that presumably points to the start of
a string, is not an actual string.

So I would need to dynamically allocate the string(not on the
stack) so it is not deleted automatically after the function
ends. Then the code which is using the result is responsible to
free it, isn't it?
Yes.

Any ideas how to go about implementing this function? I'm not
asking for code, just for directions. Thanks.

Call malloc() to get an appropriate amount of space.
Use sprintf() to write into the space[*].
Return the string.

[*] snprintf() is a safer choice but not all implementations have
it, because it is new in C99.

An alternative approach would be to have the caller provide a
buffer into which the string is written. This can in many cases
avoid the need for dynamic memory allocation, because the caller
is often able to allocate automatic memory (which is typically
"on the stack", as you say) for the string.

PS.
Say you use some function which returns a char* and you have some code
like:
char* c;
c = somefun();
Then surely somefun(); returns a char* which is saved in memory
temporarily and then this is assigned to c. But where does the
temporary value go? Who's responsible for freeing it?

Typically, the caller is responsible for freeing it, but you can
design your code to work however you like.

 

[Eric Sosman]

gamehack wrote On 02/14/06 14:55,:

Hi all,

I've been designing a program which would need to have a function to
replace values in a string.
For example I could have a string:
"<circle x="%" y="%">" and then I would replace the % with actual
values. But I cannot think of a way to convert an integer(say 5643) to
a NULL terminated string. I'm thinking of writing a function like:
char* get_circle(int x, int y)
{
}

Is there some reason you can't use sprintf(), or
snprintf() if you have a C99 implementation?

But that would return a char* and not the actual string. So I would
need to dynamically allocate the string(not on the stack) so it is not
deleted automatically after the function ends. Then the code which is
using the result is responsible to free it, isn't it? Any ideas how to
go about implementing this function? I'm not asking for code, just for
directions. Thanks.

Objects on the stack (more precisely, "objects with
automatic storage duration") disappear when execution
leaves the block that contains them. So you're right:
it would be folly to return a pointer to such an object,
because the object would vanish before the caller ever
got an opportunity to use the pointer to it.

Some other possibilities:

- The caller could provide the buffer and let the
called function store the string in it. Issues:
the caller must know how large a buffer to provide,
or else the called function needs a way to tell
the caller that the buffer was too small.

- The called function could allocate the storage
dynamically with malloc() or equivalent. Issues:
what should the function do if malloc fails, and
who takes responsibility for freeing the memory
when it's no longer needed?

- The string could be placed in static storage, which
can be pointed to safely by a returned value because
static storage outlasts the execution of any single
block. Issues: You can only have one string "in
play" at a time, because it will be overwritten the
next time the function is called. Variations: the
string could be in dynamic storage with the pointer
to it being static, the static area could have enough
"slots" for N strings used in round-robin fashion to
allow up to N circles to be "in play" simultaneously.

PS.
Say you use some function which returns a char* and you have some code
like:
char* c;
c = somefun();
Then surely somefun(); returns a char* which is saved in memory
temporarily and then this is assigned to c. But where does the
temporary value go? Who's responsible for freeing it?

The value returned by a function is just a value; it
may or may not be stored in memory as part of the value-
returning mechanism for functions. For example, it might
reside in a designated CPU register. Whatever mechanism
is used, it is the C implementation's responsibility to
handle the details, not the programmer's.

 

[gamehack]

gamehack wrote On 02/14/06 14:55,:

[snip]

Thanks

 

[Keith Thompson]

I'm puzzled how a char *, that presumably points to the start of
a string, is not an actual string.

Um, because a string is an array, and a char* is a pointer (which
might point to the start of a string). If a C function could return
an actual string, we wouldn't have to worry about memory allocation.
I'm certain you know that; I'm puzzled by your puzzlement.