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

Groups > comp.lang.c > #19622

Re: Alternative libraries for C, that are efficient

Show all headers | View raw

On 04/13/2012 12:56 PM, Kenneth Brody wrote:
> On 4/12/2012 8:35 PM, James Kuyper wrote:
>> On 04/12/2012 04:07 PM, BartC wrote:
>>> "John Reye"<jononanon@googlemail.com>  wrote in message
> [...]
>>>> 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(). 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.
> 
> Well, "fairly high" is relative.  What is the code going to do with the 
> copy?  Perhaps that is orders of magnitude longer than the call to strlen().

Agreed - I don't like wasting anything, but the amount of waste involved
here is not sufficient to justify John Reye's description of these
routines as "useless".

> Note, too, that it may be more efficient to call strlen() and then memcpy() 
> than it is to copy byte-by-byte as you look for the nul-terminator.  (As I 
> recall, the x86 series of CPU has a single opcode which basically does 
> strlen, and memcpy can copy 4 [or even 8] bytes at a time for everything 
> other than the endpoints.)

That's too platform-specific an issue for my tastes; some other platform
might have a single opcode for copying while looking for a null
terminator. As long as I write clean simple code that does precisely
what needs to be done, and no more than what needs to be done, I feel
I've done my part of the job; choosing the right op-codes to implement
it is the compiler's part.

If a two-pass implementation turns out to be faster than the one-pass
solution I wrote, I can hope that a sufficiently sophisticated compiler
will convert my one-pass C code into machine code equivalent to a
two-pass implementation. I'm not going to lose any sleep over the
possibility that it won't. If I need more speed, and can afford to loose
portability, I'll use assembly language rather than trying to figure out
how to trick a particular C compiler into generating the assembly
language I want it to generate.

John would probably be more interested in such issues than I am.

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