C Pointers

[pateldm15]

How do I sort an string array using pointers

[Ian Collins]

pa*******@yahoo.com wrote:

How do I sort an string array using pointers

How do you think? Post an attempt and you will get help.

--
Ian Collins.

[Friedrich Dominicus]

pa*******@yahoo.com writes:

How do I sort an string array using pointers

Tip: qsort + strcmp

Have a nice day of C programming
Friedrich

--
Please remove just-for-news- to reply via e-mail.

[erfan]

On 12ÔÂ1ÈÕ, ÏÂÎç4ʱ07·Ö, Friedrich Dominicus <just-for-news-fr...@q-software-
solutions.dewrote:

[e-mail] writes:

How do I sort an string array using pointers

Tip: qsort + strcmp

Have a nice day of C programming
Friedrich

--
Please remove just-for-news- to reply via e-mail.

why not try www.google.com?
have a nice day:)

[CBFalconer]

Friedrich Dominicus wrote:

pa*******@yahoo.com writes:

>How do I sort an string array using pointers

Tip: qsort + strcmp

Have a nice day of C programming

Simpler: Make a singly linked list and apply merge sort.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[santosh]

CBFalconer wrote:

Friedrich Dominicus wrote:

>pa*******@yahoo.com writes:

>>How do I sort an string array using pointers

Tip: qsort + strcmp

Have a nice day of C programming

Simpler: Make a singly linked list and apply merge sort.

How is this method simpler?

[aarklon]

On Nov 30, 9:44 pm, Ian Collins <[e-mail]:

[e-mail] wrote:

How do I sort an string array using pointers

How do you think? Post an attempt and you will get help.

--
Ian Collins.

what about this attempt

void sort(char *m[10])
{
int a,b,x;
char *temp;

for(a=0;a < 10;a++)
for(b = a + 1;b<10;b++)
{
x=0;
while(*(*(m+a) +x))
{
if( *(*(m+a)+x) *(*(m + b)+x) )
{
temp = *(m+a);
*(m+a) = *(m +b);
*(m + b) = temp;
break;
}
else if( *(*(m+a)+x) < *(*(m+b)+x) )
break;

else
x++;
}
}
}

[santosh]

aa*****@gmail.com wrote:

On Nov 30, 9:44 pm, Ian Collins <[e-mail]:

>[e-mail] wrote:

How do I sort an string array using pointers

How do you think? Post an attempt and you will get help.

--
Ian Collins.

what about this attempt

void sort(char *m[10])
{
int a,b,x;
char *temp;

for(a=0;a < 10;a++)
for(b = a + 1;b<10;b++)
{
x=0;
while(*(*(m+a) +x))
{
if( *(*(m+a)+x) *(*(m + b)+x) )
{
temp = *(m+a);
*(m+a) = *(m +b);
*(m + b) = temp;
break;
}
else if( *(*(m+a)+x) < *(*(m+b)+x) )
break;

else
x++;
}
}
}

Please do submit this to:

<http://ioccc.org/>

[vippstar]

On Dec 1, 4:30 am, [e-mail] wrote:

How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2)
{
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers
to char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);
}

int
main(int argc, char *argv[])
{
int j;
if(argc 1) {
qsort(&argv[1], argc - 1, sizeof(char *), cmpstringp);
for (j = 1; j < argc; j++)
puts(argv[j]);
}
exit(EXIT_SUCCESS);
}

[pete]

vi******@gmail.com wrote:

>
On Dec 1, 4:30 am, [e-mail] wrote:

How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2)
{
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers
to char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);

The type of your strcmp arguments is (char *const).
The strcmp parameter type is (const char *).

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

}

int
main(int argc, char *argv[])
{
int j;
if(argc 1) {
qsort(&argv[1], argc - 1, sizeof(char *), cmpstringp);
for (j = 1; j < argc; j++)
puts(argv[j]);
}
exit(EXIT_SUCCESS);
}

