I'm writing a delegate class for educational purposes and have run into a little problem. The delegate must be able to call not only functions but also member methods of objects, which means that I need to store a pointer to a method:
void (classname::*methodPtr)(...);
And I need to store pointers to methods from different classes and with different argument lists. At first I just wanted to cast the method pointer to void *, but the compiler dies with an invalid cast error. Turns out that sizeof(methodPtr) == 8 (32-bit system here), but casts to unsigned long long also fail (same compiler error - invalid cast). How do I store the method pointer universally then?
I know it's not safe - I have other safety mechanisms, please just concentrate on my question.
You don't. You use run-time inheritance, if you need abstraction, and create a derived class which is templated on the necessities, or preferably, just create a plain old functor via the use of a function. Check out boost::bind and boost::function (both in the Standard for C++0x) as to how it should be done- if you can read them past all the macro mess, anyway.
You better listen to DeadMG. The problem is, that the size of a member pointer depends on the class type for which you want to form the member pointer. This is so, because depending on the kind of class layout (for example if the class have virtual bases and so on) the member pointer has to contain various offset adjustment values - there is no "one size fits all" member pointer type you can count on. It also means, that you can not assume to have a "castable" integral type which can hold every possible member function pointer.
Related
void actually is not a specific type. So how can the system determine the end of the memory block thus cipher the value of the data block? surely you can change the type from void to specific type if you know the data in the memory, but when you don't? What's the purpose for the language designer to make this concept?
This was used mainly in C to pass data to callback functions or to build generic containers. It is used, whenever you want to abstract from the concrete data type. The type "void *" is just able to pass pointers on, sometimes that's all you need.
But you are right, if you want to actually access the data, you have to cast the pointer type back to a concrete data type at some point. So some code has to actually remember the type (and it has to get it right, otherwise you just read rubbish!). But not all the code has to know the type. Some functions can just refer to it as "void *" and therefore be more abstract: The same implementation of e.g. a linked list can then be used to contain strings or matrices or whatever you want, without having to reprogram the list code for every type.
In C++ you can avoid the potentially unsafe casting by using inheritance (interfaces) in the case of callback data or templates in the case of containers.
Btw. in C/C++ in many cases you cannot actually know the "end of the data block", that's not special to the "void *" pointers. That is why there are so many dangerous buffer overflows.
So how can the system determine the end of the memory block thus cipher the value of the data block?
It can't. It's up to you to know what type is there, and cast the pointer appropriately to access it.
but when you don't?
Then you can't use void*.
What's the purpose for the language designer to make this concept?
It's a hangover from C, where it is the only way to pass a generic type around. For example, the qsort library function uses it to pass pointers to arbitrary types through to the user-provided comparison function; it's up to the user to know what the real type is, and cast the pointers back to perform the comparison.
In C++, it serves little purpose - there are more reliable ways (including templates and inheritance-based polymorphism) to support generic types. For example, the equivalent std::sort is a template, and preserves the correct type throughout.
As for my experience, i'll say it's like a joker, it allow you to pass a pointer to a function without knowing the type of the pointer. For example, in C, a "generic" implementation of linked list would have a void * pointer to the data, allowing multiple data type to be added
It's used as a placeholder. Eventually the pointer will be passed to a function that does know what the actual type will be.
An example is a generic sorting function. It takes an array, which can contain any type (so this is void*), and a comparison function. The comparison function should be appropriate to the type of the array, so it will cast the void* pointer to the correct type* before dereferencing the values.
This is mostly a holdover from C. In C++, it's common to use templates for this.
I'm working on a Box2d project.
In a particular class constructor, I do:
this->body->SetUserData(this);
where body is a member of this class. body is of type b2Body.
Later on, I call a method:
body->GetUserData();
GetUserData() returns void*
How do I determine what type of class void* is pointing to ?
EDIT: For those who don't use Box2d, you can set the user data to your wrapper class which holds all the non-physics related logic etc, while b2Body represents a physics body.
EDIT: For example, in Objective-C , one would cast void* to NSObject* and then call isMemberOf to determine whether it is of a particular type.
There's nothing intrinsic to C++ which will let you determine the type pointed to by a void*. Your best options are probably:
Make an abstract base class which all your userdata items will derive from. Maybe you already have one. Then you can assume the void* will always be a type derived from that base, and use it accordingly.
Make a discriminated union type (or use Boost.Variant), and always have the void* point to one of those.
Make a small struct which the void* will always point to an instance of, and make that struct be the first member of everything you assign to the void* (this will only work if you're doing more C-style programming, and the classes have no bases to interfere with the alignment).
The short answer, as John Zwinck points out, is you can't.
The use of void* is an old C trick how to add user configurable data to a library. This is normally used when integrating a middleware library into a bigger software. The basic assumption here is that you know what type is behind the void*. In my experience with wrapping ODE and Bullet, this works out quite well.
There are basically two cases and with each you know what basic type is behind that void*:
In the first case you have a one to one correlation between a body or geometry to an object in the wrapping software. In this case you would simply reinterpret_cast to the wrapping object.
In the second case the body or geometry is contained in some "game object". This can be any object within the scene. But normally all "object within the scene" share a common base class. Here you simply assume that you can reinterpret_cast to the base class. Now you have an object in the hand, what you do from here is up to you. You can either call virtual methods on it, use dynamic_cast or some homebrew reflection.
I had always thought that checking the pointer after casting a void* to a struct* was a valid way to avoid invalid casts. Something like
MyStructOne* pStructOne = (MyStructOne*)someVoidPointer;
if(!pStructOne)
return 0;
It appears that this is not the case as I can cast the same data to two different structs and get the same valid address. The program is then happy to populate my struct fields with whatever random data is in there.
What is a safe way of casting struct pointers?
I can't use dynamic_cast<> as it's not a class.
Thanks for the help!
If you have any control over the struct layout you can put your own type enumeration at the front of every struct to verify the type. This works in both C and C++.
If you can't use an enumeration because not all types are known ahead of time, you can use a GUID. Or a pointer to static variable or member that is unique per struct.
You can use dynamic_cast with structs or classes, as long as it has a virtual method. I would suggest you redesign your broader system to not have void*s anywhere. It's very bad practice/design.
There is no "safe way of casting" in general, because casting pointers is inherently an unsafe procedure. Casting says that you know better than the type system, so you can't expect the type system to be of any help after you started casting pointers.
In C++, you should never use C-style casts (like (T) x), and instead use the C++ casts. Now a few simple rules let you determine whether casting a pointer or reference is OK:
If you const_cast in the bad direction and modify the object, you must be sure that the object is actually mutable.
You can only static_cast pointers or references within a polymorphic hierarchy or from/to void pointer. You must be sure that the dynamic type of the object is a subtype of the cast target, or in the case of void pointers that pointer is the address of an object of the correct type.
reinterpret_cast should only be used to or from a char * type (possibly signed or unsigned), or to convert a pointer to and from an (u)intptr_t.
In every case, it is your responsibility to ensure that the pointers or references in question refer to an object of the type that you claim in the cast. There is no check that anyone else can do for you to verify this.
The (C-style) cast you are using is compile-time operation - that is to say that the compiler generates instructions to modify the pointer to one thing so that it points to another.
With inheritance relationships, this is simply addition or subtraction from the pointer.
In the case of your code, the compiler generates precisely no code whatsoever. The cast merely serves to tell the compiler that you know what you're doing.
The compiler does not generate any code that checks the validity of your operation. If someVoidPointer is null, so will be pStructOne after the cast. \
Using a dynamic_cast<>() doesn't validate that the thing being casted is actually an object at all - it merely tells you that an object with RTTI is (or can be converted to) the type you expect. If it's not an object to start with, you'll most likely get a crash.
There isn't one. And frankly, there can't be.
struct is simply an instruction for the compiler to treat the next sizeof() bytes in a particular semantic fashion - nothing less, nothing more.
You can cast any pointer into any pointer - all that changes is how the compiler would interpret the contents.
Using dynamic_cast<> is the only way, but it invokes RTTI (run type type information) to consider the potential legality of the assignment. Yeah, it's no longer an reinterpret_cast<>
It sounds like you want to make sure the object passed as a void* to your function is really the type you expect. The best approach would be to declare the function prototype with MyStructOne* instead of void* and let the compiler do the type checking.
If you really are trying to do something more dynamic (as in different types of objects can be passed to your function) you need to enable RTTI. This will allow you to interrogate the passed in object and ask it what type it is.
What is a safe way of casting struct pointers?
First, try to avoid needing to do this in the first place. Use forward declarations for structs if you don't want to include their headers. In general, you should only need to hide the data type from the signature if a function could take multiple types of data. The example for something like that is a message passing system, where you want to be able to pass arbitrary data. The sender and receiver know what types they expect, but the message system itself doesn't need to know.
Assuming you have no other alternatives, use a boost::any. This is essentially a type-safe void*; attempts to cast it to the wrong type will throw an exception. Note that this needs RTTI to work (which you generally should have available).
Note that boost::variant is a possibility if there is a fixed, limited set of possible types that can be used.
Since you have to use void*, your options are:
create a single base class including a virtual destructor (and/or other virtual methods) and use that exclusively across the libev interface. Wrap the libev interface to enforce this, and only use the wrappers from your C++ code. Then, inside your C++ code, you can dynamic_cast your base class.
accept that you don't have any runtime information about what type your void* really points to, and just structure your code so you always know statically. That is, make sure you cast to the correct type in the first place.
use the void* to store a simple tag/cookie/id structure, and use that to look up your real struct or whatever - this is really just a more manual version of #1 though, and incurs an extra indirection to boot.
And the direct answer to
What is a safe way of casting struct pointers?
is:
cast to the correct type, or a type you know to be layout compatible.
There just isn't any substitute for knowing statically what the correct type is. You presumably passed something in as a void*, so when you get that void* back you should be able to know what type it was.
I dont see what the following macro is doing? If anyone can help me see it it would be appreciated.
#define BASE_OFFSET(ClassName,BaseName)\
(DWORD(static_cast < BaseName* >( reinterpret_cast\
< ClassName* >(Ox10000000)))-Ox10000000)
If anyone is curious to know where it is coming from, it comes out of the 3rd chapter of Don Box Book Essential COM where he is building a QueryInterface function using interface tables and the above macro is somehow used to find the pointer to the interface vtable of the class, where class is the ClassName implementing the BaseName, although I dont know how it is doing that.
It tells to the compiler: "imagine there a ClassName object at 0x10000000. Where would the BaseName data begin in that object, relative to 0x10000000"?
Think of a memory layout of a class object with multiple bases:
class A: B, C{};
In the memory block that constitutes an A object, there's the chunk of data that belong to B, also a chunk of data that belongs to C, and the data that are specific to A. Since the address of at least one base's data cannot be the same as the address of the class instance as a whole, the numeric value of the this pointer that you pass to different methods needs to vary. The macro retrieves the value of the difference.
EDIT: The pointer to the vtable is, by convention, the first data member in any class with virtual functions. So by finding the address of the base data, one finds the address of its vtable pointer.
Now, about the type conversion. Normally, when you typecast pointers, the operation is internally trivial - the numeric value of the address does not depend on what type does it point to; the very notion of datatype only exists on the C level. There's one important exception though - when you cast object pointers with multiple inheritance. As we've just discussed, the this pointer that you need to pass to a base class method might be numerically different from the one of the derived object's.
So the distinction between static_cast and reinterpret_cast captures this difference neatly. When you use reinterpret_cast, you're telling the compiler: "I know better. Take this numeric value and interpret it as a pointer to what I say". This is a deliberate subversion of the type system, dangerous, but occasionally necessary. This kind of cast is by definition trivial - cause you say so.
By "trivial" I mean - the numeric value of the pointer does not change.
The static_cast is a more high level construct. In this particular case, you're casting between an object and its base. That's a reasonable, safe cast under C++ class rules - BUT it might be numerically nontrivial. That's why the macro uses two different typecasts. static_cast does NOT violate the type system.
To recap:
reinterpret_cast<ClassName* >(OxlOOOOOOO)
is an unsafe operation. It returns a bogus pointer to a bogus object, but it's OK because we never dereference it.
static_cast<BaseName*>(...)
is a safe operation (with an unsafe pointer, the irony). It's the part where the nontrivial pointer typecast happens.
(DWORD(...)-OxlOOOOOOO)
is pure arithmetic. That's where the unsafety doubles back on itself: rather than use the pointer as a pointer, we cast it back to an integer and forget that it ever was a pointer.
The last stage could be equivalently rephrased as:
((char*)(...)-(char*)OxlOOOOOOO)
if that makes more sense.
Remark about magic 0x10000000 constant.
If that constant will be 0, GCC will show warning -Winvalid-offset-of (if it is enabled, of course). Maybe other compilers do something like that.
I'm not talking about a pointer to an instance, I want a pointer to a class itself.
In C++, classes are not "first class objects". The closest you can get is a pointer to its type_info instance.
No. A pointer is the address of something in the memory of the computer at run-time. A class is just a set of instructions to the compiler.
As everyone else have already said, it's not possible to have a pointer to a class.
But if the point is to create a new instance from some class chosen at runtime, you might want to check out the Factory Method (or Abstract Factory) design patterns.
Yes and No. This depends on your context of what you are trying to achieve. If you simply want a pointer to a type then no there is not a way. A type does not live in memory in the sense of a pointer.
There reason I said yes though is some people would consider the virtual table a pointer to a type. It is possible to get this pointer since the virtual table does exist in memory and can be used to invoke virtual methods with a bit of trickery.
Unlike true Object-Based languages, a class is not an object in C++, more is the pity. The closest you can come to "pointer to class" is RTTI:
const std::type_info &info = typeid(object expression);
type_info has name() member finction, and they can be compared to each other.
A "Class" does not exist. The only thing you can point to is the data.
The rest of a "Class" is actually a dispatch table. For each method in the class, the dispatch table has a pointer. That way, the class points to the correct method of your class regardless of what type it's currently cast to. This would be useless to access.
Methods in your class (the things pointed to by the dispatch table) are actually just "Functions" that are passed in your class data pointer. The definition of a method is pretty much that it's a function that takes the classes data as a parameter. In most C-style languages, that data pointer is hidden but referred to as "this".
The methods for your class may be spread all over the codebase. Because of parent classes, you're not likely even find these methods adjacent to each other.
You can't have a (run-time) pointer to a class, but C++ does has a similar compile-time concept: template parameters. Boost has a library dedicated to manipulating them and a traits library for getting information about classes.
Depending upon how you want to think about pointers, you can have a "pointer" to a class, if by pointer you mean some integral value. Boost allows you to register types and assign a unique integer for every type that you register. If the types you are registering are all classes then you can look up at run-time the code necessary to create an object of the type you want, as long as you have the value of the type you want. But in general, classes aren't first class objects in the language and the best you can hope for is to simulate the behavior you want to have.
True, there is no support for reflection/introspection in built in to C++, but there are a number of libraries that will add many of eg java's Class functionality, and allow a programmer to get an object representing a class, create an instance, etc. google c++ reflection.