Wataru

У вас в примере вообще классы без данных, поэтому разницы никакой нет между первым и вторым вариантом. Третий выделят память под объект не на стеке, а в куче - поэтому и выделение и работа с объектом, обычно, будет дольше.

Если бы в объекте были данные, то первый вариант был бы быстрее всего, потому что он ничего бы не инициализировал, в отличии от остальных.

Если бы в объекте был еще и конструктор, то первый и второй варинт были бы идентичными.

Третий вариант всегда инициализирует объект и выделяет память, поэтому он будет медленнее.

Введите 2 переменные t и q - это "время" на первом и втором луче, составьте 2 уравнения. Решите их - найдете время пересечения на каждом луче. Убедитесь, что пересечения при t>=0, q>=0:

x1+t*vx1=x2+q*vx2
y1+t*vy1=y2+q*vy2

надо проверить, что оно имеет решение. Преобразуйте его к стандартному виду:

t*vx1-q*vx2=x2-x1
t*vy1-q*vy2=y2-y1

Решите систему методом Краммера. Если определитель системы != 0 - то найдте 2 переменные q и t. Проверьте, что они обе неотрицательные.

Если определитель равен нулю, то прямые или не пересекаются вообще, или совпадают. Они совпадают, если оба вспомогательные определители системы равны 0.

В этом случае надо проверить, что лучи пересекаются по отрезку или лучу. Для этого надо проверить, а не лежит ли начало второго луча на первом и наоборот. Для этой проверки можно воспользоватся векторным произведением векторов. Считаете вектор {x2-x1, y2-y1} и умножаете на вектор {vx1, vy1}. Эти 2 вектора или смотрят в одну сторону (и пересечение есть), или в разные. В первом случае векторное произведение будет положительно, во втором - отрицательно. Нулевое произведение считайте как положительное - это значит что или точки совпадают или вектор направления нулевой.

Т.е. весь алгоритм
1) Считайте 3 определителя по методу краммера
2) Если главный определитель не 0, считайте q и t. Пересечение есть, если q>=0 и t>=0.
3) Если главный определитель 0, но хотя бы один из вспомогательных не 0 - пересечения нет.
4) Считайте векторное произведение {x2-x1, y2-y1} на {vx1, vy1}. Если оно неотрицательно - пересечение есть.
5) Считайте векторное произведение {x1-x2, y1-y2} на {vx2, vy2}. Если оно неотрицательно - пересечение есть.

Никак. Заставьте вашу функцию принимать указатель:

template <typename type>
  static void readMemory(uintptr_t offset, unsigned int length, type* var) {
    ReadProcessMemory(targetHandle, (LPVOID)offset, var, length * sizeof(type), 0);
  }

uint8_t arr[100500];
readMemory<uint8_t>(0x00, 10, arr);

По поводу вызова неконстантных методов - а с чего вы взяли, что они не дожны быть возможны? Временные объекты не имеют const квалификаторов. Иначе нельзя было бы делать вещи типа SomethingBuilder().WithA().WithB().Finalize().

//! f6() = X(1);

Оператор присвоения требует Lvalue слева. Временный объект же - Rvalue. Eго можно ставить только справа от =. А не потому что у него const квалификатор.

Это сделано скорее всего потому, что, ну, нет же смысла перезаписывать временный объект. Он временный, к нему потом никак не обратиться.

//! f6().modify();

Вот тут попытка вызова неконстантного метода у константного (и временного - но это не важно) объекта.

//! f7(f5());

Видимо, это чтобы исключить некоторый класс ошибок. Если вы передаете в качестве неконстантной ссылки что либо, значит оно должно внутри менятся и снаружи эти изменения должны быть видны. Иначе можно было бы передавать по константной ссылке или по значению. Но вы передаете туда временный объект - его никак снаружи видно не будет. Он существует только в этой строчке. Поэтому в C++ нельзя инициализировать неконстантные lvalue ссылки через rvalue (временные объекты).

Вам придется переписать функцию readMemory, чтобы она принималаlength и читала length*sizeof(type). Или вызывайте прямо ReadProcessMemory в вашей функции.

