Proper modularization technique

D

drhowarddrfine

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:
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");
}

2) Make the string area static for the calling routine?
routine(){
char *string_pointer;
string_pointer=called_function();
}

char* called_function(char* string){
static char string[16];
strcpy(string,"string");
return string;
}

3) Make the string area global to that file?
char string[16];

calling_routine(){called_function();}
called_function(){strcpy(string,"string");}

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?
 
M

maverik

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?

There are many variants accroding to your application design at all.
IMHO, as I understand your ideas, you can just store string within
calling function and just return pointer:

void
routine() {
char *processed = called_function(*processed);
// you can ignore return value
// char *processed;
// called_function(*processed);
...
// code goes here
...
// Of course you must free the memory
free(processed);
}

char*
called_function(char * str) {
// allocates memory
strncpy(str, "YourString", ...) ;
return str;
}
 
M

maverik

First, I mistyped
    // called_function(*processed);
I mean // called_function(processed);

Second, I think that seperating allocation and deallocation is not a
good idea. May be you should store string within the caller:

void
routine() {
char *processed = malloc(...);
if(processed == NULL) { ... }

// Of course you may write
// char processed[123];

called_function(processed);
...
// code goes here
...

// In case of malloc
free(processed);
}

void
called_function(char * str) {
strcpy(str, "YourString") ;
}

What others say?
 
S

s0suk3

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:
1) Should I set aside an array in the calling routine and have the
function strcpy to that?

No, because

- the way you wrote it, called_function() will have no way to know
how large the passed array is, and thus is likely to write pass the
end of it. Of course, this is easily fixed by having the function
accept an extra argument that represents the array size, but then
there's the possibility that
- the function might need to store more characters than the array
can hold, thus causing truncation. If truncation isn't a problem
(e.g., you can still get the remaining data in a future call, as with
fgets()), then this is a good way to go.
2) Make the string area static for the calling routine?

No, because

- if your application is multi-threaded, this will break things;
- you can't have the function generate two or more strings and hold
them at the same time (in other words, calling the function will
modify what was previously on the array, even if you still need it);
- there's still the issue of truncation.
3) Make the string area global to that file?

No, because

- "global variables are evil." :)
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?

That has the advantage that you can call realloc() to make the buffer
as large as necessary. And yes, allocating on the heap is generally
slower than allocating on the stack, but you probably don't need to
worry about that unless you're doing micro-optimization.

Sebastian
 
D

drhowarddrfine

Thanks guys. You verified what I was thinking. My sample code above
was just to give a view of what I was trying to say though I may have
confused a little with some omissions.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top