Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #62395

Re: Return value for strcat and similar functions

Show all headers | View raw

On 20/05/15 20:08, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 12/05/15 05:42, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>
>> <snip>
>>
>>> The cost I'm talking about is a coding and maintenance cost,
>>> not a compilation or performance cost.  I don't mind agreeing to
>>> the possibility that your sense of the size of that cost may be
>>> different from mine.
>>
>> Fair enough.  I don't think we need a discussion about the differences
>> in such costs in this context - at least, not in this thread.
>>
>>>> The point of this thread was to ask people with different
>>>> experiences and styles if they could think of an advantage of the
>>>> way strcat is defined - precisely because while I could not think
>>>> of one myself, I thought that someone else might.  So far no one
>>>> (including you) has given any suggestions other than "it seemed a
>>>> good idea at the time" or "they standardised the function they
>>>> were using, without thinking about other use-cases".  [snip]
>>>
>>> My answer may not have been stated very clearly, but I did
>>> suggest another possible explanation, namely, for reasons you
>>> don't consider important, namely coding convenience in certain
>>> situations, those making the choice thought, and still think (or
>>> would think, if they were still alive), that this consideration
>>> outweighs those of the alternate semantics, even after conscious
>>> evaluation.
>>
>> Can you give me:
>>
>> 1. An example where strcat, as defined today, leads to /significantly/
>> clearer, neater, more maintainable, or more efficient code than a
>> "strcat2" function that returns a pointer to the end of the string?
>>
>> 2. A justification why you think such coding style was likely in the
>> early days of C, thus making it a reasonable explanation for the
>> choice of strcat?
> 
> No, I'm not offering either of those.  I'm not saying the reasons
> mentioned are ones you would find convincing, only that is it
> plausible that the original designers found them convincing.

I realise that - that's why I asked you for a justification for why you
think the original designers did it this way.  But I am not yet
convinced that the original designers thought this through properly.  I
can accept that they might have had different balances between
efficiency and simplicity, or compilers with different abilities, or
different styles.  However, I am still lacking /any/ justification for
suggesting the original library designers thought "strcat" was a better
choice than "strcat2".  Currently, it appears that they simply didn't
consider the issues.  (And that's fair enough - we can't expect them to
have had perfect hindsight when starting out.  We must simply live with
it as another of C's sub-optimal design decisions.)

> 
>> It's very easy to find situations where a strcat2 (returning a pointer
>> to the end of the string) is clearer and more efficient than strcat.
>>
>> // Combine three strings and return the total length
>> int combineStrings(char* s, const char* t1, const char* t2) {
>>     strcat(s, t1);		// Time len(s) + len(t1)
>>     strcat(s, t2);		// Time len(s) + len(t1) + len(t2)
>>     return strlen(s);	// Time len(s) + len(t1) + len(t2)
>> }
>> // Total time 3*len(s) + 3*len(t1) + 2*len(t2)
>>
>>
>> int combineStrings(char* s, const char* t1, const char* t2) {
>>     char* end = strcat2(s, t1);	// Time len(s) + len(t1)
>>     end = strcat(end, t2);		// Time len(t2)
>>     return end - s;		// Time 1
>> }
>> // Total time len(s) + len(t1) + len(t2) + 1
>>
>> (Note that if you really don't like the extra "char* end" variable, you
>> can use strcat2 exactly like strcat in the first version.)
> 
> These examples don't seem very compelling to me, because what the
> functions do seems somewhat contrived, and because they don't
> match how I expect they would be written, especially if
> efficiency concerns were paramount.  (I assume you meant strcat2
> rather than strcat in the second definition.)

They are simply example functions that demonstrate the difference
between strcat and strcat2 when combining several strings.  Feel free to
write them in a more efficient form - once using the standard strcat,
strcpy, strlen functions, and once using strcat2.  No loops to manually
copy the strings are allowed (because that would be missing the point of
having the library functions).  I am curious to see how you would write
them with greater efficiency.

> 
>> It is also simpler and more efficient to implement strcat in terms of
>> strcat2 rather than the reverse:
>>
>> char * strcat(char* s, const char* t) {
>>     strcat2(s, t);		// Time len(s) + len(t)
>>     return s;
>> }
>> // Total time len(s) + len(t)
>>
>> char * strcat2(char* s, const char* t) {
>>     strcat(s, t);		// Time len(s) + len(t)
>>     return strlen(s);	// Time len(s) + len(t)
>> }
>> // Total time 2*len(s) + 2*len(t)
> 
> I might agree on the "more efficient" part, but not on "simpler"
> part.

