При unit-тестированиии кода рано или поздно встает вопрос тестовых данных. И если в одном случае достаточно просто несколько жестко зашитых переменных, то в других случаях необходимы сколько-нибудь большие и случайные данные. В управляемом мире нет проблем с генерацией пользовательских типов (взять тот же Autofixture), но мир C++ зачастую вызывает боль и страдание (поправьте меня, если это не так). Не так давно я познакомился с замечательной библиотекой boost::di и под ее влиянием у меня начала созревать идея библиотеки, которая позволила бы C++ программистам генерировать пользовательские типы данных, забитых случайными значаниями, и это не потребовало бы предварительного их описания. Получилось что-то вроде:

struct dummy_member{
    float a;
    int b;
};
struct dummy{
    explicit dummy(dummy_member val, std::string c) : val_(val), c_(c) {}
private:
    dummy_member val_;
    std::string c_;
};
int main(int argc, char* argv){
    auto d = datagen::random<dummy>();
    return 0;
}

→ Ссылка на код. Библиотека header-only,C++14. Всех интересующихся прошу под кат.

char *str = (char *)malloc(sizeof(char) * strlen(buffer));

В данной статье будет рассмотрено функциональное программирование на примере скрипта поиска битых ссылок с использованием AnyEvent::HTTP. Будут рассмотрены следующие темы:

• анонимные подпрограммы;
• замыкания (closures);
• функции обратного вызова (callbacks);

Важным условием корректности построенного эскиза является непротиворечивость наложенных ограничений. Если наложено меньше ограничений, чем требуется, некоторые параметры не могут быть однозначно определены, поэтому могут изменяться в некотором диапазоне значений. В таких случаях говорят, что чертеж имеет степени свободы (Degrees Of Freedom; DOF). Анализ степеней свободы позволяет инженеру-конструктору накладывать только необходимое и достаточное количество ограничений, не позволяя системе уравнений быть переопределенной (overconstrained), и не позволяя оставить какую-либо степень свободы без наложенных ограничений.
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

(gdb) p/t table->read_set->bitmap[0] @ (table->read_set->n_bits+7)/8

• Поддержка C++14 (всё кроме constexpr)
• Начальная поддержка C++17 (мы начали с самой востребованной возможности – nested namespaces)
• Возможность конвертировать тип переменной в auto
• Во время отладки программы, при отсутствии файлов с исходным кодом можно переходить на код на дизассемблере (disassembly view)
• Поддержка фреймворка для юнит-тестирования Catch
• Значительное ускорение отклика редактора при печати кода (Zero Latency Typing)
• И, наконец, экспериментальная поддержка компилятора Microsoft Visual C++!

В комментариях к последней статье про шишки, которые нам довелось набить за 15 лет использования акторов в C++, вновь всплыла тема отсутствия в SObjectizer-5 распределенности «из коробки». Мы уже отвечали на эти вопросы множество раз, но очевидно, что этого недостаточно.

В SObjectizer-5 нет распределенности потому, что в SObjectizer-4 поддержка распределенности была, но по мере того, как расширялся спектр решаемых на SObjectizer задач и росли нагрузки на SObjectizer-приложения, нам пришлось выучить несколько уроков:

• Под каждый тип задачи желательно иметь свой специализированный протокол. Потому что обмен большим количеством мелких сообщений, потеря части которых не страшна, сильно отличается от обмена большими бинарными файлами;
• Реализация back-pressure для асинхронных агентов — это сама по себе непростая штука. А когда сюда еще и примешивается общение по сети, ситуация становится гораздо хуже;
• Сегодня какие-то куски распределенного приложения обязательно будут написаны на других языках программирования, а не на C++. Поэтому требуется интероперабильность и наш собственный протокол, заточенный под C++ и SObjectizer, мешает разработке распределенных приложений.

Далее в статье попробуем раскрыть тему подробнее.

Работа со временем как с безразмерной величиной может приводить к недоразумениям и ошибкам конвертации временных единиц измерения:

– Слушай, ты не помнишь, мы в sleep передаем секунды или миллисекунды?

– Блин, оказывается у меня в часе 360 секунд, ноль пропустил.

Для избежания таких ошибок предусмотрена библиотека chrono (namespace std::chrono). Она была добавлена в C++11 и дорабатывалась в поздних стандартах. Теперь все логично:

using namespace std::chrono;

int find_answer_to_the_ultimate_question_of_life()
{
    //Поиск ответа
    std::this_thread::sleep_for(5s); //5 секунд
    return 42;
}

std::future<int> f = std::async(find_answer_to_the_ultimate_question_of_life);

//Ждем максимум 2.5 секунд
if (f.wait_for(2500ms) == std::future_status::ready)
    std::cout << "Answer is: " << f.get() << "\n";
else
    std::cout << "Can't wait anymore\n";

Библиотека реализует следующие концепции:

• интервалы времени – duration;
• моменты времени – time_point;
• таймеры – clock.

Завершаем рассказ, начатый в первой части. Сегодня рассмотрим еще несколько граблей, на которые довелось наступить за годы использования SObjectizer-а в повседневной работе.

Продолжаем перечислять грабли

Народ хочет синхронности...

Акторы в Модели Акторов и агенты у нас в SObjectizer общаются посредством асинхронных сообщений. И в этом кроется одна из причин привлекательности Модели Акторов для некоторых типов задач. Казалось бы, асинхронность — это один из краеугольных камней, один из бонусов, поэтому пользуйся себе на здоровье и получай удовольствие.

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

Выглядит в коде это вот так: