const type question

[herrcho]

int intcmp(const void *a, const void *b)
{
return (*(int*)a - *(int*)b);
}

in the above , if i put just 'void' instead of 'const void' as a
parameter,

what's the difference ?

i can't get the meaning of const when used in parameter..

Thanks in advance ~

[Richard Bos]

"herrcho" <he*********@ko rnet.net> wrote:

int intcmp(const void *a, const void *b)
{
return (*(int*)a - *(int*)b);
}

in the above , if i put just 'void' instead of 'const void' as a
parameter,

what's the difference ?
Nothing, since you're not trying to change anything anyway.
i can't get the meaning of const when used in parameter..

If a parameter is declared const, the function cannot change it. This
sounds like it's no change, since a function cannot change a the value
of a parameter in the caller anyway. However, if the parameter is const,
the function cannot even change its value _within the function_.
If a parameter is a pointer to a const type, the function cannot change
the object the pointer points at.

If you don't modify anything in the function to begin with, this doesn't
matter, of course. However, the above looks like a comparison function
for qsort() (or bsearch()). In that case, the consts are there to
prevent you from changing the objects behind qsort()'s back, since doing
so could mess up the sorting algorithm.

Richard

[Simon Biber]

"herrcho" <he*********@ko rnet.net> wrote:

int intcmp(const void *a, const void *b)
{
return (*(int*)a - *(int*)b);
}

in the above , if i put just 'void' instead of 'const void' as a
parameter,

what's the difference ?
If you're intending to pass this function to qsort or something
that expects a parameter of type int(*)(const void*,const void*)
then you must not change from const void to void, this will be
a constraint violation (wrong type of argument) or else undefined
behaviour (if you say cast it back to the right type).
i can't get the meaning of const when used in parameter..

When used as 'const type *a' it means that you are not allowed to
modify the thing that the pointer is pointing to. Unfortunately
due to the bad way you wrote the function this protection is lost
when you cast the argument to (int*). You can in fact write any
qsort compare function in a completely typesafe manner with no
casts, which is much cleaner code:

int intcmp(const void *va, const void *vb)
{
const int *a = va, *b = vb;
return *a - *b;
}

That way you will get a diagnostic message from the compiler if
you accidentally attempt to modify the contents of the memory.

--
Simon.

[CBFalconer]

Simon Biber wrote:

.... snip ...
When used as 'const type *a' it means that you are not allowed to
modify the thing that the pointer is pointing to. Unfortunately
due to the bad way you wrote the function this protection is lost
when you cast the argument to (int*). You can in fact write any
qsort compare function in a completely typesafe manner with no
casts, which is much cleaner code:

int intcmp(const void *va, const void *vb)
{
const int *a = va, *b = vb;
return *a - *b;
}

That way you will get a diagnostic message from the compiler if
you accidentally attempt to modify the contents of the memory.

Totally agree, EXCEPT for the actual comparison in your example,
which is liable to problems from integer overflow. This is a good
place for:

return (*a > *b) - (*a < *b);

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Simon Biber]

"CBFalconer " <cb********@yah oo.com> wrote:

Simon Biber wrote:

int intcmp(const void *va, const void *vb)
{
const int *a = va, *b = vb;
return *a - *b;
}

That way you will get a diagnostic message from the compiler if
you accidentally attempt to modify the contents of the memory.

Totally agree, EXCEPT for the actual comparison in your example,
which is liable to problems from integer overflow. This is a good
place for:

return (*a > *b) - (*a < *b);

Yes, my mistake. In fact I usually write it like the equivalent:
return (*a < *b) ? -1 : (*a > *b);

But I prefer your subtraction form, because in the rather arbitrary
and unjustified model of code microefficiency in my head, a subtract
is faster than a compare. This may or may not be true on any of the
platforms I compile for, I wouldn't know.

--
Simon.

[Peter Nilsson]

"Simon Biber" <ne**@ralminNOS PAM.cc> wrote in message
news:3f******** *************** @news.optusnet. com.au...

You can in fact write any
qsort compare function in a completely typesafe manner
How? The function itself can never guarantee that it won't be applied to a
type that differs from the intended one.
with no casts, which is much cleaner code:

Cleaner perhaps, but an absense of casts is not typesafety.

--
Peter

[pete]

Simon Biber wrote:

"CBFalconer " <cb********@yah oo.com> wrote:

Simon Biber wrote:

int intcmp(const void *va, const void *vb)
{
const int *a = va, *b = vb;
return *a - *b;
}

That way you will get a diagnostic message from the compiler if
you accidentally attempt to modify the contents of the memory.

Totally agree, EXCEPT for the actual comparison in your example,
which is liable to problems from integer overflow. This is a good
place for:

return (*a > *b) - (*a < *b);

Yes, my mistake. In fact I usually write it like the equivalent:
return (*a < *b) ? -1 : (*a > *b);

But I prefer your subtraction form, because in the rather arbitrary
and unjustified model of code microefficiency in my head, a subtract
is faster than a compare. This may or may not be true on any of the
platforms I compile for, I wouldn't know.

