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.
Related
I recently read an article which said it's not necessary in C to explicitly typecast malloc and calloc but in C++ it is mandatory. Why is it so? Can anyone explain?
Because in C it is very often you need to use void * for various cases. Some of them is a cookie for a callback - when you provide pointer to user data and you do not have a way to know that data type. Or generic functions like qsort() they have to work with various data without knowing their type in advance. In C++ though you do not need to use void * as often, and in good safe code you do not need to use them at all because you have templates so you write generic code using unknown types without unsafe conversions. So creators of C++ wanted to stimulate proper usage of data types and make sure when developer doing unsafe operations he/she/it/they understands what he/she/it/they is doing.
As malloc() and calloc() return void * you have to convert them explicitly in C++. Note that you are not suppose to use them in C++, but use operator new instead - which returns proper pointer type already and you do not need cast. And even further in modern C++ it is not recommended to even call new directly.
In C, it's given T *tp; U *up; void *vp;, one can say vp = tp; up = vp; and end up with a U* which holds the address of a T, without using any casting operators. The designers of C++, however, wanted to ensure that such a thing couldn't happen without using at least one explicit casting operator somewhere along the way. In most cases, requiring the casting operator to be used between the time the pointer is represented as a void* and the time it's actually used is less of a nuisance than requiring a casting operator when a pointer is converted to void*, that's what C++ does. Neither C or C++ allows any syntactic distinction between a void* which was produced by converting the address of an object with a real type, however, versus one that is used to hold the address of a blob of storage with no type, and thus has no way of allowing the latter to be implicitly converted to any type (which would be useful) without doing likewise with the former (which the designers of C++ didn't want).
As far as I know each polymorphic class in C++ contains a string with a mangled type name. And RTTI is implemented by string comparison.
Is this true? Would it be more efficient to implement a centralized type storage instead?
With centralized type storage each object can just hold a pointer to type information. Dynamic casts can be implemented simply by pointer comparison.
The actual implementation is even more efficient than one pointer per object.
The Standard forbids adding any data to "standard layout" classes, so there's not even room for a pointer, let alone a string. For polymorphic classes, there will be extra metadata, but in real-world implementations, all data specific to the dynamic type of the object is stored together, and there's just one pointer needed to all of it.
As a result, because polymorphic objects already need a pointer to the virtual function dispatch table, there is zero incremental per-object cost to storing the type name. There just an extra pointer stored in the v-table alongside the function pointers, so the cost is one pointer per polymorphic type no matter how many instances exist.
Polymorphic classes contain what the compiler builder considered worthy putting in them, there is no rule or requirement to have any type information.
The concept of C++ is strongly typed, and the checking id to be done by the compiler. The compiled code is typically optimized for performance and/or size, and not to carry information that shouldn’t be needed.
Of course, some compilers offer this, but that is not the spirit of the language.
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'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.
My question is simple: What are void pointers for in C++? (Those things you declare with void* myptr;)
What is their use? Can I make them point to a variable of any type?
Basically, a remnant from C.
What is their use?
In C, they were and are used widely, but in C++ I think they are very rarely, if ever, needed, since we have polymorphism, templates etc. which provide a much cleaner and safer way to solve the same problems where in C one would use void pointers.
Can I make them point to a variable of any type?
Yes. However, as others have pointed out, you can't use a void pointer directly - you have to cast it into a pointer to a concrete data type first.
Yes, this is a C construct (not C++-specific) that allows you to declare a pointer variable that points to any type. You can't really do much of anything with such a pointer except cast it back to the real object that it actually points to. In modern C++, void* has pretty much gone out of fashion, yielding in many cases to template-based generic code.
About one of the few uses that exist for void pointers in C++ is their use in overloading the new operators. All new operators return type void* by definition. Other than that, what others have said is true.
From cplusplus.com:
The void type of pointer is a special
type of pointer. In C++, void
represents the absence of type, so
void pointers are pointers that point
to a value that has no type (and thus
also an undetermined length and
undetermined dereference properties).
This allows void pointers to point to
any data type, from an integer value
or a float to a string of characters.
But in exchange they have a great
limitation: the data pointed by them
cannot be directly dereferenced (which
is logical, since we have no type to
dereference to), and for that reason
we will always have to cast the
address in the void pointer to some
other pointer type that points to a
concrete data type before
dereferencing it.
Type hiding. It does still have its valid uses in modern C++. Dig through the source code in boost and you'll find a few. Generally the use of a void* is buried very deep within the bowels of a more complex construct that ensures the type safety of the interface while doing black and evil magic within.
They did once in C perform the job of being the pointer-to-anything, a pointer you passed in to libraries and they gave back out to you as userdata. A void* is no use at all without the programmer knowing their context in some fashion, since you don't know what's on the other end, you can't do anything with the data. Except pass the pointer to some other code that does know.
What I don't understand is why people didn't just use undefined types, i.e. opaque pointers. Type safety, user data.
In modern C++, the pointer-to-void is nearly entirely superseded by polymorphism and template-generated generic code. However, you may still have to use them to interface with native C code. To use a void* safely, in any given context, only ever cast one type to a void*. That way, you know for sure what it points to. If you need more types, you could do a quick
struct safevoidptr {
base* ptr
}; or struct safevoidptr { void* ptr; int type; };
I believe that dynamic_cast might also be able to convert void* to polymorphic types, although I have never used dynamic_cast, so don't take my word for it.
A void pointer can point to anything, as long as its memory :-)
The C standard states that you can convert any pointer to a void-pointer, then cast it back without losing anything.
A pointer to void is the closest concept to an assembly language pointer. It is a generic pointer that reserves space for an address or location of something (function or datum). As others have stated, it must be cast before it can be dereferenced.
The void pointer is a popular tool for representing Object Orient concepts in the C language. One issue with the void pointer is that the content may not match the receiver's perception. If the caller sets the pointer to point to a square, but the receiving function is expecting a pointer to a cat, undefined and strange things will happen with the pointer is cast.
Since there are already so many good answers, I'd just provide one of the more common one I saw: template specialization. If I don't recall wrongly, Stroustrup book has an example of this: specializing vector as vector, then having vector to derive (privately) from vector. This way, vector will only contain straightforward easily inlined codes (i.e. call relevant functions from vector). This will reduce the number of duplication when vector is compiled in a program that uses it with many different types of pointers.
void ptr is basically an empty box. Fill it with whatever you want but make sure you label it(tupecasting)
I use them in my dynamic lists to hold more types of objects (all are pointers).
typedef void* Object;
Then when you declare a Object variable you can store any pointer in it.
It's more or less usefull depending on the needs.
I find it very usefull when you have to store any pointer somewhere and you can't just derive all your classes from just one. Other than that as the others said it's better to use templates, polimorphism etc.
Things you could do in C with void, but can't in C++ :
void*'s are automatically converted to other pointer types. (You know its a void* - you gain no type safety from forcing an explicit cast)
Struct* p = malloc( sizeof(Struct) );
// vs C++
Struct* p = (Struct*)malloc( sizeof(Struct) );
// Some will argue that that cast style is deprecated too, and c++ programmers
// need to actually do this:
Struct* p = reinterpret_cast<Struct*>malloc( sizeof(Struct) );
// See what C++ did there? By making you write Struct a 3rd time, you can now be sure
// you know what you are doing!
void*'s also did indirection counting in C, allowing greater safety when passing pointers to functions that take a pointer to a pointer.
void funcInitializingOutPtr( void** ppOut)
{
*ppOut = malloc( x );
}
int* out = NULL;
funcInitializingPtr(out); // C would signal this as an error
funcInitializingPtr(&out); // correct
// vs C++
funcInitializingPtr( (void**)&out ); // so much safer needing that exlicit cast.
funcInitializingPtr( (void**)out); // oops. thanks C++ for hiding the common error
I belive void* is memory location where you can typecast/Store anything. I some Language Pundit will disagree on this with me. but i have used it successfully in many of my project.
Only problem i see is of typesafety