Type-punning issue in C++

Question

I have a template class with a bool as its template parameter Dynamic<bool>. Whether the parameter is true or false it has the exact same data members. they just differ in their member functions.

There is one situation that I need to convert one to another temporarily, instead of using a copy/move constructor. So I resorted to type-punning. To make sure that it cause an issue I used two static_asserts:

d_true=Dynamic<true>(...);
...
static_assert(sizeof(Dynamic<true>)==sizeof(Dynamic<false>),"Dynamic size mismatch");
static_assert(alignof(Dynamic<true>)==alignof(Dynamic<false>),"Dynamic align mismatch");
Dynamic<false>& d_false=*reinterpret_cast<Dynamic<false>*>(&d_true);
...

So I think what I am doing is safe, and if anything is about to go wrong the compiler will give me a static_assert error. However, gcc gives a warning:

warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

My question is twofold: is what I am doing the best way to achieve this? If it is, how can convince gcc it is safe, and get rid of the warning?

Answer 1

One obvious possibility would be to separate the data that's common to both out into its own class (or struct), then grab that from the the object when you need it.

struct Common {
// ...
};

template <bool b>
class Dynamic { 
    Common c;
public:
    Common &get_data() { return c; }
    // ...
};

From there, the rest seems fairly obvious--when you need the data from the Dynamic<whatever>, you call get_data() and off you go.

Of course, there are variations on the general theme as well--for example, you could use inheritance instead:

struct Common { /* ... */ };

template <bool t>
class Dynamic : public Common {
    // ...
};

This eliminates the extra c. the previous version would need for every reference to the common data, but (at least in my opinion) inheritance is probably too high a price to pay for that.

Answer 2

In the standard it's "forbidden" to reinterpret a region of memory from type A to type B. This is called aliasing. There are 3 exceptions to aliasing, same types with different CV qualification, base types, and regions of char[]. (and for char the derogation only works unidirectionaly in the direction to char)

If you use std::aligned_storage and placement new, you can reinterpret that region into anything you want without the compiler able to complain. That's how variant works.

EDIT: Ok the above is actually true (as long as you don't forget std::launder), but misleading because of "lifetime". Only one object may live on top of a storage space at once. So it's undefined behavior to interpret it through the view of another type, while it's alive. The key is the construction.

If I may suggest, go to cppreference, take their static_vector example, simplify it to the case of 1. Add a few getters, congratulations, you've reinvented bitcast :) (proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0476r2.html).

Probably it'd look like this:

#include <type_traits>
#include <string>
#include <new>
#include <cstring>
#include <iostream>

using namespace std;

template< bool B >
struct Dynamic
{
    template <bool B2 = B>
    void ConditionalMethod(typename enable_if<B2>::type** = 0)
    {}

    string m_sharedObject = "stuff";
};

int main()
{
    using D0 = Dynamic<false>;
    using D1 = Dynamic<true>;
    aligned_storage<sizeof(D0), alignof(D0)>::type store[1];

    D0* inst0 = new (&store[0]) D0 ;

    // mutate
    inst0->m_sharedObject = "thing";

    // pune to D1
    D1* inst1 = std::launder(reinterpret_cast<D1*>(&store[0]));

    // observe aliasing
    cout << inst1->m_sharedObject;

    inst0->~D0();
}

see in effect in wandbox

EDIT: after a lengthy discussion there are other parts of the new standard than the section 'Types 8.2.1.11', that explains better why this isn't strictly valid. I recommend to refer to the "lifetime" chapter.
https://en.cppreference.com/w/cpp/language/lifetime
From Miles Budnek comment:

there is no Dynamic<true> object at that address, accessing it through a Dynamic<false> is undefined behavior.

Answer 3

After reading the discussion in https://stackoverflow.com/a/57318684/2166857 and reading the source code for bit_cast and a lot of research online, I think I have found the safest solution to my problem. This only works if

1) The align and size of both types match

2) both types are trivially copyable (https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable)

First define a memory type using aligned_storage

typedef std::aligned_storage<sizeof(Dynamic<true>),alignof(Dynamic<true>)>::type DynamicMem;

then introduce the variable of that type

DynamicMem dynamic_buff;

then use placement new to initiate the object to the primary class (in my case Dynamic)

new (&dynamic_buff) Dynamic<true>();

then whenever is needed use reinterpret_cast to define the object reference or the pointer associated with it in a scope

{
    Dynamic<true>* dyn_ptr_true=reinterpret_cast<Dynamic<true>*>(&dynamic_buff)
    // do some stuff with dyn_ptr_true
}

This solution by no means is perfect, but it does do the job for me. I do encourage everybody to read the thread https://stackoverflow.com/a/57318684/2166857 and follow the back and forth between @Miles_Budnek and @v.oddou. I certainly learned a lot from it.

Answer 4

The only safe type punning method in standard C++ is via std::bit_cast. However that may involve a copy instead of treating the same memory representation as a different type if the compiler isn't able to optimize it. Besides, currently std::bit_cast is only supported by MSVC although in Clang you can use __builtin_bit_cast

Since you're using GCC you can use the attribute __may_alias__ to tell it that the aliasing is safe

template<int T>
struct Dynamic {};

template<>
struct Dynamic<true>
{
    uint32_t v;
} __attribute__((__may_alias__));

template<>
struct Dynamic<false>
{
    float v;
} __attribute__((__may_alias__));

float f(Dynamic<true>& d_true)
{
    auto& d_false = *reinterpret_cast<Dynamic<false>*>(&d_true);
    return d_false.v;
}

Clang and ICC also support that attribute. See demo on Godbolt, no warnings are given