jcmvbkbc

Ну, это совсем просто. Чтобы держать биполярный ключ открытым, надо ему в базу загонять ток, всё время. Т.е. непрерывно тратить энергию, поскольку там есть замкнутая цепь для электрического тока (открытый эмиттерно-базовый PN-переход).
С полевым ключом принципиально не так. Управляющая цепь затвора - не замкнутая, поскольку между затвором и каналом есть изолирующая прослойка. Поэтому там ток не течёт, для открытия ключа достаточно подать напряжение, для закрытия - снять его. Электроэнергия на это практически не тратится (если не считать первый момент, когда заряжается затворная ёмкость). Вот и первое преимущество - экономичность в управлении.
Второе преимущество полевика - малое проходное сопротивление (единицы миллиом, много меньше, чем у биполярного, и в некоторых случаях даже меньше, чем у замкнутых контактов). Причём чем больше управляющее напряжение на затворе, тем проходное сопротивление меньше, соответственно и меньше нагрев полевика проходящим током. Однако не надо впадать в фанатизм на этом пути - если Uупр превысит значение 15 вольт, то изоляция затвора может быть пробита, и полевой ключ (такой удобный и простой в применении) превратится в тыкву.
Есть и другие отличия, которые проявляются только на высоких частотах.

Вот тут ошибка: while (x.get() < 999999)
Вполне атомарно можно получить тут true на неограниченное количество потоков.

Не бывает совсем "новых" веток - все ветки откуда-то растут.
Если в запушеной ветке два коммита вместо одного, значит один из них уже был в той ветке, от которой вы отпочкованли "новую".

1. Не нужно пихать getChar и getFloat в абстрактный класс.
Но если таки делаешь заглушки - кидай полноценную ошибку, чтобы гарантировать корректное использование.

2. Вместо этого можно было бы использовать паттерн visitor - по крайней мере его часто используют в ситуациях, которые похожи на твою

3. Вместо указателей на классы можно попробовать union - для этого есть std::variant. Это будет чуть более эффективно по памяти, хоть размер массива может вырасти, если вместо float будет double, а вместо char - какой-нибудь wchar или "руна", или если добавится ещё какой-нибудь тяжёлый вариант. А до этого такой Юнион можно уместить в 8 байт вместе с выравниванием.

Как решать - алгоритмически. Любая криптография - это набор алгоритмов преобразования данных итд, которые можно выполнить руками и посмотреть на все промежуточные данные. А также на то, из чего они порождены, как здесь, где в качестве random seed использован один байт. И если вы увидели, что какой-то элемент промежуточных данных оказывается статичным или из небольшого множества возможных значений, создаете множество и применяете перебор (в самом крайнем случае, иногда и он не нужен). "Взрослая" криптография обычно куда сложнее, но и там бывает, что какие-то величины оказываются не из полного пространства 2^N, тогда алгоритм использования этого факта называется "атака уменьшения сложности". Вот искать такое - уже нужно разбираться в высшей математике на уровне математических абстракций, а олимпиадные задачи чаще всего требуют относительно простого анализа алгоритма или кода.

Историю изменения коммита посмотреть невозможно, так как это неизменяемая сущность по определению. Через amend вы лишь создаёте новый коммит и перемещаете указатель текущего состояния на него. Эти перемещения вы видите в локальном журнале reflog. Вы не можете видеть reflog внешних репозиториев. В лучшем случае, вы увидите историю «изменений» в Pull Request на GitHub.

Я имею ввиду предыдущую версию коммита до amend. Локально же можно переключиться на него через checkout.

Эти осиротевшие коммиты не удаляются сразу, поэтому вы некоторое время ещё можете их извлечь из репозитория через checkout или reset. Но они не принадлежат никакой ветке, поэтому никуда не отправляются при push и не получаются при fetch или clone, поэтому вы не сможете на них переключиться, так как их нет локально. Они остались в «мусоре» внешнего репозитория, который не скачивается при clone.

falstad.com/circuit/circuitjs.html
Проще некуда. Куча примеров встроенных.

Оно не компилируется. Нажмите показать ошибки, там будут детали.

Просто догадки:
У вас опечатка - функция mian вместо main.
Потом, в конце функции должно стоять return 0;

https://gcc.gnu.org/onlinedocs/gcc/Standards.html#...

Лучше так делать не надо. Это UB - нарушение всяких strict aliasing, выравниваия и вообще от порядка байт в машине зависит. Лучше руками собрать ULL по частям, вроде

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*i);

или

for (int i = 0; i < 8; ++i) result |= byte_array[i+1] << (8ULL*(7-i));

На худой конец, если очень узкое место, надо делать memcpy из массива в &result.

заменить alias на функцию

c()
{
   example command --filter="$1"
}

-Wconversion -Warith-conversion

Матрицы используются для записи преобразований. Надо домножать на них вектор из координат точки - получится новый вектор, который и будет результатом преобразования. Любое линейное преобразование можно записать в виде матрицы.

Четвертая координата позволяет записывать одной матрицей повороты/растяжения и сдвиги. Если у вас матрица 3x3 (не "трехмерная" - у нее все так же есть только ширина и высота), то точка (0, 0, 0) всегда останется (0, 0, 0). Ведь на что 0 не домножай - останется 0. Поэтому матрицами 3x3 можно записать только повороты и сжатия, но не сдвиги.

Поэтому вводят фиктивное четвертое измерение w. При этом удобно считать, что координаты точки (x, y, z, w) - Это (x/w, y/w, z/w). Это еще иногда называют однородными координатами. Еще один плюс этого объекта в том, что им можно описать точки на бесконечности (когда w = 0).

Вот тут уже можно составить линейное преобразование (т.е. взять матрицу), которое оставляет w нетронутым, но использует его для сдвига:

x' = a11*x + a12*y + a13*z + a14*w
...
w' = w

Вот в a14 - как раз и находится сдвиг по оси X.