Note that the ANSI C function memchr already takes a const void *,
so at least this is not something new in the C++ standard.

A simple question, hopefully noncontroversial:

Is this meaningful?

void foo(const void* p);

and, if so, how does it differ from this?

void foo(void* p);

With one compiler of my acquaintance, qsort expects a

typedef int (*fptr) (void*, void*);

argument, but with another, it expects a

typedef int (*fcptr) (const void*, const void*);

This makes the portable use of qsort difficult.  The idea of "const
void" seems nonsensical, but maybe I'm missing something.

Doug Moore
(dougm@cs.rice.edu)

In article <DOUGM.93Oct12013737@cs.cs.rice.edu>,
Doug Moore <dougm@cs.cs.rice.edu> wrote:
>A simple question, hopefully noncontroversial:
>
>Is this meaningful?
>
>void foo(const void* p);

Yes.

>and, if so, how does it differ from this?
>
>void foo(void* p);

The first form simply guarantees that you will not change the value
of whatever the pointer points to.  The implication with a void *
argument is that the function will convert the pointer to some usable
type.  The const qualifier just says it won't change the value after
doing so.

>With one compiler of my acquaintance, qsort expects a
>
>typedef int (*fptr) (void*, void*);
>
>argument, but with another, it expects a
>
>typedef int (*fcptr) (const void*, const void*);

The first version is incorrect.  The qsort function is defined in the C
standard to accept a function pointer of the latter type.  Send a bug report
to your compiler or OS vendor, and fix the header file.

- Brad
--
----------------------------------------------------------------------
+ Brad Daniels   | "Let others praise ancient times;  +
+ Biles and Associates  |  I am glad I was born in these."   +
+ These are my views, not B&A's |   - Ovid(43 B.C - 17 A.D)    +

In article <DOUGM.93Oct12013737@cs.cs.rice.edu> dougm@cs.cs.rice.edu (Doug Moore) writes:
>A simple question, hopefully noncontroversial:
>
>Is this meaningful?
>
>void foo(const void* p);
>
>and, if so, how does it differ from this?
>
>void foo(void* p);
>
>The idea of "const void" seems nonsensical, but maybe I'm missing something.

 First, the current WP supports the notion of

 const void*

Presumably, the idea is that :

 const char* p = "Hi there";
 void* x = p; // error

I think this is misguided because it only works for the top
level const, and it (may) mean that pointer managers
require several methods to deal with

 void*
 const void*
 volatile void*
 const volatile void*

In any case, since you have to cast out of a void* anyhow, you
can always throw away const:

 const volatile void* x = p;
 ... (char*)p

so the 'const void*' doesnt offer any protection, and just
gets in the way of routines that want to store addresses.
In effect, you can always do this:

 void* x = (void*)(const volatile void*)p;

and it seems simpler to me to just allow a void* to accept
any pointer type and get rid of const void*.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA