473,386 Members | 2,050 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,386 software developers and data experts.

Why lsearch?

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".
Nov 14 '05 #1
9 3066
Kenny McCormack wrote:
Is there any reason to use the lsearch() function? (Rather than just
looping through it yourself)


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>

--
Er*********@sun.com

Nov 14 '05 #2
Kenny McCormack wrote:

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

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

Brian Rodenborn
Nov 14 '05 #3
In article <41**************@sun.com>,
Eric Sosman <Er*********@Sun.COM> wrote:
Kenny McCormack wrote:
Is there any reason to use the lsearch() function? (Rather than just
looping through it yourself)
There is no lsearch() function in the Standard C library.


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).
<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.
Yes, that's the one.
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.
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...
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.


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

Nov 14 '05 #4
Kenny McCormack <ga*****@yin.interaccess.com> wrote:
In article <41**************@sun.com>,
Eric Sosman <Er*********@Sun.COM> wrote:
Kenny McCormack wrote:
Is there any reason to use the lsearch() function? (Rather than just
looping through it yourself)


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


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).


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
er******@student.uu.se
Nov 14 '05 #5
Eric Sosman wrote:
Kenny McCormack wrote:
Is there any reason to use the lsearch() function? (Rather than just
looping through it yourself)


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

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

Nov 14 '05 #6
Rich Grise wrote:
Eric Sosman wrote:

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


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


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


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:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #7
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:44CXcxTCdff4 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" <ga*****@yin.interaccess.com> wrote in message
news:cf**********@yin.interaccess.com...
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".

Nov 14 '05 #8
In article <cf**********@titan.btinternet.com>,
_Christopher\(M2M\) <cd*******@yahoo.co.uk> wrote:
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.


I'm sorry - your point was?

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

Nov 14 '05 #9
Rich Grise wrote:
Eric Sosman wrote:

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


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


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().


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

--
Er*********@sun.com

Nov 14 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: ferbar | last post by:
Hi all, I'm working on a program that tests a random number generator -rand()- in this case. Runs and Chi square test have to be applied to see if the numbers generated are random.. anyway, I'm...
23
by: comp.lang.tcl | last post by:
I have a TCL proc that needs to convert what might be a list into a string to read consider this: ]; # OUTPUTS Hello World which is fine for PHP ]; # OUTPUT {{-Hello}} World, which PHP...
27
by: comp.lang.tcl | last post by:
My TCL proc, XML_GET_ALL_ELEMENT_ATTRS, is supposed to convert an XML file into a TCL list as follows: attr1 {val1} attr2 {val2} ... attrN {valN} This is the TCL code that does this: set...
4
by: jla1357 | last post by:
In my program I need to read in a file, search for 100 unique words, and count how many times a found word has been found all by using an array. This is what I have so far, but when the file is found...
3
by: alexmason86 | last post by:
getting a bit stuck here got some code that allows a user to input numbers to a 3x3 array. but next on the tutorial sheet i have to then ask the user for a number to search for and then search the...
160
by: raphfrk | last post by:
Is this valid? int a; void *b; b = (void *)a; // b points to a b += 5*sizeof(*a); // b points to a a = 100;
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.