Mercury13

Потому что у вас неэффективный алгоритм вычисления НОД, работающий на вычитании, а не на делении с остатком.
Естественно, НОД(1,6) = НОД(1, 6−1=5) = НОД(1, 5−1=4) = НОД(1, 4−1=3) = НОД(1, 3−1=2) = НОД(1, 2−1=1) = НОД(1, 1−1=0) = 1
НОД(2,6) = НОД(2, 6−2=4) = НОД(2, 4−2=2) = НОД(2, 2−2=0) = 2
С арифметическим переполнением никак не связано. Просто даже в результате переполнения получились немаленькие числа.

Как надо: НОД(1,6) = НОД(6, 1%6=1) = НОД(1, 6%1=0) = 1
Аналогично для НОД(6,2) — в общем, сходится довольно быстро.

В 2021 используйте LLD.

В конце концов перешёл на собственный порт MiniZip.

Лучше использовать MariaDB с плагинами. Мария меньше и для неё есть что угодно.

Это так называемый «универсальный инициализатор» Си++11. Иногда это действительно initializer_list, но не сейчас. Здесь он эквивалентен вызову конструктора
std::vector<char>(data.get(), data.get() + size)

Один из способов получить из рациональных чисел действительные.
Проблем не будет.
Однако эти супремумы и инфимумы стоило бы помучить.

Ваш код решает одну задачу, постоянно выводя 38 — и ту через какую-то задницу.
Во-первых, надо ВВЕСТИ информацию, а не пережёвывать цифры 12 и 126 непонятно каким раком.
Во-вторых, вам надо получить x = n % 50. Если он 0, то и вывести 0 — иначе вывести 50 − x.

Первый способ: создаётся initializer_list, вызывается конструктор. Наиболее эффективен для простых тупых объектов.

Второй способ эквивалентен push_back(string("vec1")) и сильно полагается на оптимизацию передаваемых параметров. Наименее эффективен.

Третий способ гарантированно не создаёт промежуточные объекты (вызывает конструктор string(const char*) уже на месте). Вместе с reserve(3) наиболее эффективен для управляемых объектов.

UPD. 2 и 3 для string() не очень сильно различаются из-за эффективного переноса. А вот для более крупных объектов 3 лучше.

UPD2. Начиная с Си++20, 1 лучше, но только из-за того, что Си++ научился делать полноценные string’и при компиляции — то есть управляемый объект string обзавёлся некоторыми чертами тупого.

UPD3. Ни один компилятор пока constexpr string пока не поддерживает. Но ведь ни у кого стабильного 20 пока нет, правильно?

От массы тела зависит взаимодействие с другой массой.
От силы броска и массы тела — начальная скорость v.

Чаще всего действительно не доводят до аналитического решения, а каждый кадр происходит шаг численного решения дифференциального уравнения:
(vx, vy)′ = (0, −g) — ну или сопротивление воздуха добавьте
(x, y)’ = (vx, vy)

Гуглите «методы Рунге—Кутты», нам хватит метода второго порядка.

printf("%c", x);
Форматную строку упустил.

Я бы предложил поискать в коде ошибку, есть большое подозрение — первым множителем так и просится size. Ну или деление size %/ msize — невозможно сказать. Ну или условием будет не меньше, а больше или больше-равно. Но будем работать как есть.

int v = msize / size;
if (i < msize % size) ++v;
int teqportion = msize * v;

Почему подозреваю ошибку? Тут очень похоже на сильно поломанное округление вверх или вниз до кратного, в зависимости от условия.

Строковый литерал " ab " находится в особом сегменте данных, который (если процессор и ОС позволяют) только для чтения. А память сегмента данных освободить и сделать «кучей» нельзя.

Если предположить, что текст " ab " находится в «куче» — эта самая куча является сложной структурой данных и память выделяется с выравниванием. Потому функция realloc может (но не обязана) отдать конец или приделать память к концу. Отдать начало будет сложнее, и ни одна известная мне библиотека функций на это не способна.

Кроме того, Си++ придумал объект string_view именно для этого — чтобы передавать строки в функцию, абстрагируясь от выделения памяти и даже от оконечного нуля. Потому у string_view нет функции c_str().

Разумеется, вы можете сделать что-то вроде

char* str2 = str + 2;
str2[2] = '\0';
// А str оставь, уничтожать как-то придётся

Разумеется, если str находится в куче. Сегмент с литералами, напоминаю, только для чтения, и в ОС вроде DOS, где менять можно, такая замена может вызвать нехорошие побочки.