Why lsearch?

[Kenny McCormack]

Is there any reason to use the lsearch() function? (Rather than just
looping through it yourself)

(I think it is clear why I am asking this question - I will not go into the
detail of explaining why - unless asked, in which case, I will give the
long version of the explanation).

Note: I think I used to know the answer to this, so I am asking this from
the perspective of "I think there is an answer, but I can't remember what
it is", rather the more common perspective of "This is crazy. There is no
answer".

[Eric Sosman]

Re: Why lsearch?

Kenny McCormack wrote:[color=blue]
> Is there any reason to use the lsearch() function? (Rather than just
> looping through it yourself)[/color]

There is no lsearch() function in the Standard C library.

<off-topic>

I found documentation for a function named lsearch() that
may or may not be akin to the one you're asking about: This one
does a linear search through an array, using parameters somewhat
like those for qsort() or bsearch() to handle "opaque" data types.
If the item is found in the array, lsearch() returns a pointer
to the pre-existing item. Otherwise, lsearch() appends the item
to the array (updating a count) and returns a pointer to the
newly-added item.

If the type of the item is known at compile time, I can see
no advantage (and some disadvantage) to using lsearch() -- an
ordinary in-line loop seems simpler and is likely to be faster.
The only advantage I can see to lsearch() is if you're writing
code that deals with opaque data types, where all you get is a
`void*' or something of the sort. Such situations are fairly
rare, though; one usually has *some* information about what
data types are permissible.

FWIW, my feelings about bsearch() are much the same: I don't
find it useful, although others apparently do. So when I fail
to see much use in lsearch(), it may just be my prejudices.

</off-topic>

--
Eric.Sosman@sun .com

[Default User]

Re: Why lsearch?

Kenny McCormack wrote:[color=blue]
>
> Is there any reason to use the lsearch() function? (Rather than just
> looping through it yourself)[/color]


Never heard of it. I can think of reasons for NOT using nonstandard
functions.



Brian Rodenborn

[Kenny McCormack]

Re: Why lsearch?

In article <411CFE40.50605 05@sun.com>,
Eric Sosman <Eric.Sosman@Su n.COM> wrote:[color=blue]
>Kenny McCormack wrote:[color=green]
>> Is there any reason to use the lsearch() function? (Rather than just
>> looping through it yourself)[/color]
>
> There is no lsearch() function in the Standard C library.[/color]

I couldn't quite tell one way or the other. I *thought* that bsearch and
qsort were "standard" and assumed, by extension, that lsearch was also.

But I am not sure of this (clearly).
[color=blue]
><off-topic>
>
> I found documentation for a function named lsearch() that
>may or may not be akin to the one you're asking about: This one
>does a linear search through an array, using parameters somewhat
>like those for qsort() or bsearch() to handle "opaque" data types.
>If the item is found in the array, lsearch() returns a pointer
>to the pre-existing item. Otherwise, lsearch() appends the item
>to the array (updating a count) and returns a pointer to the
>newly-added item.[/color]

Yes, that's the one.
[color=blue]
> If the type of the item is known at compile time, I can see
>no advantage (and some disadvantage) to using lsearch() -- an
>ordinary in-line loop seems simpler and is likely to be faster.
>The only advantage I can see to lsearch() is if you're writing
>code that deals with opaque data types, where all you get is a
>`void*' or something of the sort. Such situations are fairly
>rare, though; one usually has *some* information about what
>data types are permissible.[/color]

You mean, like, if you were programming in an environment where you are
given the pointer to the data and the access functions (the thing you
passed to qsort/bsearch/lsearch), but aren't actually told what the type
of the data is? Weird, but I suppose conceivable...
[color=blue]
> FWIW, my feelings about bsearch() are much the same: I don't
>find it useful, although others apparently do. So when I fail
>to see much use in lsearch(), it may just be my prejudices.[/color]

bsearch I understand - because it does contribute something that you might
not know how to do yourself. But lsearch really doesn't.

[Erik Trulsson]

Re: Why lsearch?

