Virtual variables or constants?

Hi! Is it possible to have virtual variables in a class (they would be stored in the v-table)? Or virtual constants? I know that I could just have a virtual function that returned the variable, but it feels bad to have a function to return the variable when I could just have a variable (if the language would support it!). The reason I'm asking is because I want to index my classes, so that I can easily use the class type as one of two entry keys to a two-dimensional array.

No, there is no such feature. But if you want to map keys to values, then why not use a map?

I don't think it makes any sense to refer to virtual variables unless they are going to be of different types. Which if they are going to be of different types, it's hard to see how you are going to incorporate that in a meaningful way -- eg, only if you had a function in the base class which operated on the variable which is of one class and you want to change that type in the derived class, which I doubt this will work anyway. Certainly this seems like a non-sequitor:

The reason I'm asking is because I want to index my classes, so that I can easily use the class type as one of two entry keys to a two-dimensional array.

Or maybe I misunderstand you?

Originally Posted by Elysia

No, there is no such feature. But if you want to map keys to values, then why not use a map?

Because I can use a virtual function to do the job, which I believe is faster. But I don't know. Using a map was not a bad idea, though.

Originally Posted by MK27

Certainly this seems like a non-sequitor:

Originally Posted by MK27

Or maybe I misunderstand you?

I can give you an example of what I mean:

A container class, cntr, contains a pointer to one of five subclasses of the class sup, which are called c1, c2, c3, c4 and c5. For these five classes c1-c5, the plus operator is defined and returns a cntr for all 25 combinations of them (two arguments, 5^2 = 25); for example is the function operator+(const c1&, const c2&) defined. When two objects a and b, each of the cntr class, are added to each other with the + operator, the result should be the sum of the two objects that are pointed to by the pointers in a and b respectively. Hence, it must be possible to determine which plus operator to use, since there are 25 of them. Letting the v-table choose for you, by using a virtual plus operator, is not sufficient since there are only 5 v-tables which means that only 5 plus operators could be addressed using that method.

However, if the v-table for each subclass c1-c5 contained an index between 0 and 4, corresponding to the class, the index for both of the objects' classes could be looked up and a key to an array containing pointers to all the plus operators could be calculated. The key could then be used to acquire the appropriate function pointer and call the plus operator.

Hmmm. Okay. You might as well use method calls -- gettype() or something then. I'm always uncomfortable with one line functions that just return a static value too, but realistically it's probably no big deal.

I totally understand why you would want to ask if something else is possible.

BUT, just reading thu that again, why not just have one variable inherited from the base class:

Code:

int type;

which would be set to 0-4 in the constructor for each derived class? Then in your + operator function you check the value of "type" for each submitted object and deal with it from there (probably by passing them on to a more specific/appropriate function and returning that).

Originally Posted by MK27

BUT, just reading thu that again, why not just have one variable inherited from the base class which would be set to 0-4 in the constructor for each derived class?

Hm, that's actually pretty smart. It would make each object 4 bytes bigger, but then since the type of the object would be known thanks to the variable, I won't need to have any v-table and the objects won't need to have any pointers to the v-tables, so it evens out. Simple and clean solution. I guess this is how you can do it in C if you want to have something close to virtual functions, isn't it?

Originally Posted by Elysia

No, there is no such feature.

Good to know at least

Thanks to both of you!

Originally Posted by TriKri

Simple and clean solution. I guess this is how you can do it in C if you want to have something close to virtual functions, isn't it?

I suppose that's essentially true. I don't really like the function pointer method of simulating OO in C, I'd rather just write separate functions dedicated to specific typedefs/structs (which C++ classes are a means of organizing code and exploiting the possibilities which arise from that). But you could include a (sub)type indicator and a void pointer containing anything* (sorted by the type indicator). I've never done anything like that, but I think I've seen it done. I suppose it would simulate inheritance, but thinking in terms of "simulation" and OOP terms is not really necessary (it still makes sense).

* lack of a useful void pointer is the absolute worst thing about C++, that was the single dumbest idea in all programming history IMO. I cannot see how the added "type safety" is worth all the work-arounds and templating needed to make up for that. If I could lock Bjlarney S. up in a room, I would not let him out until he agreed to take it back

Originally Posted by MK27

* lack of a useful void pointer is the absolute worst thing about C++, that was the single dumbest idea in all programming history IMO. I cannot see how the added "type safety" is worth all the work-arounds and templating needed to make up for that. If I could lock Bjlarney S. up in a room, I would not let him out until he agreed to take it back

Good joke

Originally Posted by laserlight

Good joke

I reaaaaaaally hope that it was a joke.

TriKri, what you want is commonly referred to as "multimethods" and "multiple dispatch" (or just "binary dispatch" in the two-argument case) in the literature. Searching for those terms might give you some implementation ideas.

I read the Wikipedia article about multiple dispatch; it mentioned the use of visitor patterns, which actually has crossed my mind before. However, I think that the code easily would get messy if I used this kind of help functions, since every operator in every class would need to have an extra help function. So I'd rather use the method with a lookup table containing to get a function pointer, which I also believe is the quickest method. The function would then have to reinterpret_cast the arguments (since all functions would take arguments from the base class).

If you have to reinterpret_cast, you've done something wrong. Nothing less safe than a static_cast should ever be necessary in a multimethod implementation.

I meant that I was going to use static_cast. Thank you.

Using an int type is fastest, but the problem is that it is more easy to mess up. If you want to go on that path make an enumeration with all classes so you wont have to remember 2 = apple.