drhowarddrfine wrote:
I'm unsure the best way to do this. I want to call a function that
will generate a string to be used by the calling routine. Where is
the best place to store that string? iow:
Much depends on your definition of "best" ...
1) Should I set aside an array in the calling routine and have the
function strcpy to that?
routine(){
char string[16];
called_function(string);
}
called_function(char* string){
strcpy(string,"string");
}
This works if `16' (which probably ought to be a #define) is
easily predictable and not over-large. The utility of returning
a pointer to the string -- something the caller already knows --
is questionable.
An important variant is to let the caller manage the storage
*and* tell the called routine how much there is:
routine() {
char string[HOWMANY];
called_function(string, sizeof string);
}
char *called_function(char *string, size_t size) {
if (strlen("string") < size) {
strcpy(string, "string");
return string;
}
return NULL; /* means "not enough room" */
}
2) Make the string area static for the calling routine?
routine(){
char *string_pointer;
string_pointer=called_function();
}
char* called_function(char* string){
Where did the argument come from? Copy-and-paste error?
static char string[16];
strcpy(string,"string");
return string;
}
This works if you never need more than one returned value
at a time (or if the value is the same every time). It would
not work well if done this way:
char *called_function(int answer){
static char string[16];
strcpy(string, answer == 42 ? "Right!" : "Rong!");
return string;
}
...
printf ("%s %s\n", called_function(42), called_function(24));
3) Make the string area global to that file?
char string[16];
calling_routine(){called_function();}
called_function(){strcpy(string,"string");}
Same drawback as (2), plus the additional drawbacks of global
variables. Globals *are* useful, sometimes, but they are very
easy to overuse and can engender maintenance nightmares. Avoid
them unless they're unavoidable.
Part 2 of this would be, I have a whole bunch of these small routines
that need less than 256 bytes of memory for storing such strings.
Would it be better to just malloc to acquire the memory for that and
then release it? Does that cause relative program slow down doing all
that acquire/releasing?
"We follow two rules in the matter of optimization:
Rule 1. Don't do it.
Rule 2 (for experts only). Don't do it yet - that is, not
until you have a perfecly clear and unoptimized solution."
-- M.A. Jackson
It is likely that all of the approaches you mention will be faster
than managing the memory with malloc() and free(). But here's the
crucial question: Will their speed be enough greater to make up for
their other drawbacks, or even enough to notice? Keep in mind all the
other things your program is (presumably) doing, and ask yourself
whether there might be something more important to fret about ...
Giving your car a fresh coat of wax might reduce air resistance
and improve the fuel economy, but taking the boat trailer off the
back will probably improve it more.
--
Er*********@sun.com