reinterpret-cast

Is it a strict aliasing violation to alias a struct as its first member?

妖精的绣舞 提交于 2019-11-29 01:11:38
Sample code: struct S { int x; }; int func() { S s{2}; return (int &)s; // Equivalent to *reinterpret_cast<int *>(&s) } I believe this is common and considered acceptable. The standard does guarantee that there is no initial padding in the struct. However this case is not listed in the strict aliasing rule (C++17 [basic.lval]/11): If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: (11.1) the dynamic type of the object, (11.2) a cv-qualified version of the dynamic type of the object, (11.3) a type

Equivalent of C++'s reinterpret_cast in C#

生来就可爱ヽ(ⅴ<●) 提交于 2019-11-28 10:03:38
I wonder what's the equivalent of C++'s reinterpret_cast in C#!? Here's my sample: class Base { protected int counter = 0; } class Foo : Base { public int Counter { get { return counter; } } } Base b = new Base(); Foo f = b as Foo; // f will be null I've got no objection why f will be null since it should be. But if it was C++ I could have written Foo f = reinterpret_cast<Foo>(b); and get what I wanted. What can I do to achieve the same in C#? PS. I'm assuming that Base and Foo are consistent data-wise. [UPDATE] Here's a simple scenario where a reinterpret_cast could be helpful: Consider

reinterpret_cast

我的梦境 提交于 2019-11-28 09:29:07
In the C++ Without Fear: A Beginner's Guide That Makes You Feel Smart book, and in chapter (8), it mentions the following about reinterpret_cast ....converts from one pointer type (int ) to another (char*). Because the cast changes the way the data pointed to is interpreted, it is called reinterpret_cast, as opposed to static_cast.* Can you describe this paragraph here? Especially the reason for the way the operation is named? Thanks. Basically, the reinterpret_cast reinterprets the bit pattern at a specific location as a different type. See for example here: http://publib.boulder.ibm.com

Getting around the reinterpret cast limitation with constexpr

为君一笑 提交于 2019-11-28 06:56:58
问题 In c++11, a constexpr expression cannot contain reinterpret casts. So for instance, if one wanted to manipulate the bits in a floating point number, say to find the mantissa of the number: constexpr unsigned int mantissa(float x) { return ((*(unsigned int*)&x << 9) >> 9); }; The above code would fail to be constexpr . In theory, I can't see how a reinterpret cast in this or similar cases can be any different from arithmetic operators, but the complier (and the standard) don't allow it. Is

Why can't I static_cast between char * and unsigned char *?

烈酒焚心 提交于 2019-11-28 05:42:28
Apparently the compiler considers them to be unrelated types and hence reinterpret_cast is required. Why is this the rule? EdChum They are completely different types see standard: 3.9.1 Fundamental types [basic.fundamental] 1 Objects declared as characters char) shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold

Proper way of casting pointer types

最后都变了- 提交于 2019-11-28 04:38:47
Considering the following code (and the fact that VirtualAlloc() returns a void* ): BYTE* pbNext = reinterpret_cast<BYTE*>( VirtualAlloc(NULL, cbAlloc, MEM_COMMIT, PAGE_READWRITE)); why is reinterpret_cast chosen instead of static_cast ? I used to think that reinterpret_cast is OK for e.g. casting pointers to and from integer types (like e.g. DWORD_PTR ), but to cast from a void* to a BYTE* , isn't static_cast OK? Are there any (subtle?) differences in this particular case, or are they just both valid pointer casts? Does the C++ standard have a preference for this case, suggesting a way

Proper casting for fstream read and write member functions

∥☆過路亽.° 提交于 2019-11-28 04:34:01
问题 Although there was a lot of lines written on the topic of reinterpret_cast, and how bad it is, I'm still puzzled with best way to avoid it, especially when dealing with functions like read and write from fstream. So, here is my dilemma... Let's say we have an integer array that we want to fill with some data from a file. std::ifstream iFile( ... ); // presume that the type of this array is not a matter of choice int *a = new int[ 100 ]; We can read with a few different casts: iFile.read(

Should I use a C++ reinterpret_cast over a C-style cast?

假如想象 提交于 2019-11-28 01:53:55
I have the following template function used to dump data of any standard type into a binary output stream. template<typename T> static void dump ( const T& v, ostream& o ) { o.write ( reinterpret_cast<const char*>(&v), sizeof(T)); } Instead of the reinterpret_cast I could also use a C-style (const char*). Is there any particular reason to use reinterpret_cast? I read a few other posts where reinterpret_cast was frowned upon. But the above usage is legal and cannot be replaced with anything else, right? The problem with C-Style casts is that they do a lot under the hood. See here for a detailed

C++ unions vs. reinterpret_cast

对着背影说爱祢 提交于 2019-11-27 22:49:07
It appears from other StackOverflow questions and reading §9.5.1 of the ISO/IEC draft C++ standard standard that the use of unions to do a literal reinterpret_cast of data is undefined behavior. Consider the code below. The goal is to take the integer value of 0xffff and literally interpret it as a series of bits in IEEE 754 floating point. ( Binary convert shows visually how this is done. ) #include <iostream> using namespace std; union unionType { int myInt; float myFloat; }; int main() { int i = 0xffff; unionType u; u.myInt = i; cout << "size of int " << sizeof(int) << endl; cout << "size

C++ When should we prefer to use a two chained static_cast over reinterpret_cast

别说谁变了你拦得住时间么 提交于 2019-11-27 19:06:56
问题 First of all, this is not a duplicate of Why do we have reinterpret_cast in C++ when two chained static_cast can do it's job?. I know situations where we cannot use even two chained static_cast to achieve that, what reinterpret_cast does. But is there any situation where I should prefer a two chained static_cast over a simple and more readable reinterpret_cast ? 回答1: reinterpret_cast should be a huge flashing symbol that says THIS LOOKS CRAZY BUT I KNOW WHAT I'M DOING. Don't use it just out