Всем привет!

Мы выложили в открытый доступ видео прошедшей в феврале конференции C++ Russia 2017. Самое время вспомнить как круто было на конференции, освежить в памяти понравившиеся доклады.

3 июня пройдет встреча в Казани, под катом информация о докладах, которые будут представлены на ней и немного о разном.

Раньше всё было лучше: компьютеры были большими, а буквы на экране — зелёными. Тогда они ещё назывались ЭВМ, а инженеры ходили по машинному залу в белых халатах. В те благословенные времена никто не заморачивался на тему user friendly-интерфейсов, а просто требовали от пользователя подготовить колоду перфокарт в соответствии с определённым форматом. Подготовил неверно — сам виноват. Это кажется не очень удобным и вовсе не «интуитивно понятным», но данный спартанский подход позволял обсчитывать весьма серьёзные задачи вроде моделирования ядерных реакций или расчёт полётного задания для космических ракет. И всё это при ресурсах, на два-три порядка меньших, чем почти любой современный смартфон.

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

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.

В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Это окончание статьи, начало тут.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.

В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Это продолжение статьи, а начало тут.

Примерно год назад вышла моя статья, которую можно назвать "первой частью" данной статьи. В первой части я насколько смог подробно разобрал тернистый путь разработчика-энтузиаста, который мне удалось когда-то самостоятельно пройти от начала и до конца. Результатом этих усилий стала игра жанра RTS "Земля онимодов" созданная мною в домашних условиях без движков, конструкторов и прочих современных средств разработки. Для проекта использовались C++ и Ассемблер, ну, и в качестве основного инструмента моя собственная голова.
В этой статье я постараюсь рассказать о том, как я решил взять на себя роль «реаниматора» и попытаться «воскресить» этот проект. Много внимания будет уделено написанию собственного игрового сервера.

Порой кажется, что на фронте борьбы с проблемой 2038 года наступило относительное затишье. Однако время идет, и тот день, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, наступит уже меньше чем через 21 год. Этот срок может показаться большим, однако сравнительно долгий жизненный цикл многих встраиваемых систем подразумевает, что некоторые из них, будучи введенными в строй в наше время, все еще будут работать, когда наступит критический момент. Арнд Бергманн — один из основных разработчиков, занимающихся этой проблемой. На конференции Linaro Connect 2017 он поделился новостями о текущем положении дел в этой области.

Название статьи намекает разработчикам Visual Studio, что они могут получать пользу от использования статического анализатора кода PVS-Studio. В статье приводятся результаты анализа библиотек, входящих в состав недавно выпущенной версии Visual C++ 2017, и даются рекомендации по улучшению и устранению ошибок. Приглашаю читателей узнать, как разработчики Visual C++ Libraries отстреливают ноги: будет интересно и познавательно.

В предыдущем уроке обсуждалась матрица вида, и то, как её можно использовать для перемещения по сцене (мы немного отодвинули назад точку зрения наблюдателя). В OpenGL отсутствует концепция камеры, но можно попытаться её сымитировать, перемещая все объекты сцены в направлении противоположном движению наблюдателя, и тем самым создать иллюзию, что движемся мы сами.

В этом уроке мы рассмотрим, как можно создать камеру в OpenGL. Мы обсудим камеру типа FPS (First Person Shooter), которая позволит вам свободно перемещаться в трехмерной сцене. Кроме того, мы поговорим о вводе с клавиатуры и мыши, а закончим созданием собственного C++ класса камеры.

Всем привет. Потихоньку перебирая листы книг, занимаюсь я серверным программированием. И дошёл мой разум до того, что можно было бы и на C++ сервер написать. Ну и недолго думая(точнее вообще не думая и плохо зная плюсы), я пошёл писать сервер.

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

Начнём с самого главного элемента — класс сервера SServer:

Я думаю, все знают, что такое наследование или хотя бы слышали о нём. Часто мы используем наследование ради полиморфного поведения объектов. Но задумываемся ли мы о той цене, которую приходится платить за виртуальность? Поставлю вопрос по-другому: каждый ли знает эту цену? Давайте попробуем разобраться в этой проблеме.

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

Русскоязычные видео

Статический анализ кода

Я часто встречаю критику фреймворка Qt, в которой ему пеняют использованием мета-объектного компилятора (утилиты moc). Как один из разработчиков moc, я решил написать данную статью с целью развенчать некоторые связанные с этим мифы.

Вступление

Moc — это один из инструментов разработчика и часть библиотеки Qt. Его задача — поддерживать расширение языка С++, необходимое для интроспекции и рефлексии в Qt (сюда относятся сигналы, слоты и QML). Для более детального объяснение вы можете почитать о том, как работают сигналы и слоты в Qt.

Необходимость использования moc является одним из главных объектов критики Qt. Это даже привело к появлению форков Qt, принципиально отказавшихся от moc (например, CopperSpice). Но всё-же большинство приписываемых moc так называемых недостатков не обоснованы.

