📄 retaggr.970623.html
字号:
<html><!-- Mirrored from c-faq.com/malloc/retaggr.970623.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 08:02:59 GMT --><head><title></title></head><body>From: scs@eskimo.com (Steve Summit)<br>Newsgroups: comp.lang.c<br>Subject: Re: function that returns string [repost]<br>Date: 23 Jun 1997 22:14:59 GMT<br>Message-ID: <5omsh3$4jb$1@eskinews.eskimo.com><br>X-Original-Date: 18 Jun 1997 17:50:13 GMT<br>X-Original-Message-ID: <5o974l$df6$1@eskinews.eskimo.com><br>See-Also: <1992Aug4.170926.2335@athena.mit.edu><p>With regards to the multiple static return buffer technique mostrecently posted by John Winters, brucemo@seanet.com wrote:<p>> I think that technique is awful because it adds unnecessary "cute" code, <br>> uses up 200 bytes of static data, introduces something you need to <br>> document (the fact that buffers returned by the function eventually will <br>> get over-written), and introduces bugs (caused by the above time-bomb <br>> combined with failure to read or remember this documentation), all in a <br>> dubious effort to save someone the hassle of allocating a buffer on the <br>> stack and passing a pointer to this buffer to the function.<br>> <br>> Sorry, but this thread has made me cringe. I can't stand to see people <br>> turn a simple function into a complicated "system" for no reason. This <br>> kind of coding leads to byzantine structures that make the person you <br>> hand your code off to want to drink too much.<p>It all depends. In many circumstances, I'd agree with youcompletely that gratuitous complexity or cleverness serves onlyto stroke the original coder's ego and to make everyone else'slives miserable. But not always.<p>Software engineering is all about managing complexity. If you'vegot complexity spread out all over the place, sort of like thepink sludge in The Cat In The Hat Comes Back, you've got problems.And if you or Little Cat Z can figure out a way to sweep at leastsome of the complexity off into one little corner, so that youcan ignore it except when you have occasion to venture into thatcorner, then that's a good thing.<p>I'm lazy. I like simple code, that's easy to understand and thatwrites itself. But I will occasionally bend 'way over backwards,and toil away an entire day writing some miserably complicated,excessively general function, if that function will then serveas a workhorse which I can punt all the hard work to from therest of the program, such that the rest of the program becomespleasantly, falling-off-a-log easy to write.<p>In C, at least, returning strings from functions can be a littlebit hard, and any technique for doing so is more complex thanit is to return a simple, non-aggregate value. When you'respecifying any functional interface, it's often a delicatequestion how much of the work you should have the function doand how much you should require the caller to do. It's notenough that the specification be correct and complete; if it'stoo cumbersome to use, or makes the caller do too much work,then the would-be caller may get discouraged, and decide thatit's too much trouble to call the function after all, such thatthe benefit of having the function is at least partially lost.The tradeoffs can be subtle, and can depend on many things,but it's certainly not possible to (in this case) declareunilaterally either that the caller should always allocatespace for the string result, or that the function shouldalways allocate it. Different situations may requiredifferent approaches (at least for best results).<p>The multiple static return buffer technique certainly isn't apanacea. John wasn't advocating using it all of the time, andalthough it's a technique I like a lot, I hardly ever find myselfactually using it, either. But once in a while, the tradeoffsare such that it is quite attractive and (I believe) appropriate.<p>Some time ago, I wrote a long article discussing some of theoptions for returning strings and other aggregates, and theirrelative merits and applicability. I was going to mount a searchfor it, but then last night, in a directory and on a machinewhere I wouldn't even have looked, I came across a copy (as ithappens, while looking for directories to clean up to save somedisk space). <a href="retaggr.920804.html">Here it is</a>.<p><hr><p>[Well, <a href="retaggr.920804.html">there it was</a>,but an hour later I found<a href="retaggr.940616.html">another one</a>...]<p><hr><p>From: scs@eskimo.com (Steve Summit)<br>Newsgroups: comp.lang.c<br>Subject: Re: function that returns string [repost]<br>Date: 23 Jun 1997 22:15:07 GMT<br>Message-ID: <5omshb$4jg$1@eskinews.eskimo.com><br>X-Original-Date: 18 Jun 1997 18:53:06 GMT<br>X-Original-Message-ID: <5o9aqi$fcq$1@eskinews.eskimo.com><br>See-Also: <CrHu2G.D3B@eskimo.com><p>In article <5o974l$df6$1@eskinews.eskimo.com>, I wrote:<br>> Some time ago, I wrote a long article discussing some of the<br>> options for returning strings and other aggregates, and their<br>> relative merits and applicability. I was going to mount a search<br>> for it, but then last night, in a directory and on a machine<br>> where I wouldn't even have looked, I came across a copy (as it<br>> happens, while looking for directories to clean up to save some<br>> disk space).<p>And I was so pleased at having done so that I neglected to followthrough on this nagging feeling I had that the article I'd justfound didn't do as much discussing of tradeoffs and relativemerits as the one I remembered. Then, when I went to put theone I'd just found in the directory where it belonged, sureenough, there was another file there (of exactly the same name;determinism strikes again) containing <a href="retaggr.940616.html"><em>this</em> article</a> (whichI have edited lightly for this posting).</body><!-- Mirrored from c-faq.com/malloc/retaggr.970623.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 08:02:59 GMT --></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -