Kevsh

Оператор << не является точкой следования, таким образом, вы получаете неопределенное поведение - у вас вызовы ++(*val) не отделены точкой следования друг от друга.

Вот так ошибки не будет:

cout << a.get();
cout << b.get();

Потому что ; является точкой следования.

В более свежих версиях стандарта может быть другая терминология, но суть проблемы - прежняя.

Это тот самый случай, когда с виду простой код заставляет разобраться во множестве тонкостей языка.
Для лучшего понимания проходящих в коде процессов сперва требуется внимательно присмотреться к стандарту языка.

Что стандарт говорит нам о перегрузке операторов?

A declaration whose declarator-id is an operator-function-id shall declare a function or function template or an explicit instantiation or specialization of a function template. A function so declared is an operator function.

cout << a.get() << b.get();
Данный код маскирует два вызова одной функции - std::ostream& operator << ( std::ostream&, int ).

Тут очень важно уточнить форму перегрузки оператора, т.к. результат поведения этого кода сильно зависит от применяемой формы перегрузки.
Относительно стандартной формы перегрузки operator << () стандарт говорит что это перегрузка в форме внешней функции.

Значит приведенный код можно записать как:

operator<<( operator<<( cout, a.get() ), b.get() );

И именно с этого момента начинается самое интересное.

Что стандарт говорит нам о вызове функций? А говорит он совсем разные вещи.
C++14 [expr.call#5.2.2.8] заявляет, что:

The evaluations of the postfix expression and of the arguments are all unsequenced relative to one another. All side effects of argument evaluations are sequenced before the function is entered (see 1.9).

C++17 [expr.call#8.2.2.5] утверждает, что:

If an operator function is invoked using operator notation, argument evaluation is sequenced as specified for the built-in operator; see 16.3.1.2.

В результате, если транслировать данный код как код 14-го (или старших) стандарта, поведение у этого кода будет одно. Если же код транслировать как код 17-го (и моложе) стандарта, его поведение будет будет уже другим.

А что же там с вероятным неопределенным поведением? Ведь неупорядоченная модификация состояния является UB. И, вроде как, cout << a.get() << b.get(); можно упростить до cout << ++i << ++i;, что уже более явно должно показывать наличие UB.
UB в этом коде нет. И вот почему.

Для определения порядка вычисления участков выражения следует руководствоваться правилами упорядочивания выражений.
Среди прочих правил там записаны важные для нас сейчас. Я приведу цитаты.

2) The value computations (but not the side-effects) of the operands to any operator are sequenced before the value computation of the result of the operator (but not its side-effects).

3) When calling a function (whether or not the function is inline, and whether or not explicit function call syntax is used), every value computation and side effect associated with any argument expression, or with the postfix expression designating the called function, is sequenced before execution of every expression or statement in the body of the called function.

5) The side effect of the built-in pre-increment and pre-decrement operators is sequenced before its value computation (implicit rule due to definition as compound assignment)

16) Every overloaded operator obeys the sequencing rules of the built-in operator it overloads when called using operator notation. (since C++17)

19) In a shift operator expression E1<<E2 and E1>>E2, every value computation and side-effect of E1 is sequenced before every value computation and side effect of E2. (since C++17)

До C++17 порядок вычисления операндов cout << a.get() << b.get(); не определен, но поведение этого кода определено. Поэтому при трансляции по стандарту C++14 этот код может выдать или 12, или 21. Но не 11.
Начиная с C++17 порядок вычисления операндов строго определен и является интуитивным, а результат выполнения cout << a.get() << b.get(); всегда однозначен. При трансляции этого кода по стандарту C++17 (и дальше) в консоль будет выведено всегда и только 12.
До C++11 поведение кода cout << a.get() << b.get(); не определено.

Сегодня мы уже не задумываемся о жизни до стандарта C++11, поэтому я не скажу что в общем смысле в этом коде присутствует UB. Я скажу что UB тут нет. Но тем не менее, я бы рекомендовал избегать присутствия подобного кода в проектах даже если используется стандарт C++17 и дальше.

b = func(a);

Вот тут вы взяли ссылку, которую вернула func и скопировали значение в переменную b. Поэтому ниже &b выведет вам адрес переменной b, а не то, что вы хотели.

Возвращать ссылки бывает удобно, когда надо вернуть значение без копирования и оно всегда существует. Потому что функция, возвращающая указатель, вообще говоря, может вернуть и nullptr. По уму, надо бы этот указатель проверить перед разыменованием. А вот ссылки - они всегда куда-то указывают.

Решение:
Создаём пустой CLR проект.
Добавляем форму.
Открываем вкладку
Пишем это в имя_формы.cpp файле

#include "имя_формы.h"
#include <Windows.h>

using namespace Имя_Вашего_Проекта;
 
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    Application::EnableVisualStyles();
    Application::SetCompatibleTextRenderingDefault(false);
    Application::Run(gcnew MyForm);
    return 0;
}

Сохраняем.
Закрываем проект.
Открываем снова, если появится окно с визуальным редактором, то там будет ошибка.
Закрываем его.
Открываем двойным нажатием имя_формы.h
Done.

Вы "создаете" класс sf::RectangleShape через malloc в составе временных массивов pq, qr. Он оказывается заполнен мусором. Нарушены какие-то его внутренние инварианты. Может быть куча проблем: начиная от того, что там переопределен оператор присванивания, который должен что-то где-то почистить, заканчивая тем, что таблица виртуальных методов у класса будет испорчена. Любая попытка сделать что угодно с таким экземпляром класса - скорее всего неопределенное поведение.

Если уж вы используете классы из C++, то выделять память надо через new[], а не malloc. Тогда экземпляр класса создасться нормально и конструктор вызовется.

Можно было бы подумать, что memmove решил бы вашу проблему - но, опять же, при этом нарушаются внутренние инварианты. Какой-нибудь unique_ptr внутри будет уже не уникальным. Такие операции работы с памятью можно делать только для POD (Plain old data) - структур состоящих из структур, массивов и базовых типов.

Или, еще лучше использовать vector для временных массивов. Тогда вам не придется заботиться об освобождении памяти. Еще, вместо копирования можно использовать std::move, может работать бысрее, если эти sf классы имеют более эффективные операторы перемещения.

if (f_pos.x * x_direction > R) {
    rot_direction2 = false;
}

Если делаете относительной линк, а затем его копируете, то он будет ссылаться относительно нового каталога. Делайте линк ссылкой от корня файловой системы. Или создавайте линк сразу в нужном каталоге. Да в майкрософтп все тоже самое.

Попробуйте заменить тильду ~ на /home/user.