When to use a void pointer?

Question

I understand the use of void pointer for malloc implementation.

void* malloc  ( size_t size );

Can anyone suggest other reasons or provide

Answer 1

int (*f) (void);
f =(void*) getprocaddress(dll,"myfunction");

to make the compiler happy

Answer 2

Another example of such C "generics", implemented with void *, is a standard qsort function:

void qsort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *));

You can sort an array of any type: int, long, double, char * or some struct pointers...

Answer 3

There is great advantage of using void pointer . Pointer variable is an variable which stores the address of another variable. example:

int a;
int *x= &a;

Now 'x' stores the address of the integer variable.

But this one fails:

float f;
int *x = &f;

Because Integer pointer variable can store only integer variable address. in same manner it applies for other data types.

When you use void * pointer , it gives an edge to store address of any TYPE variable.

void *pointer = &i;
void *pointer = &f;

while retrieving it has to be deferenced.

*((int*)pointer)

So, carefully make use of void pointer.

This might help you, Thank You.

Answer 4

Void pointers are useful when you write code that needs to run on multiple operating systems and needs to be fairly agnostic of underlying framework APIs.

For example, OS X, Windows and Linux all have the basic concept of a window object, but they're all very different. So I have common code that passes them around as void*'s and then platform specific implementations that cast the void* to the native type (HWND, etc).

But, yeah, as others have said in this thread, this sort of thing is certainly to be avoided except where necessary.

Answer 5

If you are interfacing with C code and need to pass through a C++ object, but a C library will only take a generic pointer, then when you retrieve the pointer you need to re-cast it to the proper type.

Void pointers probably shouldn't be used very often, but they can help when you're trying to use a library function that works with arbitrary pointers, and doesn't really care what data is represented by that memory.

Answer 6

In C++, I've found the most compelling use case for void* pointers is to give code the option to store arbitrary "user data" on an object they are already using.

Let's say you've written a class representing a Car, for use in software which does useful things with Car objects (traffic simulation, rental car inventory, whatever). Now let's say you find yourself in a situation where your application wants to keep track of the arbitrary contents of the trunk of a Car. The details of what's stored in the trunk are not important to the Car class, and could be anything -- it really depends on the purpose of the application using the Car class. Enter the void* pointer.

class Car
{
    public:

        // Existing methods of your Car class

        void setContentsOfTrunk(void* contentsOfTrunk);
        void* contentsOfTrunk() const;

    private:

        void* m_contentsOfTrunk;
}

Now, any application using your Car class has the option to attach an arbitrary data object to an existing Car object such that it can be obtained from any code which has the Car object. The contents of the trunk "travel with" the Car object, wherever it goes in your code.

There are two alternatives to using void* in this case.

The first is to template your class based on the type of the trunk contents object:

template <class TrunkContentsType>
class Car
{
    public:

        // Existing methods of your Car class

        void setContentsOfTrunk(TrunkContentsType contentsOfTrunk);
        TrunkContentsType contentsOfTrunk() const;

    private:

        TrunkContentsType m_contentsOfTrunk;
}

This seems unnecessarily invasive. The type of the contents of the trunk are important only to the application. Algorithms and data structures working with Car objects don't care what's in the trunk. By templating the class, you're forcing applications using the class to choose a type for trunk contents, but in many cases the applications don't care about trunk contents either.

The second alternative is to derive a new class from Car which adds a data member and accessors for trunk contents:

class Car
{
    public:

        // Existing methods of your Car class
        // No methods having anything to do with trunk contents.

    private:

        // No data member representing trunk contents.
}

class CarWithTrunkContents
{
    public:

        // Existing methods of your Car class

        void setContentsOfTrunk(TrunkContentsType contentsOfTrunk);
        TrunkContentsType contentsOfTrunk() const;

    private:

        TrunkContentsType m_contentsOfTrunk;
}

The new CarWithTrunkContents class is an application-specific class which adds a data member of the type the application needs to store trunk contents on the car. This also seems unnecessarily heavyweight. Why do you have to derive a whole new class to add an additional piece of data which doesn't affect the behavior of the class? And if it's fairly common for applications using the Car class to want to store trunk contents, why force each application to derive a new class for their particular type of trunk contents?

Finally, while my contrived example of trunk contents maybe paints a vivid picture of arbitrary trunk contents traveling with the Car object, in practice you would likely provide an even more general mechanism for attaching application-specific data to the Car:

class Car
{
    public:

        // Existing methods of your Car class

        void setUserData(void* userData);
        void* userData() const;

    private:

        void* m_userData;
}

This way, an application can attach an object representing trunk contents, or an object representing driver's license and registration, or an object representing rental agreement, or whatever. I've seen this kind of void* pointer referred to as "userData" (i.e. understood by the user of the class), "blindData" (i.e. the class is blind to the contents of the object it carries) or "applicationData" (i.e. data of type and purpose defined by the application).