Thread: help needed with void pointers.

Hi, I'm trying to create a generic link list. Here's the data structure for node:

Code:

typedef struct node_s
{ 
   void *data;
   struct node_s *next;
}node;

Now let's say I want the data pointer to point to a vector structre:

Code:

typedef struct
{
  double coord[3];
}vector;

I can assign data (of some random node in list) address of some vector:

Code:

p->data = &v

p is pointer to node in link list and v is the vector.

But when I try an operation like this for eg:

Code:

  p->data->coord[0]  < p->data->coord[1]

It gives me an error. Is there any way I can solve this ?

Originally Posted by MacGyver

You have to cast the void * back to another pointer type before you can dereference it.

This

Code:

 vector *a = (vector *) p->ptr;
 vector *b  = (vector *) p->ptr;

a->coord[0] < b->coord[0]

did the trick. Is this what you are trying to say ?

Originally Posted by MacGyver

You have to cast the void * back to another pointer type before you can dereference it.

Ok is there any way I can let a function know about the type to which void must be casted to ?
I wanted to make the program as general as possible.

You can make a function that has a parameter for the type. Then for assigning things to the list:

Code:

#define TYPE v

void svdata(node *node, void *p, int type)
{
     vector *v; int *i; double *d;
     switch(type) {
     case 'v':
              v = (vector *)p;
              node->data = v;
              ....
     case 'd':
          ......
}

now:
next(node, my_vector, TYPE)

If you want to make a linked list for multiple types then each node has to include the type.

You could always make a struct that has a lot of pointers instead of void. Assign everything NULL so you can check which data is used. If you don't need a high efficiency then you indeed have a multiple type linked list. With some limitations

Well, generally you cannot make a generic list in C. There is no way without having some cost in efficiency, I believe.

I believe what I proposed is the most efficient in matter of speed. The downside is that you will have to use functions for a lot of things. Like even printing the data, since you don't know for example if it a float or an int. But that isn't hard, and the functions with the lot of if's can be stored in another file, so you won't have that long code.

The problem is if you wanted a linked list with multiple types, which isn't supported even by some languages that have real polymorphism (like Haskell). Then you will need to add as McGyver said another int or enum on the node and again have functions read it.

If you didn't want to have a bad-pseudo-polymorphism then you would have to make a node for every data type you use. That will also need more code. Then you will have functions for every type. You would probably copy-paste a lot of things and get again bugs and lose time.

What McGyver suggested as an idea is better. But practically it might be worse. Your program will know what data types it uses. But what if you want to change the main program? You will have to change everything that has to do with types (though you could find-replace easily). And it would have more code, since it will have all the castings.

Having the casting and type decision in separate functions would make the main program more readable. For example:

Example:

Code:

#define T1 long double
#define T2 int
#define ....

if (strcmp("T1", float) == 0)
   printf("%f", i);
else (strcmp("T1", int) == 0)
   printf("%d", i);

etc etc

then the same for T2, probably for T3

You would make a function anyway to printf what you want. So why not do everything you want in the function and save code from the main program?
Though, everything depends on what you want

If you didn't then you would have to change everything in the main program. Bugs...

In C, a linked list that deals with nothing but void pointers *is* a generic list. The language just isn't well suited for imparting meaningful type information within the list abstract data type. Which is why pushing out type-related responsibilities to the user of the list makes sense. Which really means that each user of the list simply casts to the type of object that was originally inserted.

Now you have a single copy of the list code - multiple users of the list (even within the same compilation unit) - and no additional overhead.

>> though you could find-replace easily
Changing a single typedef is even easier

gg

Well, you are focusing more on making a "library" that will be useful for everyone and everything. I am more considered on having a main program + libraries that everyone will use. So you wouldn't want to change a lot the main program. Just add maybe something. Or change the datatypes and some line of code.

That's why I said it depends. If you want a library with a linked list that is functional and useful then you just leave the user to do the casting. If you want though a main program that does something to a linked list with a certain datatype, when the datatype can be changed, it is safer and more appropriate to make sure with a function that you will get the desired result. Depending on the user to change the printf()s and the casting isn't I believe the best solution. What if he forgets something? In C that means a big error because the program might run nicely with mixed casting. With a function you would change only the functions parameter (a simple replace).

Void is polymorphic but incomplete in a way. It lets you assign a value not use it though without casting it. You can make all sort of mistakes. Have the void pointer point at a long double. Change it to point to a character. Forget to change a casting so something is casted to long double. It pointed to 1byte and now you will read 12bytes. Lots and lots of bad things.
In Java for example a "pointer" to an Object is like void in a way. You can point at any object. But when you cast it to what you want I assume you are safe, because the thing you are pointing at will have to have the appropriate type or the compiler can find the mistake. In C such a thing won't be checked, since C has a different logic.