Kenny McCormack <gazelle@yin.in teraccess.com> wrote:[color=blue]
> In article <411CFE40.50605 05@sun.com>,
> Eric Sosman <Eric.Sosman@Su n.COM> wrote:[color=green]
>>Kenny McCormack wrote:[color=darkred]
>>> Is there any reason to use the lsearch() function? (Rather than just
>>> looping through it yourself)[/color]
>>
>> There is no lsearch() function in the Standard C library.[/color]
>
> I couldn't quite tell one way or the other. I *thought* that bsearch and
> qsort were "standard" and assumed, by extension, that lsearch was also.
>
> But I am not sure of this (clearly).[/color]

bsearch() and qsort() are part of Standard C. lsearch() is not.

(Although it does appear that lsearch() is defined by Posix, but that is
outside the scope of this newsgroup.)


--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@studen t.uu.se

[Rich Grise]

Re: Why lsearch?

Eric Sosman wrote:
[color=blue]
> Kenny McCormack wrote:[color=green]
>> Is there any reason to use the lsearch() function? (Rather than just
>> looping through it yourself)[/color]
>
> There is no lsearch() function in the Standard C library.
>[/color]
I've learned at least two things today, both of which are something
that's not standard C, but I have always seen included in libraries.

Where's the list? I don't want to accidentally use something non-
regulation, like lseek().

Thanks,
Rich

[Joe Wright]

Re: Why lsearch?

Rich Grise wrote:[color=blue]
> Eric Sosman wrote:
>
>[color=green]
>>Kenny McCormack wrote:
>>[color=darkred]
>>>Is there any reason to use the lsearch() function? (Rather than just
>>>looping through it yourself)[/color]
>>
>> There is no lsearch() function in the Standard C library.
>>[/color]
>
> I've learned at least two things today, both of which are something
> that's not standard C, but I have always seen included in libraries.
>
> Where's the list? I don't want to accidentally use something non-
> regulation, like lseek().
>
> Thanks,
> Rich[/color]

The List is in the C Standard. Even in the N869 draft. You knew
that, right? By the way, Eric does his homework about as well as
anyone here. Challenge him at your peril. :-)

--
Joe Wright mailto:joewwrig ht@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[_Christopher\(M2M\)]

Re: Why lsearch?

This is a help page from Borland C++ 3.1 You may need to change to font to
a mono font in other to read this.


bsearch, lfind,
lsearch, and qsort <STDLIB.H, SEARCH.H>

bsearch performs a binary search
lfind and lsearch perform a linear search
qsort sorts using the quicksort algorithm

Declaration:

void *bsearch(const void *key, const void *base, size_t nelem,size_t width,
int (*fcmp)(const void*, const void*));
void *lfind(const void *key, const void *base, size_t *num,size_t width, int
(*fcmp)(const void *, const void*));
void *lsearch(const void *key, void *base, size_t *num,size_t width, int
(*fcmp)(const void *, const void *));
void qsort(void *base, size_t nelem,size_t width, int (*fcmp)(const void *,
const void *));

Remarks:

Function What It Does

bsearch Makes a binary search for the value *key in a table (array)
of nelem elements in memory
lfind Makes a linear search for *key in an array of sequential
records
lsearch Makes a linear search for *key in a table. If *key is not in
the table, lsearch appends it (the search key) to the table.
qsort Is an implementation of the "median of three" variant of the
quicksort algorithm


Argument What It Is/Points To

base The base (0th element) of the search table
fcmp A user-defined comparison routine that compares two items
and returns a value based on the comparison
key The item to be searched for (the search key)
nelem The number of entries in the table
num The number of entries in the table
width The number of bytes in each entry

NOTE:
# Because lsearch performs a linear search, the table entries do not need
to be sorted before the function call.
# Because bsearch performs a binary search, the first matching entry is
not necessarily the first entry in the table.

Return Value:

Function On Failure On Success

bsearch 0 (No match) The address of the first
lfind NULL (No match) entry in the table that
lsearch matches the search key

qsort None None

Portability:
+ DOS + UNIX + Windows + ANSI C + C++ Only +
bsearch | Yes | Yes | Yes | Yes | |
lfind | Yes | Yes | Yes | | |
lsearch | Yes | Yes | Yes | | |
qsort | Yes | Yes | Yes | Yes | |
+-----+------+---------+--------+----------+
Examples:
bsearch example lfind example lsearch example qsort example