I see two unconditional comparisons and a subtraction
in the first,
but only two comparisons, with one of them being conditional,
in the second.

--
pete

[CBFalconer]

pete wrote:

Simon Biber wrote:

"CBFalconer " <cb********@yah oo.com> wrote:

Simon Biber wrote:

> int intcmp(const void *va, const void *vb)
> {
> const int *a = va, *b = vb;
> return *a - *b;
> }
>
> That way you will get a diagnostic message from the compiler if
> you accidentally attempt to modify the contents of the memory.

Totally agree, EXCEPT for the actual comparison in your example,
which is liable to problems from integer overflow. This is a good
place for:

return (*a > *b) - (*a < *b);

Yes, my mistake. In fact I usually write it like the equivalent:
return (*a < *b) ? -1 : (*a > *b);

But I prefer your subtraction form, because in the rather arbitrary
and unjustified model of code microefficiency in my head, a subtract
is faster than a compare. This may or may not be true on any of the
platforms I compile for, I wouldn't know.

I see two unconditional comparisons and a subtraction in the first,
but only two comparisons, with one of them being conditional,
in the second.

However the emitted code will often not have any jumps in it (for
the first), which avoids flushing any instruction queues. I
learned it from someone, and consider it a trick worth knowing.

The point is that they are both safe, and have a chance to
simultaneously be efficient and clear. However there may be
considerable code involved in converting a machine comparison into
the 0 or 1 representation, in which case the ?: coding will be
superior.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[pete]

CBFalconer wrote:

pete wrote:

Simon Biber wrote:

"CBFalconer " <cb********@yah oo.com> wrote:
> Simon Biber wrote:

> > int intcmp(const void *va, const void *vb)
> > {
> > const int *a = va, *b = vb;
> > return *a - *b;
> > }
> >
> > That way you will get a diagnostic message from the compiler if
> > you accidentally attempt to modify the contents of the memory.
>
> Totally agree, EXCEPT for the actual comparison in your example,
> which is liable to problems from integer overflow. This is a good
> place for:
>
> return (*a > *b) - (*a < *b);

Yes, my mistake. In fact I usually write it like the equivalent:
return (*a < *b) ? -1 : (*a > *b);

But I prefer your subtraction form,
because in the rather arbitrary
and unjustified model of code microefficiency in my head,
a subtract is faster than a compare.
This may or may not be true on any of the
platforms I compile for, I wouldn't know.

I see two unconditional comparisons and a subtraction in the first,
but only two comparisons, with one of them being conditional,
in the second.

However the emitted code will often not have any jumps in it (for
the first), which avoids flushing any instruction queues. I
learned it from someone, and consider it a trick worth knowing.

The point is that they are both safe, and have a chance to
simultaneously be efficient and clear. However there may be
considerable code involved in converting a machine comparison into
the 0 or 1 representation, in which case the ?: coding will be
superior.

Thank you.

--
pete

[dam_fool_2003]

"Simon Biber" <ne**@ralminNOS PAM.cc> wrote in message news:<3f******* *************** *@news.optusnet .com.au>...

"herrcho" <he*********@ko rnet.net> wrote:

int intcmp(const void *a, const void *b)
{
return (*(int*)a - *(int*)b);
}

in the above , if i put just 'void' instead of 'const void' as a
parameter,

what's the difference ?
If you're intending to pass this function to qsort or something
that expects a parameter of type int(*)(const void*,const void*)
then you must not change from const void to void, this will be
a constraint violation (wrong type of argument) or else undefined
behaviour (if you say cast it back to the right type).

i can't get the meaning of const when used in parameter..

When used as 'const type *a' it means that you are not allowed to
modify the thing that the pointer is pointing to. Unfortunately
due to the bad way you wrote the function this protection is lost
when you cast the argument to (int*). You can in fact write any
qsort compare function in a completely typesafe manner with no
casts, which is much cleaner code:

int intcmp(const void *va, const void *vb)
{
const int *a = va, *b = vb;
return *a - *b;
}

Friends,
Don't we have to cast a void* so that the void points to a valid
value (as per 6.3.2.3 of the standard). (Correct me if I am wrong):

int fun(const void *a, const void *b)
{
unsigned int *p , *q;
p =(unsigned int*) a, q =(unsigned int*) b;
/*return (*p > *q ) - (*p < *q); */
return *p - *q;
}
int main(void)
{
int a=2,b=2,c=8,d=6 ;
printf("%d %d\n",fun(&a,&b ),fun(&c,&d));
return 0;
}

OUTPUT:

0 2

And for the second one:

int fun(const void *a, const void *b)
{
unsigned int *p , *q;
p =(unsigned int*) a, q =(unsigned int*) b;
return (*p > *q ) - (*p < *q);
/*return *p - *q; */
}
int main(void)
{
int a=2,b=2,c=8,d=6 ;
printf("%d %d\n",fun(&a,&b ),fun(&c,&d));
return 0;
}

OUTPUT:
0 1

Is there any UB?

That way you will get a diagnostic message from the compiler if
you accidentally attempt to modify the contents of the memory.