You cannot possibly /disagree/ on the "more efficient" part - strcat can
be implemented optimally from strcat2, while the opposite direction
requires double the time.  (In theory, a smart enough compiler could
remove the function calls and turn the strcat + strlen into an inlined
loop.)

And how can you justify contending on the "simpler" part?  Implementing
strcat from strcat2 requires one function call, while implementing
strcat2 from strcat requires two function calls.  I won't claim it's a
complicated function, but there can be no doubts as to which is simpler.

> 
>> So it is clear that there are common cases where a strcat2 returning the
>> end pointer is more flexible and significantly more efficient than the
>> standard version.  There are no cases in which the standard version is
>> more efficient.  And the standard version is easily and efficiently
>> created from the strcat2 version.
> 
> I understand that you think this reasoning is convincing.  Not
> everyone does.

I have given a fair amount of justification and evidence for why my
reasoning makes sense.  I still have heard absolutely no technical
justification for the choice of strcat as we have it today, compared to
strcat2 (or a version that returned the length of the new string, which
would be another reasonable alternative).  You have done nothing but
claim that the original library authors might have had good reason for
the decision.

> 
>> The question is, does the standard version lead to significantly neater
>> or clearer code in common cases, and was it common enough to lead to a
>> concious design decision when the library was standardised?  Or was it,
>> as most people here seem to think, a bad decision - probably the result
>> of standardising someone's existing usage rather than the result of a
>> thoughtful design.
> 
> Why do you find it so hard to believe that other people might
> reasonably reach different conclusions than you do?
> 

I like to base my conclusions on evidence and technical justifications,
if I can.  I can find plenty of evidence for the viewpoint that strcat2
would have been a better choice for the standard library than strcat.  I
can find no significant evidence to the contrary, and no one else here
seems to have done so either.

The nearest I have seen is the fact that strcat allows certain chained
expression syntaxes that cannot be written directly with strcat2 - you
need to use multiple expressions.  But even in such cases, the strcat2
version is not more difficult, and it is much more efficient.  And no
one has argued that such chained expressions were common in old C code,
or that they were a reason for picking the strcat form.

So the question is, why do you find it so hard to believe that the
original design decision was not a good one, and was perhaps made in
haste or for "historical" reasons?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-06 10:02 +0200
  Re: Return value for strcat and similar functions Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-05-06 10:34 +0200
  Re: Return value for strcat and similar functions Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-05-06 16:51 +0200
  Re: Return value for strcat and similar functions Keith Thompson <kst-u@mib.org> - 2015-05-06 08:58 -0700
    Re: Return value for strcat and similar functions Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 17:07 +0100
      Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-06 12:01 -0500
    Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-07 10:19 +0200
      Re: Return value for strcat and similar functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-07 13:21 +0000
        Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-07 16:24 +0200
          Re: Return value for strcat and similar functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-07 18:02 +0000
      Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-07 10:17 -0500
        Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-07 10:56 -0500
          Re: Return value for strcat and similar functions asetofsymbols@gmail.com - 2015-05-07 11:00 -0700
            Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-07 14:28 -0500
              Re: Return value for strcat and similar functions asetofsymbols@gmail.com - 2015-05-07 12:47 -0700
          Re: Return value for strcat and similar functions Nathan Wagner <nw@hydaspes.if.org> - 2015-05-08 09:31 +0000
        Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 15:55 -0700
        Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-08 11:03 +0200
          Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-08 05:07 -0500
  Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 18:25 -0700
    Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-07 10:22 +0200
      Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 15:39 -0700
        Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-08 11:09 +0200
          Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 08:44 -0700
            Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-10 21:30 +0200
              Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 20:42 -0700
                Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-12 09:52 +0200
                Re: Return value for strcat and similar functions Bartc <bc@freeuk.com> - 2015-05-12 13:33 +0100
                Re: Return value for strcat and similar functions Ike Naar <ike@iceland.freeshell.org> - 2015-05-14 20:15 +0000
                Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-14 23:06 +0200
                Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 11:08 -0700
                Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-21 10:55 +0200
                Re: Return value for strcat and similar functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 13:05 +0000
                Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-21 20:42 +0200
                Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 10:40 -0700
    Re: Return value for strcat and similar functions raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:56 +0000
      Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 09:07 -0700
  Re: Return value for strcat and similar functions Bartc <bc@freeuk.com> - 2015-05-07 10:11 +0100

csiph-web