Mercury13

https://docs.microsoft.com/en-us/windows/win32/api...
В Qt нет, посмотрел исходники — либо часть Chromium, либо не выглядывает наружу.

Tony сказал правильно, но есть ещё одна вещь.
CreateThread использовать ЗАПРЕЩАЕТСЯ. Точнее, можно — но для этого нужно знать, что делаешь. А так для прикладного прогера правило — надо перевести библиотеку времени выполнения в многопоточный режим, и для этого вызвать аналог из этой самой библиотеки. В Си++ для этого используется функция beginthreadex(), в Delphi — BeginThread.

Проверим один тест.

// Какую концепцию проверяем?
   // Это не просто проверка функции ListAll, это проверка какой-то концепции кода
   // Варианты.
   // 1. Пустой listAll() даёт пустой список.
   // 2. Непустой listAll() даёт непустой список.
    void testListAll() {
        ArrayList<Product> productList = new ArrayList<Product>();
        // Проводим поиск в списке — что в этот список вносится?
        // И не будет ли физической зависимости тестов друг от друга?
        // И для чего вообще нужен этот search, если мы listAll тестируем?
        // Что такое ProductRepository и он вообще проверен?
        when(this.productRepository.search((String) any())).thenReturn(productList);
        // Ну, хорошо.
        List<Product> actualListAllResult = this.productService.listAll("Keyword");
        // Отказ, они не same: первый мы только что создали, а второй откуда-то пришёл.
        assertSame(productList, actualListAllResult);
        // Получается, что концепция — поиск, когда ничего не находится?
        assertTrue(actualListAllResult.isEmpty());
        verify(this.productRepository).search((String) any());
        // Получается, единственная концепция, которую мы тестируем,— поиск в пустом списке даёт пустоту
        // (и та некорректная из-за assertSame).
        assertTrue(this.productService.getAll().isEmpty());
    }

Ну что, понятно, что или фтопку такие инструменты, или нужно их серьёзно осваивать, прежде чем будут приносить хоть какие-то результаты?

Придумал.

[[maybe_unused]] byte debugWarning = SIMULATE_CHANGED_HORIZON * 1000;

В случае false компиляция пройдёт гладко. В случае true преобразование 1000 → byte выдаст предупреждение.

А теперь скажу правильный ответ.
В Си символьный литерал имеет тип int и потому его sizeof 4 байта.
В Си++ у него тип char и 1 байт. Потому те, кто создавал CPP-файл, проблемы не видели. Очевидно, связано с перегрузкой функций: как-то не хочется, чтобы в foo('A') вызывалась версия для int.

#include <stdio.h>

int main()
{
    int sz = sizeof('A');  // латинское
    printf("sz = %d\n", sz);
    return 0;
}

Си: 4
Си++: 1

При написании char test='A' на стеке будет 1 байт (+выравнивание). Здесь Си, грубо говоря, проводит преобразование типа — прямо при компиляции. Если написать char test=L'Й', сообщит, что преобразование при компиляции ushort→char обрежет результат с 1049 до 25.

HMAC — это так называемая имитовставка.
То есть нечто среднее между хэш-функцией и электронной подписью.
Тот, кто изменил сообщение и не знает ключа, НЕ МОЖЕТ подделать имитовставку — в отличие от хэш-функции.
Но ключ подписи и проверки ОДИН И ТОТ ЖЕ — в отличие от электронной подписи.

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

К сожалению, только сигналы — и ключевое слово BlockingQueuedConnection.
А всё остальное — это как сделать синхроблок рядом с процедурой, а сигнал-слот — где-нибудь в главном окне. Скажем, так.

class AsyncSimpleContext {  // интерфейс
public:
  virtual void syncExec(const Runnable& body) = 0;
  template <class Body>
  void syncExecT(const Body& body); // тело упущу, тут всё стандартно,
                                         // идиома «виртуальный шаблон»
}

class FmMain : public AsyncSimpleContext
{
  // Разрешите не писать реализацию syncExec — тут всё просто:
  // в конструкторе соединить сигнал со слотом методом BlockingQueuedConnection
  // в syncExec проверить id потока и или вызвать прямо, или возбудить сигнал.
signals:
   void sigSyncExec(const Runnable&);
private slots:
   void slotSyncExec(const Runnable&);
}

…и передавая куда-нибудь как-нибудь интерфейс AsyncSimpleContext, мы можем синхронизировать что-то с интерфейсом.

Шаблонный класс.
Гугли «Java Generics»

String — Input parameter type
Integer — progress report type
String — result parameter type

Сайт может быть:
• преимущественно настольный (Посмотре.ли);
• преимущественно мобильный (Эгея. Или вот знакомая пишет внутреннюю систему учёта отпускных — всё сделано, чтобы работало с мобилы);
• адаптивный (Розетка — простите, я с Украины. Ну и Хабр Q&A);
• с сильно разными шкурками под настольный и мобильный (Википедия, YouTube)

Какие факторы на это влияют:
• Умение веб-программиста — что он умеет, то и пишет.
• Используемый инструментарий — скажем, у нас есть древний сайт, надо переписать под мобилу.
• Соотношение «настольный/мобильный» — например, заказ пиццы обязательно делать преимущественно мобильным или адаптивным.
• Контент — если много картинок, приходится думать. И наоборот, простой блог без проблем можно сделать преимущественно мобильным, что и сделал Бирман в своей Эгее.
• Особый настольный инструментарий — например, вики смотрят и с мобилы, но редактирование с мобилы — крайне редкий сценарий и обычно ограничивается редактурой. YouTube с мобилы много глазеют, но залить с мобилы — дело значительно более редкое. И уж совсем редкое — управлять видеоблогом с мобилы.

Кодовая база общая, разные только шкурки.