--
pete

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 01 Dec 2007 07:06:31 -0500, pete wrote:

vi******@gmail.com wrote:

>>
On Dec 1, 4:30 am, [e-mail] wrote:

How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2) {
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers to
char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);

The type of your strcmp arguments is (char *const). The strcmp parameter
type is (const char *).

char * can be implicitly converted to const char *.

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

argv is declared as char *[]. argv[n] (which is what p1 and p2 point to)
is a char *. You shouldn't access a char * as if it were a const char *.

I'm not saying it's not allowed, because I'm not sure about that, but I
consider it poor style at least.

[pete]

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

>
On Sat, 01 Dec 2007 07:06:31 -0500, pete wrote:

vi******@gmail.com wrote:

>
On Dec 1, 4:30 am, [e-mail] wrote:
How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2) {
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers to
char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);

The type of your strcmp arguments is (char *const). The strcmp parameter
type is (const char *).

char * can be implicitly converted to const char *.

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

argv is declared as char *[].
argv[n] (which is what p1 and p2 point to) is a char *.
You shouldn't access a char * as if it were a const char *.

I'm not saying it's not allowed, because I'm not sure about that,
but I consider it poor style at least.

However,
strcmp *will* access its arguments as type (const char *).
A function call to strcmp,
implies that there are parameters of type (const char *)
being initialized with the values of the arguments.
The values of those arguments should be type (const char *).
int strcmp(const char *s1, const char *s2);
--
pete

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 01 Dec 2007 07:32:04 -0500, pete wrote:

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

>On Sat, 01 Dec 2007 07:06:31 -0500, pete wrote:

vi******@gmail.com wrote:

On Dec 1, 4:30 am, [e-mail] wrote:
How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2) {
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers to
char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);

The type of your strcmp arguments is (char *const). The strcmp
parameter type is (const char *).

char * can be implicitly converted to const char *.

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

argv is declared as char *[].
argv[n] (which is what p1 and p2 point to) is a char *. You shouldn't
access a char * as if it were a const char *.

I'm not saying it's not allowed, because I'm not sure about that, but I
consider it poor style at least.

However,
strcmp *will* access its arguments as type (const char *).

No, it won't. It will access its parameters as type (const char *), and
its parameters *are* type const char *, as the result of the implicit
conversion from the arguments (of type char *) to const char *. You can
compare it to this:

Good:

char a = 'x';
int b = a;
const int *c = &b;

Bad:

char a = 'x';
const int *c = (int *) &a;

[Tor Rustad]

vi******@gmail.com wrote:

On Dec 1, 4:30 am, [e-mail] wrote:

>How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2)
{
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers
to char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);
}

int
main(int argc, char *argv[])
{
int j;
if(argc 1) {
qsort(&argv[1], argc - 1, sizeof(char *), cmpstringp);
for (j = 1; j < argc; j++)
puts(argv[j]);
}
exit(EXIT_SUCCESS);
}

Yes, assuming argv[0] represent the program name, I have yet to see an
environment where this isn't the case. Anybody knows of one?

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[santosh]

Tor Rustad wrote:

vi******@gmail.com wrote:

>On Dec 1, 4:30 am, [e-mail] wrote:

