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

Groups > comp.lang.c > #19588

Re: Alternative libraries for C, that are efficient

Show all headers | View raw

On 04/12/2012 02:30 PM, John Reye wrote:
> On Apr 12, 6:50 pm, James Kuyper <jameskuy...@verizon.net> wrote:
[>> John Reye wrote:]
>>> Is there no good library which I can use for optimal computing?
>>
>> I think that you can safely assume that no library you've ever heard of,
>> and no library that you ever will hear of, is perfectly optimal.
> What about a library that has better interfaces.

I guarantee you that the library with better interfaces will still be
sub-optimal.

>> I almost never write my own routines for any purpose for which a C
>> standard library routine can be made to serve, even if the library
>> routine is a less-than perfect fit to my desires. The main exception is
>> that I will often manually inline code that is roughly equivalent to
>> some of the standard str*() and mem*() functions, especially strtok().
>> For the other str*() and mem*() functions, I'll usually inline the code
>> only if I need a pointer to the end of the memory that was processed,
>> something that the standard library functions don't provide. The
>> in-lining is generally trivial for most of those functions.
> 
> Could you perhaps give a brief example of what you mean with inlining,
> here.

Here's an example of code to concatenate some strings:

	outstring[0] = '\0';
	for(str=0; str < num_strings; str++)
	    strcat(outstring, in_strings[str]);

My inline equivalent would be as follows:

	char *p = outstring;
	for(str=0; str < num_strings; str++)
	{
	    const char *q = instrings[str];
	    while(*p++ = *q++);
	    p--; // move back to terminating null character
	}

It's slightly more wordy, but keeps track of the current end of the
string, avoiding the time wasted by strcat() searching for the end of
the string. It's a minor issue, and I wouldn't bother with it if it were
significantly more difficult to do. Most of the str*() and mem*()
functions are easy to inline.

Here's some code in a utility library that I inherited responsibility
for several years ago. If caused problems when called inside a strtok()
loop in the calling routine:

    if((p=strtok(local_string, ","))!=NULL){
      do{
        /* Byte_sum = MFAIL if datatype_to_DFNT fails.
           Get HDF_num_type for p */
        if((HDF_num_type=datatype_to_DFNT(p))==MFAIL)byte_sum=MFAIL;

        /* If not MFAIL, increment byte_sum by the number of
           bytes returned from DFKNTsize */
        else byte_sum=byte_sum+(long int)DFKNTsize(HDF_num_type);

        }while((p=strtok(NULL,","))!=NULL && byte_sum!=MFAIL);
    }

To resolve this problem, a subordinate re-wrote the code, following my
advice, as follows:

    while (local_string != NULL && byte_sum != MFAIL) {
        next_string = strchr(local_string, ',');
        if (next_string)
           *next_string++ = '\0';
        HDF_num_type = datatype_to_DFNT(local_string);
        if (HDF_num_type==MFAIL)
           byte_sum = MFAIL;
        else
           byte_sum += (long int)DFKNTsize(HDF_num_type);
        local_string = next_string;
    }

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