API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: Jens Thoms Toerring on 19 Dec 2009 17:18 In comp.lang.c James Harris <james.harris.1(a)googlemail.com> wrote: > On 17 Dec, 17:06, jacob navia <ja...(a)nospam.org> wrote: > > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext > > > > Communications of the ACM rarely bring something practical. > > This is a good exception. > > > > It is a good article about API design, and the problems of bad APIs. > It is a good article though I'd take exception to his criticisms of > the C select function. select() isn't a genuine C function (in the sense that it's part of the C standard) but comes AFAIK from UNIX/POSIX;-) > If it were to do as he suggests and return a > number of fds without overwriting the input fd set it would have to > return newly allocated memory which it would be left to the caller to > free. As far as I can see the function could also take a pointer to three further fd_set's that belong to the caller and just modify those, couldn't it? On the other hand, there may have been also other considerations when the select() function was invent a long time ago like speed, memory requirements etc. on machines at the time, so I would be a bit careful about blaming the original authors about coming up with a bad API when I don't know all the factors they had to take into account. > This could be done but it would be unusual for C functions > wouldn't it? IIRC some of the string functions return new objects but > most other C functions seem to go to lengths to avoid doing so. I can't remember a single standard C string function that does that, they all seem to operate on user supplied memory. Perhaps you're thinking about some non-standard-C (but POSIX) functions like strdup()? > - in anticipation that someone will correct me if my impression is > wrong.... - me too;-) Regards, Jens -- \ Jens Thoms Toerring ___ jt(a)toerring.de \__________________________ http://toerring.de
From: Chris McDonald on 19 Dec 2009 17:44 jt(a)toerring.de (Jens Thoms Toerring) writes: >I can't remember a single standard C string function that does >that, they all seem to operate on user supplied memory. Perhaps >you're thinking about some non-standard-C (but POSIX) functions >like strdup()? Not really wishing to steal the thread, but I've often wondered why strdup() has not appeared in the C standard. Could a reason be because it *does* return allocated memory? -- Chris.
From: Hallvard B Furuseth on 19 Dec 2009 18:00 Jens Thoms Toerring writes: > In comp.lang.c James Harris <james.harris.1(a)googlemail.com> wrote: >> This could be done but it would be unusual for C functions >> wouldn't it? IIRC some of the string functions return new objects but >> most other C functions seem to go to lengths to avoid doing so. > > I can't remember a single standard C string function that does > that, they all seem to operate on user supplied memory. Right. Or on static/program-allocated memory - asctime(), getenv(), strerror(). There is fopen() which might allocate memory, but it has its own function (fclose) which will free it. > Perhaps you're thinking about some non-standard-C (but POSIX) > functions like strdup()? -- Hallvard
From: Malcolm McLean on 20 Dec 2009 05:36 "Chris McDonald" <chris(a)csse.uwa.edu.au> wrote in message news: > jt(a)toerring.de (Jens Thoms Toerring) writes: > > Not really wishing to steal the thread, but I've often wondered why > strdup() has not appeared in the C standard. Could a reason be because > it *does* return allocated memory? > That's right. It would make the string library dependent upon the dynamic memory allocation library. Just for one trivial little function, it wasn't considered worth it.
From: Flash Gordon on 20 Dec 2009 06:39
Malcolm McLean wrote: > "Chris McDonald" <chris(a)csse.uwa.edu.au> wrote in message news: >> jt(a)toerring.de (Jens Thoms Toerring) writes: >> >> Not really wishing to steal the thread, but I've often wondered why >> strdup() has not appeared in the C standard. Could a reason be because >> it *does* return allocated memory? >> > That's right. It would make the string library dependent upon the dynamic > memory allocation library. Just for one trivial little function, it wasn't > considered worth it. I very much doubt that is the issue, since both the sting functions and memory allocation functions are in the *same* library, the standard C library. As I understand it this was more a matter of philosophy, that is was decided that the str* and mem* functions do not allocate memory, and the only functions to allocate memory which needed a call to free would be the *alloc functions. Maybe a proposal for stralloc would have been seen more favourably ;-) -- Flash Gordon |