>>How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2)
{
/* The actual arguments to this function are "pointers to
pointers to char", but strcmp() arguments are "pointers
to char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);
}

int
main(int argc, char *argv[])
{
int j;
if(argc 1) {
qsort(&argv[1], argc - 1, sizeof(char *), cmpstringp);
for (j = 1; j < argc; j++)
puts(argv[j]);
}
exit(EXIT_SUCCESS);
}

Yes, assuming argv[0] represent the program name, I have yet to see an
environment where this isn't the case. Anybody knows of one?

Not specifically but I would guess that in environments where the C
program is the only program on the device, it would be meaningless for
it to have a name.

[Martien Verbruggen]

On Sat, 01 Dec 2007 13:03:58 -0500,
CBFalconer <cb********@yahoo.comwrote:

santosh wrote:

>CBFalconer wrote:

>>Friedrich Dominicus wrote:
pa*******@yahoo.com writes:

How do I sort an string array using pointers

Tip: qsort + strcmp

Have a nice day of C programming

Simpler: Make a singly linked list and apply merge sort.

How is this method simpler?

Merge sort code is simple. Input is simple, because you just
extend a linked list by one for each input line. No problem as
long as memory holds out.

[ snip of about 150 lines of code ]

But qsort is a standard function, that you do not have to implement.
Therefore it is simpler to just use that, rather than to implement any
sort algorithm yourself. Using qsort() and strcmp, as suggested before,
is likely to take less than 15 lines of code.

Also, the input is an array, not a linked list, and a good assumption
would be that the array should be sorted in place, or at least that the
output should be a sorted array. Translating it into a linked list,
sort, and then translating back, is by no means simpler than just using
a method that acts directly on the data structure at hand.

Besides that, you do not know how qsort is implemented internally. It's
a bit hard to make judgements on the complexity of the algorithm without
that knowledge.

Martien
--
|
Martien Verbruggen | Useful Statistic: 75% of the people make up
| 3/4 of the population.
|

[cr88192]

"santosh" <sa*********@gmail.comwrote in message
news:fi**********@registered.motzarella.org...

Tor Rustad wrote:

>vi******@gmail.com wrote:

<snip>

>>
Yes, assuming argv[0] represent the program name, I have yet to see an
environment where this isn't the case. Anybody knows of one?

Not specifically but I would guess that in environments where the C
program is the only program on the device, it would be meaningless for
it to have a name.

when your program consists of source files which are dynamically loaded and
compiled, there is no meaningful name to pass to main...

[pete]

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

>
On Sat, 01 Dec 2007 07:32:04 -0500, pete wrote:

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

On Sat, 01 Dec 2007 07:06:31 -0500, pete wrote:
vi******@gmail.com wrote:

On Dec 1, 4:30 am, [e-mail] wrote:
How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2) {
/* The actual arguments to this function are "pointers to
pointers to char",
but strcmp() arguments are "pointers to
char", hence the following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);

The type of your strcmp arguments is (char *const). The strcmp
parameter type is (const char *).

char * can be implicitly converted to const char *.

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

argv is declared as char *[].
argv[n] (which is what p1 and p2 point to) is a char *.
You shouldn't
access a char * as if it were a const char *.

I'm not saying it's not allowed,
because I'm not sure about that, but I
consider it poor style at least.

However,
strcmp *will* access its arguments as type (const char *).

No, it won't.
It will access its parameters as type (const char *), and
its parameters *are* type const char *, as the result of the implicit
conversion from the arguments (of type char *) to const char *.

I can't parse out which effect you say occurs:
"... as the result of the implicit conversion from the arguments
(of type char *) to const char *."

You can
compare it to this:

Good:

char a = 'x';
int b = a;
const int *c = &b;

Bad:

char a = 'x';
const int *c = (int *) &a;

At least in the bad example, your code acknowledges
that the purpose of the cast is to convert the value
to the type of the object receiving the value.

The whole point of casting a pointer initializer,
is to convert the value
to the type of the object receiving the value.

Recording the type history of the value,
is not the purpose of the cast.

--
pete

[Justin Spahr-Summers]

On Dec 1, 3:22 pm, "cr88192" <[e-mail]:

"santosh" <[e-mail] in message

news:fi**********@registered.motzarella.org...

Tor Rustad wrote:

[e-mail] wrote:

<snip>

Yes, assuming argv[0] represent the program name, I have yet to see an
environment where this isn't the case. Anybody knows of one?

Not specifically but I would guess that in environments where the C
program is the only program on the device, it would be meaningless for
it to have a name.

when your program consists of source files which are dynamically loaded and
compiled, there is no meaningful name to pass to main...

argv[0] is always present. C99 draft N1256 (section 5.1.2.2.1):
"If the value of argc is greater than zero, the string pointed to by
argv[0] represents the program name; argv[0][0] shall be the null
character if the program name is not available from the host
environment. If the value of argc is greater than one, the strings
pointed to by argv[1] through argv[argc-1] represent the program
parameters."

[CBFalconer]

Tor Rustad wrote:

>

.... snip ...

>
Yes, assuming argv[0] represent the program name, I have yet to
see an environment where this isn't the case. Anybody knows of one?

Virtually any embedded program.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[cr88192]

"Justin Spahr-Summers" <Ju*****************@gmail.comwrote in message
news:8a**********************************@e23g2000 prf.googlegroups.com...

On Dec 1, 3:22 pm, "cr88192" <[e-mail]:

>"santosh" <[e-mail] in message

news:fi**********@registered.motzarella.org...

Tor Rustad wrote:

>[e-mail] wrote:

<snip>

>Yes, assuming argv[0] represent the program name, I have yet to see an
environment where this isn't the case. Anybody knows of one?

Not specifically but I would guess that in environments where the C
program is the only program on the device, it would be meaningless for
it to have a name.

when your program consists of source files which are dynamically loaded
and
compiled, there is no meaningful name to pass to main...

argv[0] is always present. C99 draft N1256 (section 5.1.2.2.1):
"If the value of argc is greater than zero, the string pointed to by
argv[0] represents the program name; argv[0][0] shall be the null
character if the program name is not available from the host
environment. If the value of argc is greater than one, the strings
pointed to by argv[1] through argv[argc-1] represent the program
parameters."

yes, but is "\0" sensibly a valid program name?...
I will say it is not, and thus the above statements hold...

so, argv[1] to argv[argc-1] represent the program args, but argv[0] is not
necessarily the program name...

[Tor Rustad]

CBFalconer wrote:

Tor Rustad wrote:
.... snip ...

>Yes, assuming argv[0] represent the program name, I have yet to
see an environment where this isn't the case. Anybody knows of one?

Virtually any embedded program.

For some reason, I was talking about "hosted environment". :)

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[Walter Roberson]

In article <aK*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>Yes, assuming argv[0] represent the program name, I have yet to see an
environment where this isn't the case. Anybody knows of one?

Sure. POSIX offers a couple of exec*() calls in which argv[0]
can be completely arbitrary, and that facility is actually used
at times. For example,

$ ps -fe
[...]
nobody 597 451 0 Sep 21 ? 1:43 (pinger)
nobody 539 451 0 Sep 21 ? 0:04 (unlinkd)
roberson 21333 21332 0 Nov 29 ? 0:00 (dns helper)

The last of those is a process forked off by Netscape.
Historically in BSD, writing to argv[0] changed what was reported
by ps, a facility taken advantage of to indicate program status.
--
"There are some ideas so wrong that only a very intelligent person
could believe in them." -- George Orwell

[Flash Gordon]

Tor Rustad wrote, On 02/12/07 01:47:

CBFalconer wrote:

>Tor Rustad wrote:
.... snip ...

>>Yes, assuming argv[0] represent the program name, I have yet to
see an environment where this isn't the case. Anybody knows of one?

Virtually any embedded program.

For some reason, I was talking about "hosted environment". :)

Any Unix like system if the process execing your program decides to lie
about the name of the program it is invoking. Look up the Posix exec*
functions to see what I mean.
--
Flash Gordon

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 01 Dec 2007 17:43:55 -0500, pete wrote:

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

>On Sat, 01 Dec 2007 07:32:04 -0500, pete wrote:

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:
On Sat, 01 Dec 2007 07:06:31 -0500, pete wrote:
vi******@gmail.com wrote:

On Dec 1, 4:30 am, [e-mail] wrote:
How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2) {
/* The actual arguments to this function are "pointers to
pointers to char",
but strcmp() arguments are "pointers to char", hence the
following cast plus dereference */
return strcmp(* (char * const *) p1, * (char * const *) p2);

The type of your strcmp arguments is (char *const). The strcmp
parameter type is (const char *).

char * can be implicitly converted to const char *.

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

argv is declared as char *[].
argv[n] (which is what p1 and p2 point to) is a char *. You
shouldn't
access a char * as if it were a const char *.

I'm not saying it's not allowed,
because I'm not sure about that, but I consider it poor style at
least.

However,
strcmp *will* access its arguments as type (const char *).

No, it won't.
It will access its parameters as type (const char *), and its
parameters *are* type const char *, as the result of the implicit
conversion from the arguments (of type char *) to const char *.

I can't parse out which effect you say occurs:
"... as the result of the implicit conversion from the arguments
(of type char *) to const char *."

char *x = "a";
char *y = "b";
strcmp(x, y);

The arguments are x and y. x and y are of type char *. The arguments are
implicitly converted to the type of the parameters as declared in
strcmp's function prototype.

>You can
compare it to this:

Good:

char a = 'x';
int b = a;
const int *c = &b;

Bad:

char a = 'x';
const int *c = (int *) &a;

At least in the bad example, your code acknowledges that the purpose of
the cast is to convert the value to the type of the object receiving the
value.

The whole point of casting a pointer initializer, is to convert the
value
to the type of the object receiving the value.

Recording the type history of the value, is not the purpose of the cast.

But you weren't casting the pointer value argv[n], you were
reinterpreting its bit pattern, by casting a pointer to argv[n]. That's
what the second example does (except for the actual dereference). That's
what you shouldn't do.

static int
cmpstringp(const void *p1, const void *p2) {
return strcmp(* (char * const *) p1, * (char * const *) p2);
}

cmpstringp will be called by qsort as, for example,
cmpstringp(&argv[1], &argv[2]);

argv[n] is of type char *. So p1 and p2 are pointers to a char *. So they
should be dereferenced as pointers to char *. If you want to get a
const char *, you can convert the value _after_ dereferencing.

[pete]

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

>
On Sat, 01 Dec 2007 17:43:55 -0500, pete wrote:

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

On Sat, 01 Dec 2007 07:32:04 -0500, pete wrote:
=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:
On Sat, 01 Dec 2007 07:06:31 -0500, pete wrote:
vi******@gmail.com wrote:

On Dec 1, 4:30 am, [e-mail] wrote:
How do I sort an string array using pointers

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int
cmpstringp(const void *p1, const void *p2) {
/* The actual arguments to this function are "pointers to
pointers to char",
but strcmp() arguments are "pointers to char",
hence the
following cast plus dereference */
return strcmp(* (char * const *) p1,
* (char * const *) p2);

The type of your strcmp arguments is (char *const). The strcmp
parameter type is (const char *).

char * can be implicitly converted to const char *.

This way would be more better:

return strcmp(* (const char **) p1, * (const char **) p2);

argv is declared as char *[].
argv[n] (which is what p1 and p2 point to) is a char *. You
shouldn't
access a char * as if it were a const char *.

I'm not saying it's not allowed,
because I'm not sure about that, but I consider it poor style at
least.

However,
strcmp *will* access its arguments as type (const char *).

No, it won't.
It will access its parameters as type (const char *), and its
parameters *are* type const char *, as the result of the implicit
conversion from the arguments (of type char *) to const char *.

I can't parse out which effect you say occurs:
"... as the result of the implicit conversion from the arguments
(of type char *) to const char *."

char *x = "a";
char *y = "b";
strcmp(x, y);

The arguments are x and y. x and y are of type char *.
The arguments are
implicitly converted to the type of the parameters as declared in
strcmp's function prototype.

You can
compare it to this:

Good:

char a = 'x';
int b = a;
const int *c = &b;

Bad:

char a = 'x';
const int *c = (int *) &a;

At least in the bad example,
your code acknowledges that the purpose of
the cast is to convert the value to the type
of the object receiving the value.

The whole point of casting a pointer initializer, is to convert the
value
to the type of the object receiving the value.

Recording the type history of the value,
is not the purpose of the cast.

But you weren't casting the pointer value argv[n], you were
reinterpreting its bit pattern, by casting a pointer to argv[n].
That's
what the second example does
(except for the actual dereference). That's
what you shouldn't do.

static int
cmpstringp(const void *p1, const void *p2) {
return strcmp(* (char * const *) p1, * (char * const *) p2);
}

cmpstringp will be called by qsort as, for example,
cmpstringp(&argv[1], &argv[2]);

argv[n] is of type char *.
So p1 and p2 are pointers to a char *. So they
should be dereferenced as pointers to char *. If you want to get a
const char *, you can convert the value _after_ dereferencing.

OK.
I'm thinking about it now.
Thank you.

--
pete

[pete]

pete wrote:

>
CBFalconer wrote:

The only thing affected is the cmp function, and now the void*
parameters make the central block (that manipulates the list,
including sorting) much simpler and a constant library entry. The
only thing needed in the actual cmp function is something like:

int acmp(const void *litem, const void* ritem) {
const whatever ldptr = litem, rdptr = ritem;

It's not "const whatever",
it's always going to be "const nodeptr".

The way that your mergesort and mergelist functions
call the cmp function,
the argument is always going to be a nodeptr value,
and the only way that the cmp function can use that value
is as a nodeptr value.

... code using ldptr and rdptr ...
}

That's the point.
With nodeptr parameters instead of void * parameters,
the equivalent cmp function becomes:

int acmp(const nodeptr litem, const nodeptr ritem) {
... code using litem and ritem ...
}

... which is a simpler way to write it.

--
pete

[pete]

pete wrote:

>
pete wrote:

CBFalconer wrote:

The only thing affected is the cmp function, and now the void*
parameters make the central block (that manipulates the list,
including sorting) much simpler and a constant library entry. The
only thing needed in the actual cmp function is something like:
>
int acmp(const void *litem, const void* ritem) {
const whatever ldptr = litem, rdptr = ritem;

It's not "const whatever",
it's always going to be "const nodeptr".

... code using ldptr and rdptr ...
}

Because the code using ldptr and rdptr ...,
is always going to be (ldptr -data) and (rdptr -data).

--
pete

[CBFalconer]

pete wrote:

CBFalconer wrote:

>pete wrote:

.... snip ...

>>

>>The various cmp functions are simpler to write when they have
nodeptr parameters, than they are when they have (void *) parameters.

The only thing affected is the cmp function, and now the void*
parameters make the central block (that manipulates the list,
including sorting) much simpler and a constant library entry. The
only thing needed in the actual cmp function is something like:

int acmp(const void *litem, const void* ritem) {
const whatever ldptr = litem, rdptr = ritem;

... code using ldptr and rdptr ...
}

That's the point.
With nodeptr parameters instead of void * parameters,
the equivalent cmp function becomes:

int acmp(const nodeptr litem, const nodeptr ritem) {
... code using litem and ritem ...
}

... which is a simpler way to write it.

You have once more totally ignored the need to keep the node
maneuvering code independant yet linkable. This absolutely
requires the void* parameters.

I suspect I would not like to have to service any fairly
complicated system designed by you. I do not intend to keep on
repeating the same reasons and having them ignored.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com

[pete]

CBFalconer wrote:

>
pete wrote:

CBFalconer wrote:

pete wrote:

... snip ...

>
The various cmp functions are simpler to write when they have
nodeptr parameters,
than they are when they have (void *) parameters.

The only thing affected is the cmp function, and now the void*
parameters make the central block (that manipulates the list,
including sorting) much simpler and a constant library entry. The
only thing needed in the actual cmp function is something like:

int acmp(const void *litem, const void* ritem) {
const whatever ldptr = litem, rdptr = ritem;

... code using ldptr and rdptr ...
}

That's the point.
With nodeptr parameters instead of void * parameters,
the equivalent cmp function becomes:

int acmp(const nodeptr litem, const nodeptr ritem) {
... code using litem and ritem ...
}

... which is a simpler way to write it.

You have once more totally ignored the need to keep the node
maneuvering code independant yet linkable. This absolutely
requires the void* parameters.

I suspect I would not like to have to service any fairly
complicated system designed by you. I do not intend to keep on
repeating the same reasons and having them ignored.

I challenge.

You write a C program that sorts a linked list with your
generic list sorting functions.

I'll rewrite it, making only two changes;
1 The parameters on the cmp function will be changed
from void * to nodeptr.
2 The cmp function definition will be simplified.

If the (void *) parameters on the cmp function
are really needed for anything,
then you should be able to come up with
program that I can't convert.

If you won't,
it's because you know that you can't.

--
pete

[Martien Verbruggen]

On Sat, 01 Dec 2007 18:24:11 -0500,
CBFalconer <cb********@yahoo.comwrote:

Martien Verbruggen wrote:

>>

... snip ...

>>
Also, the input is an array, not a linked list, and a good
assumption would be that the array should be sorted in place, or
at least that the output should be a sorted array. Translating it
into a linked list, sort, and then translating back, is by no
means simpler than just using a method that acts directly on the
data structure at hand.

I did NOT recommend converting arrays to lists.

The OP, however, has an array. So they would have to convert, even if
you don't recommend it.

Martien
--
|
Martien Verbruggen | It's not what we don't know that hurts us,
| it's what we know for certain that just ain't
| so. -- Mark Twain

[Barry Schwarz]

On Sat, 01 Dec 2007 15:37:33 +0530, santosh <sa*********@gmail.com>
wrote:

>aa*****@gmail.com wrote:

>On Nov 30, 9:44 pm, Ian Collins <[e-mail]:

>>[e-mail] wrote:
How do I sort an string array using pointers

How do you think? Post an attempt and you will get help.

--
Ian Collins.

what about this attempt

snip abominable code

>Please do submit this to:

<http://ioccc.org/>

Since it doesn't compile, why bother?
Remove del for email

[CBFalconer]

pete wrote:

>

.... snip ...

>
I challenge.

You write a C program that sorts a linked list with your
generic list sorting functions.

I'll rewrite it, making only two changes;
1 The parameters on the cmp function will be changed
from void * to nodeptr.
2 The cmp function definition will be simplified.

If the (void *) parameters on the cmp function are really needed
for anything, then you should be able to come up with program
that I can't convert.

If you won't, it's because you know that you can't.

The problem is not just the one program. It is the one or ten
dozen further programs that use the same list and sorting module,
unchanged, and which programs do all sorts of different things.
Not only do you want to write portable code, you want to write
reusable portable code.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[pete]

CBFalconer wrote:

>
pete wrote:

... snip ...

I challenge.

You write a C program that sorts a linked list with your
generic list sorting functions.

I'll rewrite it, making only two changes;
1 The parameters on the cmp function will be changed
from void * to nodeptr.
2 The cmp function definition will be simplified.

If the (void *) parameters on the cmp function are really needed
for anything, then you should be able to come up with program
that I can't convert.

If you won't, it's because you know that you can't.

The problem is not just the one program. It is the one or ten
dozen further programs that use the same list and sorting module,
unchanged, and which programs do all sorts of different things.

I've got three of them right here:
http://www.mindspring.com/~pfilandr/.../string_sort.c
http://www.mindspring.com/~pfilandr/...es/file_sort.c
http://www.mindspring.com/~pfilandr/...s/file_parse.c

Not only do you want to write portable code, you want to write
reusable portable code.

The associated files are here:
http://www.mindspring.com/~pfilandr/...les/list_lib.h
http://www.mindspring.com/~pfilandr/...les/file_lib.h
http://www.mindspring.com/~pfilandr/...les/list_lib.c
http://www.mindspring.com/~pfilandr/...les/file_lib.c

--
pete