27 апреля 2017 года в 19.00 приглашаем разработчиков C++ на VeloCPPed Meetup в главный офис компании «Тензор» в Ярославле на ул. Угличской 36/44

Поговорим о промышленной разработке крупных приложений на С++ — поделимся опытом управления огромной кодовой базой (2 млн. SLOC) и процессом ее создания. Разберемся, как ускорить и удешевить разработку продукта.

Программа Meetup

Это будет история младшего разработчика из Яндекс.Паспорта о появлении предложения в стандарт С++, разработанного в соавторстве с Антоном antoshkka Полухиным. Как часто бывает в жизни, что-то новое началось с боли, а точнее — с желания её прекратить.

Жила-была библиотека у меня на поддержке. Всё у неё было хорошо: собиралась под Linux, работала, не падала. Однажды пришли люди с просьбой (требованием) собрать её под Windows. Почему бы и нет? Но с первого раза не получилось. Корнем зла оказалась рукописная криптография, которая в какой-то момент умножала два 64-битных целых числа. Для сохранения результата такого умножения потребуется число на 128 бит, и в библиотеке использовался тип __int128. Он прекрасен: имеет естественный интерфейс, поддерживается несколькими компиляторами (gcc, clang), работает без аллокации памяти, но главное — он есть.

Опираясь на материал, описанный в первой, второй и третьей частях данной статьи, мы продолжим обсуждение темы обработки исключений в Windows x64.

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

Возможно, кто-то, прочитав заголовок, спросит: «Зачем что-то делать со своим кодом?! Ведь С++ кроссплатформенный язык!». В целом, это так… но только пока нигде нет завязок на специфичные возможности компилятора и целевой платформы…

В реальной жизни разработчики, решающие конкретную задачу под конкретную платформу, редко задаются вопросом «А точно ли это соответствует Стандарту С++? А вдруг это расширение моего компилятора». Они пишут код, запускают сборку и чинят места, на которые выругался их компилятор.

В итоге получаем приложение, которое, в некоторой степени, «заточено» под конкретный компилятор (и даже под его конкретную версию!) и целевую ОС. Более того, из-за скудности стандартной библиотеки С++ некоторые вещи просто невозможно написать, не воспользовавшись специфичным API системы.

Так было и у нас в Тензоре. Мы писали на MS Visual Studio 2010. Наши продукты были 32-х битными Windows-приложениями. И, само собой, код был пронизан всевозможными завязками на технологии от Microsoft. Однажды мы решили, что пора осваивать новые горизонты: пора научить СБИС работать под Linux и другими ОС, пора попробовать перейти на другое «железо» (POWER).

В данном цикле статей я расскажу, как мы сделали свои продукты настоящими кроссплатформенными приложениями; как заставили их работать на Linux, MacOS и даже под iOS и Android; как запустили свои приложения на множестве аппаратных архитектур (x86-64, POWER, ARM и другие); как научили работать на big-endian машинах.

17 апреля мы перезапустили онлайн-курс «Углублённое программирование на С/С++» на платформе Stepik. Это курс для тех, кто знает С++ и хочет научиться использовать его в промышленной разработке. Мы упростили доступ к модулям, чтобы вы прошли курс в удобное время и получили сертификат. Но обо всём по порядку.

В статье на примерах объясняется, как реализовать поддержку потокового ввода-вывода из стандартной библиотеки (<iostream>) для своих классов.

В тексте статьи будет часто встречаться слово «поток», что означает именно поток ввода-вывода ((i/o)stream), но не поток выполнения (thread). Потоки выполнения в статье не рассматриваются.

Введение

Потоки из стандартной библиотеки — мощный инструмент. Аргументом функции можно указать поток, и это обеспечивает ее универсальность: она может работать как со стандартными файлами (fstream) и консолью (cin/cout), так и с сокетами и COM-портами, если найти соответствующую библиотеку.

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

При 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. Всех интересующихся прошу под кат.

Хабра, привет!

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

Разговор о программировании под Linux медленно перешел к тому, что этот человек стал утверждать, что сложность системного программирования на самом деле сильно преувеличена. Что язык Си прост как спичка, собственно как и ядро Linux (с его слов).

У меня был с собой ноутбук с Linux, на котором присутствовал джентльменский набор утилит для разработки на языке Си (gcc, vim, make, valgrind, gdb). Я уже не помню, какую цель мы тогда перед собой поставили, но через пару минут мой оппонент оказался за этим ноутбуком, полностью готовый решать задачу.

И буквально на первых же строках он допустил серьезную ошибку при аллоцировании памяти под… строку.

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

buffer — стековая переменная, в которую заносились данные с клавиатуры.

Я думаю, определенно найдутся люди, которые спросят: «Разве что-то тут может быть не так?».
Поверьте, может.

А что именно — читайте по катом.