lsearch example

/* lsearch example */

#include <stdlib.h>
#include <stdio.h>
#include <string.h> /* for strcmp declaration */

/* initialize number of colours */
char *colours[10] = { "Red", "Blue", "Green" };
int ncolours = 3;

int colourscmp(char **arg1, char **arg2)
{
return(strcmp(* arg1, *arg2));
}

int addelem(char *key)
{
int oldn = ncolours;
lsearch(key, colours, (size_t *)&ncolours, sizeof(char *),
(int(*)(const void *,const void *))colourscmp);
return(ncolours == oldn);
}

int main(void)
{
int i;
char *key = "Purple";

if (addelem(key))
printf("%s already in colours table\n", key);
else
{
strcpy(colours[ncolours-1],key);
printf("%s added to colours table\n", key);
}

printf("The colours:\n");
for (i = 0; i < ncolours; i++)
printf("%s\n", colours[i]);
return 0;
}





--
From _Christopher (M2M).
RefCode:44CXcxT Cdff4 V04
void DeadEnds() {for(;;);} // :)

If replying by email please included ##71; on the subject line followed by
your subject,
any post without the ##71; tag WILL be deleted. I.e. "##71; Thank for the
help."

"Kenny McCormack" <gazelle@yin.in teraccess.com> wrote in message
news:cfit36$o54 $1@yin.interacc ess.com...[color=blue]
> Is there any reason to use the lsearch() function? (Rather than just
> looping through it yourself)
>
> (I think it is clear why I am asking this question - I will not go into[/color]
the[color=blue]
> detail of explaining why - unless asked, in which case, I will give the
> long version of the explanation).
>
> Note: I think I used to know the answer to this, so I am asking this from
> the perspective of "I think there is an answer, but I can't remember what
> it is", rather the more common perspective of "This is crazy. There is no
> answer".[/color]

[Kenny McCormack]

Re: Why lsearch?

In article <cfnoje$gsg$1@t itan.btinternet .com>,
_Christopher\(M 2M\) <cdhuk2000@yaho o.co.uk> wrote:[color=blue]
>This is a help page from Borland C++ 3.1 You may need to change to font to
>a mono font in other to read this.[/color]

I'm sorry - your point was?

I think you are focussing on "what", when the question was (and is) "why".

[Eric Sosman]

Re: Why lsearch?

Rich Grise wrote:[color=blue]
> Eric Sosman wrote:
>
>[color=green]
>>Kenny McCormack wrote:
>>[color=darkred]
>>>Is there any reason to use the lsearch() function? (Rather than just
>>>looping through it yourself)[/color]
>>
>> There is no lsearch() function in the Standard C library.
>>[/color]
>
> I've learned at least two things today, both of which are something
> that's not standard C, but I have always seen included in libraries.
>
> Where's the list? I don't want to accidentally use something non-
> regulation, like lseek().[/color]

For the C language, "the list" is in the Standard itself.
A good C textbook or reference will contain "the list" and may
explain it more readably.

That's not the end of the story, though. Although people
on this newsgroup don't like to talk about them (for good reason),
Standards other than the C Standard do in fact exist. You will
find that lseek() is a Standard function on a POSIX system, just
not part of the C language and library per se. Does that mean
you shouldn't use lseek()? That's a question you must ask and
answer again for each program you write. Essentially, you must
predict the environments in which it will be asked to operate,
and which Standards hold sway in those environments. "The list"
for your program will be the union of the functions specified by
the various Standards you decide to require.

Every time you add another Standard to the environment your
program requires you place another limit on your program's
portability: A program that relies only on the C Standard will
operate on more systems than one that requires C *and* IEEE
floating-point *and* a bouquet of POSIX Standards. However,
portability is just one attribute of a program, not the be-all
and end-all of program design. You must weigh the portability
limitations of additional Standards against the benefits they
bring to your purpose.

"Let a thousand functions bloom!" -- Chairman Dennis

--
Eric.Sosman@sun .com