Wataru

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

Подсказка: вот то число, что у вас в конце выводится - это 2^64-1. Еще подсказка: size_t на современных платформах имеет размер 64 бита.

У вас переполнение. Вы там из 0 вычитаете 1 в итерации цикла, получаете самое большое число, представимое в 64-битном типе.

Надо переписать цикл на while и делать из него break по достижению 0. Или тип переменной сменить на знаковый.

Вам нужна lock-free хеш таблица (гуглите Lock free unordered_map). В стандартной библиотеке таких структур нет. Или просто используйте свои мьютексы при каждом обращении к структуре.

iostream - лишь обертка над системными вызовами. Входной и выходной потоки - это концепция системы.

Это целый набор шаблонных классов, которые переопределяют операции побитового сдвига, поэтому у вас в программе используются << и >>. Под капотом это все доходит до системных вызовов, которые пишут или читают данные в системные потоки (pipe). Там тупо команды "запиши вот эти байты" и "отдай мне вот в этот буфер максимум столько-то байт".

Система, насколько я знаю, для каждого pipe'а поддерживает какой-нибудь кольцевой буфер в который процессы могут писать и читать оттуда, через системные вызовы выше.

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

ОС-ка поддерживает список потоков, которые ждут чтения из каждого буфера. Когда что-то в буфер записывается, эти потоки просыпаются.

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

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

Или у вас вопрос, почему указатель? Ну ведь фунция - это огромный кусок кода в памяти. Логично же ее передавать как указатель, как и массивы, например. Но тут есть еще и низкоуровневая проблема - в процессоре есть защита от исполнения данных. Без дополнительных танцев с бубном, вы никак данные не выполните, даже если там записан корректный машинный код. Поэтому все функции записаны в read-only секции памяти, специально помеченной, как разрешенная к исполнению. Поэтому единственный сопособ как-то эти данные куда-то передать - это указатель туда. Сами данные-то не перемещаемые.

Без разницы. Используйте то, что логичнее смотрится в коде. Разницу в производительности, во-первых, вы получите лишь в очень специфичных случаях (при передаче в функцию enum скорее всего окажется в регистре, а вот структура полезет на стек. В итоге enum окажется быстрее), во-вторых, только если читать вы будете миллионы стркутур. И то, вам должно не повезсти с кешем процессора и префетчером.

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

Надо или использовать std::vector, или самосталятельно выделять под массив память. Тогда массив будет просто int*, выделяете его как new int[n]. Не забудьте в этом случае сделать delete[] в деструкторе.

Судя по ошибке, это компилятор GCC.
MSVC и Clang выдают чуть-чуть другие сообщения об ошибке.

Вот минимальный рабочий пример. В вашей реализации return_type проблема в том, что вы этот шаблон применяете к указателю на функцию. Если там поставить * в специализации шаблона - то все компилируется и даже работает.

template<typename T>
struct return_type;
template<typename R, typename... Args>
struct return_type<R(*)(Args...)>
{
	using type = R;
};

typedef bool (*function)(int);

template<typename T>
class smart_pointer {
public:    
    smart_pointer(T func) : func_(func) {}
    
    template<typename R = typename return_type<T>::type, typename ...Args>
    R operator()(Args... args) const {
        return func_(args...);
    }
    
    T func_;
};

bool foo(int t) {
    return t % 2 == 0;
}


int main() {
    smart_pointer<function> sm(&foo);
    std::cout << sm(5);

    return 0;
}

Приоритеты операций.

Без скобочек сначала выполняется <<. Фактически, у вас написано вот это: (std::cout<<a) == b;
<< - переопределенный оператор для std::cout, он выведет a на экран и вернет ссылку на std::cout, которую потом программа попытается сравнить с b и не сможет, потому что операция такого сравнения не определена.

Если же поставить скобки, то сначала выполнится ==, результат ее работы - bool - уже потом будет через оператор << выведен в на экран.

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

Из документации:

You cannot paste a DIB section from one application into another application.

Можно после изменения данных в DIB section сделать нормальный битмап через CreateDiBitmap.

А еще лучше, вместо CreateDIBSection, скопируйте данные из битмапа через GetDIBits, измените их и скопируйте назад в битмап через SetDIBits.