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

Groups > comp.lang.c > #19614

Re: Alternative libraries for C, that are efficient

Show all headers | View raw

On 04/13/2012 06:38 AM, BartC wrote:
> 
> 
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:jm7sc1$18n$1@dont-email.me...
>> On 04/12/2012 04:07 PM, BartC wrote:
>>> "John Reye" <jononanon@googlemail.com> wrote in message
>>> news:d965f1e6-f918-4c5b-88f8-b5c09644faef@f5g2000vby.googlegroups.com...
>> ...
>>>> Example:            char * strcat ( char * destination, const char *
>>>> source );
>>>> Return Value:     destination is returned.
>>>>
>>>> How useless is that! I already know the distination, in the first
>>>> place.
>>>> Why not return a pointer to the end of the concatenated string, or the
>>>> size of the string. This would cost the library no extra performance
>>>> cost whatsoever!
>>>>
>>>>
>>>> Are these deficiencies _only_ string-related?
>>>
>>> It seems that way. But no-one is bothered about it, because writing
>>> alternative versions (thin wrappers around standard functions) is 
>>> trivial:
>> ,,,
>>> int strcpy_l(char *s,char *t,int tlen){
>>> if (tlen<0) tlen=strlen(t);
>>> memcpy(s,t,tlen+1);
>>> return tlen;
>>> }
>>
>> Your wrapper version passes through the input array twice: once for
>> strlen() and once for memcpy().
> 
> Yes, I mentioned my versions work better when the caller knows the lengths.

Which I consider a very minor advantage; if the length is known, just
call memcpy() directly. If it's not known, your version is slower than
strcpy(), and no faster than strcpy() followed by strlen().

>  That's precisely the deficiency he wants
>> to avoid. A minor change to the implementation of strcpy() would allow
>> it to return the desired pointer at no extra cost - the cost for your
>> wrapper is fairly high.
> 
> My point was that wrappers like this can be trivial to write: that 
> length-based strcpy_l() function took only a minute or two. And instantly it 
> can already be faster than the standard function.

With only a little extra work, you can write your own strcpy_l() that
doesn't call standard library functions, passes through the array only
once, and is likely (with a decent compiler) to compile into code with
speed comparable to that of strcpy() itself, but with the added
advantage of returning a value which contains more useful information
than that returned by strcpy(). I wouldn't bother writing such a
routine, because it's trivial to inline the code manually; but it would
have been slightly more convenient if strcpy() had been defined to work
that way in the first place. It's not a sufficiently big issue to
justify John Reye's overreaction, but it is a real one.

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

Thread

Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 09:01 -0700
  Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 09:05 -0700
    Re: Alternative libraries for C, that are efficient ImpalerCore <jadill33@gmail.com> - 2012-04-12 09:38 -0700
      Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:32 -0700
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 14:41 -0400
          Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-12 18:51 +0000
            Re: Alternative libraries for C, that are efficient nick_keighley_nospam@hotmail.com - 2012-04-13 03:46 -0700
              Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-13 14:51 +0000
            Re: Alternative libraries for C, that are efficient Kenneth Brody <kenbrody@spamcop.net> - 2012-04-13 12:38 -0400
              Re: Alternative libraries for C, that are efficient Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-04-15 19:47 +0300
  Re: Alternative libraries for C, that are efficient tom st denis <tom@iahu.ca> - 2012-04-12 09:09 -0700
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:13 -0700
      Re: Alternative libraries for C, that are efficient tom st denis <tom@iahu.ca> - 2012-04-12 18:20 -0700
  Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-12 18:13 +0200
    Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 12:47 -0400
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:22 -0700
      Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-13 22:37 +0200
        Re: Alternative libraries for C, that are efficient Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-04-15 20:15 +0300
          Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-15 23:30 +0200
  Re: Alternative libraries for C, that are efficient Ben Pfaff <blp@cs.stanford.edu> - 2012-04-12 09:20 -0700
  Re: Alternative libraries for C, that are efficient Noob <root@127.0.0.1> - 2012-04-12 18:34 +0200
    Re: Alternative libraries for C, that are efficient Kaz Kylheku <kaz@kylheku.com> - 2012-04-12 18:00 +0000
      Re: Alternative libraries for C, that are efficient nick_keighley_nospam@hotmail.com - 2012-04-13 03:50 -0700
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:24 -0700
      Re: Alternative libraries for C, that are efficient Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-12 13:08 -0700
  Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 12:50 -0400
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:30 -0700
      Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 15:55 -0400
  Re: Alternative libraries for C, that are efficient Barry Schwarz <schwarzb@dqel.com> - 2012-04-12 11:41 -0700
    Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-12 19:08 +0000
  Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-12 21:07 +0100
    Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 20:35 -0400
      Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-13 11:38 +0100
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-13 09:52 -0400
          Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-13 17:56 +0100
      Re: Alternative libraries for C, that are efficient Kenneth Brody <kenbrody@spamcop.net> - 2012-04-13 12:56 -0400
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-13 14:48 -0400
          Re: Alternative libraries for C, that are efficient Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-14 07:22 -0700
  Re: Alternative libraries for C, that are efficient Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-12 21:23 -0400
    Re: Alternative libraries for C, that are efficient Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-04-13 16:52 +0000
  Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-13 23:24 +0200

csiph-web