Re: General rules on interface (function) design
- From: Eric Sosman <Eric.Sosman@xxxxxxx>
- Date: Tue, 23 May 2006 12:37:05 -0400
lovecreatesbeauty wrote On 05/23/06 10:19,:
Could you talk something about the general rules on the interface
(function) design in C program that recognized publically? Or introduce
some good advice of yourself.
How do you think about some of those advices like following?
a. keep the interface clean and clear (What does clean or clear mean
and how to achieve that?).
"For motherhood and against sin." (A parodist's summary
of politicians' campaign posturings.)
b. avoid using static variables in local function if possible.
See Richard Heathfield's response. Also, what do you mean
by a "local" function, and how does it differ from "national"
functions or "remote" functions or "express" functions?
c. avoid using global variables for local function if possible.
In addition to the points raised by R.H., note that a file-
scope variable has static storage duration and thus shares the
drawbacks of (b).
d. avoid allocating dynamic memory in local function if possible.
Hogwash. Allocate memory when you need it and as it's
needed. The important thing isn't where it's allocated, but
that it's properly kept track of.
And I write following the function to convert an integer to a string.
Your advices are welcome and appreciated.
Requirement: convert an integer to character string, put one blank char
among the string, for example: "1 2 3 4 0 9" for 123409.
/* s : hold the string presentation of an integer.
* num : an integer is to be gotten its string presentation.
*/
void itoa2(char *s, int num)
{
int len = 100;
char s1[len]; /* C99 features involved */
No need, as shown in R.H.'s post. (However, I see no
reason to initialize the array to all zeroes as he does.)
sprintf(s1, "%d", num);
int i = 0, j = 0;
for (i = 0; s1[i]; ++i, ++j)
{
s[j] = s1[i];
s[++j] = ' ';
}
s[--j] = '\0';
}
How do you think about following choices of different interface design:
/* #2 self-contained or self-sufficient */
void itoa2(char *s, int num);
Unattractive, because it ignores the lesson of gets().
Two alternatives seem plausible:
- Let the caller provide both a buffer pointer and a
buffer size, and the function promises to honor the
size. If the buffer is too small for the number,
the function should be able to return a value that
describes the difficulty. See snprintf().
- In the header that declares itoa2(), #define a macro
named ITOA2BUFSIZE or some such. Require (in the
documentation) that the caller provide at buffer of
at least ITOA2BUFSIZE characters.
/* #3 global or static variables or dynamic memory may be required */
void itoa3(int num);
This signature appears to require a global variable to
communicate the result; I don't like it. The variable might
be the result buffer or a pointer to a dynamically-allocated
buffer or a FILE* stream that the caller can rewind and read
back again ... No matter; I don't like it.
--
Eric.Sosman@xxxxxxx
.
- Follow-Ups:
- Re: General rules on interface (function) design
- From: August Karlstrom
- Re: General rules on interface (function) design
- From: Richard Heathfield
- Re: General rules on interface (function) design
- References:
- General rules on interface (function) design
- From: lovecreatesbeauty
- General rules on interface (function) design
- Prev by Date: Re: General rules on interface (function) design
- Next by Date: Re: General rules on interface (function) design
- Previous by thread: Re: General rules on interface (function) design
- Next by thread: Re: General rules on interface (function) design
- Index(es):
Relevant Pages
|