Текущая реализация для вашей цели не подходит вообще. Тип шаблона должен быть известен на этапе компиляции. А вы хотите как-то в нем передать динамическую длину.

Нет. Распишите формулы, они будут разные. В прогрессии каждый раз добавляется степень коэффициента q. В проценте происходит домножение на (1+q):

A+Aq+Aq^2+Aq^3+...
A+Aq+(Aq+Aq^2)+(Aq+2*Aq^2+Aq^3)+...

машина состояний?

Вы наткнулись на важное свойство ассимптотического анализа. O(n^2) -означает, что на достаточно больших n, время работы будет примерно n^2 с точностью до константы. Эта самая константа может быть хоть 0.5, хоть 10000000.

Сравните 2 алгоритма:

// n(n-1)/2 инкремента.
for(i = 0; i < n; ++i){
  for (j = i+1; j < n; j++) {
    cnt1++;
  }
}
// n^2 инкремента.
for(i = 0; i < n; ++i){
  for (j =0; j < n; j++) {
    cnt2++;
  }
}

Оба алгоритма имеют O(n^2) сложность, но один делает примерно в 2 раза меньше операций.

Суть в том, что хоть алгоритмы и работают с одинаковой ассимптотикой, они могут работать разное время! Особые странности могут быть при маленьких n. O(n log n) алгоритм часто может быть медленнее O(n^2) алгоритма. Поэтому все настоящие реализации сортировок для маленьких массивов запускают более тупые квадратичные алгоритмы.

Если же вы хотите показать только ассимптотику, то возьмите n побольше, и тогда эти 30% будут незаметны по сравнению с десятикратным замедлением O(n^2) относительно O(n log n). Или нормируйте ваши сортировки. Искуственно ускорьте одни алгоритмы и замедлите другие, чтобы получить именно тот результат, который вы хотите. Но это как-то нечестно что ли. Если же вы все-таки хотите именно этого, назначьте каждой сортировке время C\*n^2 или С\*n\*log n миллисекунд. Прогоните алгоритмы сортировки без визуализации, подсчитайте, сколько операций замедления вы бы сделали (тот же самый код, что у вас, только вместо usleep() делайте sleep_count++). В конце подсчитайте коэффициент замедления - сколько каждый usleep должен спать, чтобы суммарно sleep_count их спал заданное время. И запускайте каждую сортировку уже с подсчитанными параметрами для usleep.

Первое - это Retrun Value Optimization. Компилятор видит, что результат работы функции используется для инициализации переменной и вместо выделения памяти под временный объект и копирования сразу заполняет результат.

По поводу ссылки. Результат работы функции в вашем случае - prvalue

там же по ссылке написано:

An rvalue may be used to initialize a const lvalue reference, in which case the lifetime of the object identified by the rvalue is extended until the scope of the reference ends.

An rvalue may be used to initialize an rvalue reference, in which case the lifetime of the object identified by the rvalue is extended until the scope of the reference ends.

Т.е. стандартом запрещено инициализировать не const ссылку через prvalue.

Почему это сделано? Потому что эти самые prvalue/rvalue по сути являются временными объектами. У них нельзя взять адрес, у них нет имени, компилятор может засунуть их куда угодно и уничтожить сразу за текущим выражением.

Если бы можно было делать ссылку на эти временные объекты и как-то их менять потом, это бы усложняло анализ и возможность некоторых оптимизаций. Как, например, RVO в вашем вопросе. Пришлось бы создавать временную переменную в main для хранения результата, потому что функция память под результат не выделяет. Поэтому в стандарте C++ этого нет.

Потом, когда в С++11 ввели rvalue ссылки и перелопатили категории значений - разрешили инициализировать rvalue ссылки через prvalue.

Поэтому работают

const int& r1 = f();
int&& r2 = f();

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

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

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

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

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

Надо так:

template<typename ...Args>
UniformBuffer<Args...>::UniformBuffer(Args... arg)
{ 
//код
}

У вас шаблоном является сам класс, а не его методы.

Заведите char массивы какой-то достаточной длины. Читайте через gets_s. Сравнивайте строки через strcmp.