This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the difference between (type)value and type(value)?
I am mainly a C# developer and so do a lot of explicit casting using syntax like: (type)variable, with (int)100.0004d as an example. As such, when writing code in C++, I often use the same syntax. However, I have seen (and even used) code in other cases where the same cast is achieved using the syntax type(variable) with int(100.0004) as an example.
I was just curious as to what the difference between the two methods were and whether there were any implications in using one over the other.
Example:
double someDouble = 100.00456;
// Cast the double using the (type)variable syntax
int firstCastValue = (int)someDouble;
// Cast the double using the type(variable) syntax
int secondCastValue = int(someDouble);
The two are exactly the same, and this is true for any type.
Personally, I would avoid the first form, (T)x, in favour of an explicit static cast:
y = static_cast<T>(x);
This expresses that you want to convert x to the type T.
The second form is rather more evocative of a constructor call, and that's sometimes preferable:
v = std::vector<int>(10); // not: v = static_cast<std::vector<int>>(10)
To repeat, both forms are entirely equivalent, and it's a matter of taste which you prefer. I would use static cast for "converting" and constructor-syntax for "constructing", if that makes any sense.
None. They're exactly the same. But this is C++, and you should not use C-style casts between types. static_cast<int>(someDouble) is what you're looking for.
They will do the same operation. However,
(int)someDouble is a C-style cast, which is discouraged in C++. Don't use it. Ever.
int(someDouble) syntax is not a cast as such, it's an explicit request to create a temporary. It allows creating temporary using constructor with more than 1 argument and creating a temporary using explicit constructor. On the other hand it does not allow casting to types that are not named by single identifier (so no pointers, no unsigned long etc.). Normally used when your intention is really to have a temporary of some complex type, i.e. one with non-trivial constructor.
static_cast<int>(someDouble) is what you really should use most of the time. It will cast between any convertible types and between pointers of related types only. Which is what you should limit yourself to most of the time.
There are other flavors of *_cast, namely:
dynamic_cast<Something *>(pAnything) will check at runtime that the pointer actually points to the specified type and return NULL if it does not. Also usable with references like dynamic_cast<Something &>(anything) in which case it throws a std::bad_cast exception if it is not of the correct type. This is like the C# anything as Something.
const_cast<Something *>(constSomething) is only capable of removing const qualifier; the other *_cast will refuse to. If you need this, you have design problem.
reinterpret_cast<Something *>(pUnrelated) will cast unrelated pointers. Since in C++ a pointer cast is not necessarily a trivial operation (adds/subtracts offset for multiply-inherited objects), it is usually a bad idea and should only be used if you are doing something clever. In fact I am not sure there is a use of reinterpret_cast that would not violate "strict aliasing rules" and therefore be platform-dependent. The reason that C-style cast decays to reinterpret cast when the pointers are unrelated is why it should never be used.
Related
I have been trying to wrap my head around the differences between type casting and type conversion. What i've learnt is that essentially when the underlying value or bit representation of one type is changed to another value, we have performed a conversion. While in pure type casting we simply tell the compiler to treat the bit-pattern as another type. I used 'pure' because a casting may lead to a conversion in which case it is called an 'explicit conversion'.
I have thought of two examples to illustrate this difference.
First:
float x = 1.5;
float* p1 = &x;
int* p2 = (int*) p1;
int i = *p2;
Here casting a pointer type performs no operation on the pointer value. So it's pure casting. In this case it has lead to undefined behavour as we get the int value based on f1.5's bit representation, 1069547520 to be precise.
Second:
B* b = new D();
D* d = static_cast<D*>(b);
Where D is derived from B. Here an implicit conversion is done in the first line. In the second line too, the cast is actually a conversion.These are conversions because the pointer value may be changed, adjusting the value if necessary to point to the complete D object or the B sub-object (I havent completely understood how offsets work though.)
Am i correct in calling pointer casts of user-defined classes conversions? If so then static_cast above has also performed a conversion(explicitly) whereas this answer i read calls casts a different concept altogether:
https://stackoverflow.com/a/34268988/1219638 -
The standard conversions are implicit conversions with built-in meanings and are separate concepts to things like static_cast or C-style casts.
Also why is a conversion of user-defined class pointer called a standard conversion?
Can i ask one last question? I have learnt that a C-style cast will act like a static_cast when the types are related. Does that mean that a C-style cast will also calculate offsets if it has to?
It's important to understand that, as far as the C++ language is concerned, the distinction you're talking about does not exist. All "*_casts" (and their C equivalents) are all just (explicit) conversions. And for the language, all conversions create a new object (or a new reference to an existing object if the conversion is to a reference type).
Pointers are objects. int* p2 = (int*) p1; performs a reinterpret_cast, which creates a new pointer object of a different type. p2 is a distinct object from p1, even though they are pointing to the same memory. If you did ++p2, that would in no way affect what p1 points to.
So from the perspective of the language, a cast is just certain explicit conversions that use syntax that has the word "cast" in it (or syntax equivalent to syntax with the word "cast" in it).
The distinction you're trying to make is basically when a conversion returns a value that is binary identical to the original object and when it doesn't. Well, C++ doesn't really care; all (non-reference) conversions return a new object. C++ neither has nor needs terminology to describe conversions when the new object is binary-identical to the old. And there are plenty of "*_cast" operations which may not return binary-identical values, so even if one were to desire to create such a concept, calling it a "cast" would be confusing.
Also why is a conversion of user-defined class pointer called a standard conversion?
Because that's what the C++ standard calls them. I don't mean that in the sense that we call them "standard" because they're in the C++ standard. I mean the C++ standard has a concept called "standard conversion", and conversions between certain kinds of pointers to classes are part of that.
A "standard conversion" is a conversion that can happen implicitly (ie: without specialized syntax at the site of the conversion). A pointer to a derived class can be implicitly converted to a pointer to an accessible base class. This is part of what polymorphic inheritance is for: the ability for some code to act on a derived class instance without knowing exactly which type it is acting on. The polymorphic base class provides a general interface which code is written to use, and the derived classes provide various implementations of that interface.
I have been trying to wrap my head around the differences between type casting and type conversion.
Here is the difference:
Type cast is an expression. It causes a type conversion explicitly.
Conversions include both explicit conversions and implicit conversions.
Implicit conversions are not caused by casts. They occur in expressions... implicitly.
In this case it has lead to undefined behavour
Correct.
as we get the int value based on f1.5's bit representation, 1069547520 to be precise.
Note that as the behaviour is undefined, we are not guaranteed to get that precise value. Behaviour of the program could be anything; It could be crashing, failing to build, behaving exactly as you would want, or even behave exactly the way you don't want.
Am i correct in calling pointer casts of user-defined classes conversions?
It's common to call casts conversions. Although it may technically be more precise to say that casts cause conversions.
If so then static_cast above has also performed a conversion(explicitly)
Correct.
Also why is a conversion of user-defined class pointer called a standard conversion?
Because it is a pointer, and conversions between pointers are standard conversions.
Does that mean that a C-style cast will also calculate offsets if it has to?
Yes. If a static cast has to calculate an offset, and a C-style cast does a static cast, then the C-style cast calculates an offset.
P.S. Don't use C-style casts.
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).
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.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why do we have reinterpret_cast in C++ when two chained static_cast can do it's job?
I have been suggested that i should not use reinterpret_cast or const_cast in case of pointer to pointer conversion. Only dynamic_cast should be used.Because other cast can create problem in future. So my question is why not reinterpret_cast or other cast which is dangerous has been removed from c++ standard.
Because there are times when you need a cast which does what reinterpret_cast does. As for dynamic_cast, I almost never use this cast; that's only for casting from a parent type to a more derived type. Most of the time I can prove which child type I'm working with, and I use static_cast. I also use static_cast for compile time type conversions, for example from signed to unsigned integers.
static_cast, not dynamic_cast, is the most common kind of cast. If your design relies on dynamic_cast too heavily, that's a code smell indicating your class hierarchy violates LSP in most cases.
In the real world, you frequently have to cast pointers in ways the compiler/runtime can't validate. For example, in pthreads you pass a void* to the new thread's start routine. Sometimes that arg is actually a class? The compiler has no way to tell. It's one of those "real life" issues.
Incidentally I find myself using dynamic_cast infrequently. My main use for is has been exception type scraping in catch blocks.
They are dangerous but sometimes you need them.
C++ is not know for removing constructs that are dangerous to the new user. We will let you run with those scissors (while eating cake).
What makes them good is that the dangerous code sticks out so it is easy to spot. So when people do code reviews they can quickly spot the stuff that is dangerous and add a little scrutiny more checking.
Use reinterpret_cast for casting between unrelated pointer types.
Use static_cast for explicit, supported conversions.
Use dynamic_cast to cast a pointer of one type to a pointer of a derived type.
If you know a pointer to a parent type points to a child type, you can safely static_cast from the parent type to the child type. A cast from a child type pointer to a parent type pointer is implicit and requires no explicit cast.
A reinterpret_cast example from my own code base:
unsigned int CTaskManager::CWorker::WorkerMain(void* Parameters)
{
CWorker* This = reinterpret_cast<CWorker*>(Parameters);
// ...
}
bool CTaskManager::CWorker::Initialize()
{
// ...
// Create worker.
m_ThreadHandle = reinterpret_cast<HANDLE>(_beginthreadex(NULL, 0, &(WorkerMain), this, 0, NULL));
// ...
}
A lot of dangerous operations, though they should generally be avoided, do have a rare legitimate usage. Furthermore, the rule of thumb when it comes to language features and APIs is that once it's there, you can't get rid of it; removing a feature from the C++ language has the potential to break lots of existing C++ code. Typically removal of features requires demonstration that it is not used or that the use is so limited that the cost impact of getting rid of it would be small. Even trigraphs, which are almost never used (unless you are at IBM) and which people wanted to get rid of survived the axe. These various casts and other usually dangerous operations are used way, way more than trigraphs are.
The reinterpret_cast as we know can cast any pointer type to any another pointer type. The question I want to ask regarding this cast operator are:
How does reinterpret_cast work, What is the magic(the internal implementation) that allows reinterpret_cast to work?
How to ensure safety when using reinterpret_cast? As far as i know, it doesn't guarantee of safe casting, So what precaution to take while using reinterpret_cast?
What is the practical usage of this operator. I have not really encountered it in my professional programing experience, wherein I could'nt get around without using this operator.Any practical examples apart from usual int* to char* will be highly helpful and appreciated.
One other Question regarding casting operators in general:
Casting operators(static_cast, dynamic_cast, const_cast, reinterpret_cast) are all called Operators i.e is to the best of my understanding, So is it correct statement to make that casting operators cannot be overloaded unlike most other operators (I am aware not all operators can be overloaded and I am aware of which can't be(except the Q I am asking, Please refrain flaming me on that) Just I had this doubt that since they are operators, what does the standard say about these?
There is no magic. reinterpret_cast normally just means (at least try to) treat what you find at this address as if it was the type I've specified. The standard defines little enough about what it does that it could be different from that, but it rarely (if ever) really is.
In a few cases, you can get safety from something like a discriminated union. For example, if you're reading network packets, and read enough to see that what you've received is a TCP packet, then you can (fairly) safely do a reinterpret_cast from IPHdr to TCPHdr (or whatever names you happen to have used). The compiler won't (again, normally) do much though -- any safety is up to you to implement and enforce.
I've used code like I describe in 2), dealing with different types of network packets.
For your final question: you can overload casting for a class:
class XXX {
public:
operator YYY() { return whatever; }
};
This can be used for conversions in general though -- whether done by a static_cast, C-style cast, or even an implicit conversion. C++0x allows you to add an explicit qualifier so it won't be used for implicit conversions, but there's still no way to differentiate between a static_cast and a C-style cast though.
First, it's unclear what you mean by "non-standard pointer". I think your premise is flawed. Happily it doesn't seem to affect the questions.
"How does [it] work?" Well, the intent, as you can guess from the name, is to just change the interpretation of a bitpattern, perhaps extending or shorting as appropriate. This is a kind of change of type where the bitpattern is left unchanged but the interpretation and hence conceptual value is changed. And it's in contrast to a kind of change of type where the conceptual value is kept (e.g. int converted to double) while the bitpattern is changed as necessary to keep the conceptual value. But most cases of reinterpret_cast have implementation defined effect, so for those cases your compiler can do whatever it wants -- not necessarily keeping the bitpattern -- as long as it is documented.
"How to ensure safety" That is about knowing what your compiler does, and about avoiding reinterpret_cast. :-)
"What is the practical usage". Mostly it is about recovering type information that's been lost in C-oriented code where void* pointers are used to sort of emulate polymorphism.
Cheers & hth.,
reinterpret_cast generally lets you do some very bad things. In the case of casting a pointer it will permit casting from one type to another which has absolutely no reason to assume this should work. It's like saying "trust me I really want to do this". What exactly this does is unpredictable from one system to the next. On your system it might just copy the bit-patterns, where as on another one it could transform them in some (potentially useful) way.
e.g.
class Foo {
int a;
};
class Bar {
int a;
};
int main() {
Foo a;
// No inheritance relationship and not void* so must be reinterpret_cast
// if you really want to do it
Bar *b = reinterpret_cast<Bar*>(&a);
char buffer[sizeof(Bar)];
Bar *c = reinterpret_cast<Bar*>(buffer); // alignment?
}
Will quite happily let you do that, no matter what the scenario. Sometimes if you're doing low-level manipulation of things this might actually be what you want to do. (Imagine char * of a buffer casting to something user defined type)
Potential pitfalls are huge, even in the simplest case like a buffer, where alignment may well be a problem.
With dlsym() on Linux it's useful to be able to cast void* to a function pointer, which is otherwise undefined behaviour in C++. (Some systems might use separate address spaces or different size pointers!). This can only be done with reinterpret_cast in C++.
reinterpret_cast only works on pointers. The way it works is that it leaves the value of the pointer alone and changes the assumed type information about it. It says, "I know these types are not equivalent, but I want you to just pretend this is now a pointer to T2." Of course, this can cause any number of problems if you use the T2 pointer and it does not point to a T2.
There are very few guarantees about reinterpret_cast, which is why it is to be so avoided. You're really only allowed to cast from T1 to T2 and then back to T1 and know that, given some assumptions, that the final result will be the same as what you started with.
The only one I can think of is casting a char* to an unsigned char*. I know that the underlying representation is the same in my implementation so I know the cast is safe. I can't use a static cast though because it's a pointer to a buffer. In reality, you'll find very little legitimate use of reinterpret_cast in the real world.
Yes, they are operators. AFAIK you can't override them.
One "practical" use of reinterpret_cast.
I have a class where the members are not meant to be read. Example below
class ClassWithHiddenVariables
{
private:
int a;
double m;
public:
void SetVariables(int s, int d)
{
a = s;
m = d;
}
};
This class is used in a thousand places in an application without a problem.
Now, because of some reason I want see the members in one specific part. However, I don't want to touch the existing class.So break the rules as follows.
Create another class with the same bit pattern and public visibility. Here the original class contains an int and double.
class ExposeAnotherClass
{
public:
int a_exposed;
double m_exposed;
};
When you want to see members of the ClassWithHiddenVariables object, use reinterpret_cast to cast to ExposeAnotherClass. Example follows
ClassWithHiddenVariables obj;
obj.SetVariables(10, 20.02);
ExposeAnotherClass *ptrExposedClass;
ptrExposedClass = reinterpret_cast<ExposeAnotherClass*>(&obj);
cout<<ptrExposedClass->a_exposed<<"\n"<<ptrExposedClass->m_exposed;
I don't think this situation ever occurs in real world. But this is just an explanation of reinterpret_cast which considers objects as bit patterns.
reinterpret_cast tells the compiler "shut up, it's a variable of type T*" and there's no safety unless it is really a variable of type T*. On most implementations just nothing is done - the same value in the variable is passed to the destination.
Your class can have conversion operators to any type T* and those conversions will either be invokde implicitly under certain conditions or you can invoke them explicitly using static_cast.
I've used reinterpret_cast a lot in Windows programming. Message handling uses WPARAM and LPARAM parameters that need casting to the correct types.
reinterpret_cast is pretty equivalent to a C-style cast. It doesn't guarentee anything; it's there to allow you to do what you need to, in the hopes that you know what you're doing.
If you're looking to ensure safety, use dynamic_cast, as that's what it does. If the cast cannot be completed safely, dynamic_cast returns NULL or nullptr (C++0x).
Casting using the "casting operators" such as static_cast, dynamic_cast, etc.. cannot be overloaded. Straight conversions can, such as:
class Degrees
{
public:
operator double() { ... }
};
The reinterpret_cast as we know can
cast any non-standard pointer to
another non-standard pointer.
Almost, but not exactly. For example, you can't use reinterpret_cast to cast a const int* to an int*. For that, you need const_cast.
How does reinterpret_cast work, What is the magic(the internal
implementation) that allows
reinterpret_cast to work?
There's no magic at all. Ultimately, all data is just bytes. The C++ type system is merely an abstraction layer which tells the compiler how to "interpret" each byte. A reinterpret_cast is similar to a plain C-cast, in that it simply says "to hell with the type system: interpret these bytes as type X instead of type Y!"
How to ensure safety when using reinterpret_cast? As far as i know, it
doesn't guarantee of safe casting, So
what precaution to take while using
reinterpret_cast?
Well, reinterpret_cast is inherently dangerous. You shouldn't use it unless you really know what you're doing. Try to use static_cast instead. The C++ type system will protect you from doing anything too dangerous if you use static_cast.
What is the practical usage of this operator. I have not really
encountered it in my professional
programing experience, wherein I
could'nt get around without using this
operator.Any practical examples apart
from usual int* to char* will be
highly helpful and appreciated.
It has many uses, but usually these uses are somewhat "advanced". For example, if you are creating a memory pool of linked blocks, and storing pointers to free blocks on the blocks themselves, you'll need to reinterpret_cast a block from a T* to a T** to interpret the block as a pointer to the next block, rather than a block itself.