Не так давно я стал присматриваться к языку программирования Rust. Прочитав Rustbook, изучив код некоторых популярных проектов, я решил своими руками попробовать этот язык программирования и своими глазами оценить его преимущества и недостатки, его производительность и эко-систему.

Язык Rust позиционирует себя, как язык системного программирования, поэтому основным его vis-à-vis следует называть C/C++. Сравнивать же молодой и мультипарадигмальный Rust, который поддерживает множество современных конструкций программирования (таких, как итераторы, RAII и др.) с «голым» C я считаю не правильно. Поэтому в данной статье речь пойдет об сравнении с C++.

Чтобы сравнить код и производительность Rust и C++, я взял ряд алгоритмических задач, которые нашел в онлайн курсах по программированию и алгоритмам.

Статья построена следующим образом: в первой части я опишу основные плюсы и минусы, на которые я обратил внимание, работая с Rust. Во второй части я приведу краткое описание алгоритмических задач, которые были решены в Rust и C++, прокомментирую основные моменты реализации программ. В третьей части будет приведена таблица замера производительности программ на Rust и C++.

Представлять WebAssembly не нужно — поддержка уже есть в современных браузерах. Но технология годится не только для них.

WebAssembly — кроссплатформенный байткод. Значит, этот байткод можно запустить на любой платформе, где есть его виртуальная машина. И для этого вовсе не нужен браузер и Javascript-движок.

Далее — проверка концепции на прочность, инструментарий и первый скриптовый модуль.

Как только, фрагментный шейдер обработал фрагмент, выполняется так называемый тест трафарета, который, как и тест глубины, может отбрасывать фрагменты. Затем оставшиеся фрагменты переходят к тесту глубины, который, может отбросить еще больше фрагментов. Трафаретный тест основан на содержимом еще одного буфера, называемого трафаретным буфером. Мы можем обновлять его во время рендеринга для достижения интересных эффектов.

Данная статья является расшифровкой (с небольшими правками) доклада Антона antoshkka Полухина — “Немного магии для C++14”.

Я тут недавно ковырялся с C++ и случайно открыл пару новых приемов метапрограммирования, которые позволяют делать рефлексию в C++14. Пара мотивационных примеров. Вот у вас есть какая-то POD структура, в ней какие-то поля:

struct complicated_struct {
    int i;
    short s;
    double d;
    unsigned u;
};

Количество полей и их имена не имеют значение, важно то, что с этой структуры мы можем написать следующий кусочек кода:

#include <iostream>
#include "magic_get.hpp"

struct complicated_struct { /* … */ };

int main() {
    using namespace pod_ops;
    complicated_struct s {1, 2, 3.0, 4};
    std::cout << "s == " << s << std::endl; // Compile time error?
}

Функция main, в ней создаем переменную нашей структуры, как-то ее инициализируем через aggregate инициализацию, а потом эту переменную пытаемся вывести в std::cout. И в этот момент у нас, по идее, должна быть ошибка компиляции: мы не определили оператор вывода в поток для нашей структуры, компилятор не знает как все это скомпилировать и вывести. Однако, оно скомпилируется и выведет содержимое структуры:

antoshkka@home:~$ ./test
s == {1, 2, 3.0, 4}

Каждый разработчик С++ рано или поздно сталкивается с особенностями конвертации дробного числа из строкового представления (std::string) в непосредственно число с плавающей точкой (float), связанными с установленной локалью (locale). Как правило, проблема возникает с различным представлением разделителя целой и дробной частей в десятичной записи числа ("," или ".").

В данной статье речь пойдет о двойственности локалей С++. Если Вам интересно, почему преобразование одной и той же std::string("0.1") с помощью std::stof() и std::istringstream во float может привести к различным результатам, прошу под кат.

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

Наша команда приготовила всем разработчикам на C и C++ новогодний подарок под елку – новый релиз CLion 2017.3! В этом посте постараемся рассказать, чем он хорош, прикинуть дальнейшие направления для развития продукта и, конечно, ответить на все интересующие вас вопросы в комментариях.



Коротко об основных улучшениях для тех, кто не хочет много читать:

• Поддержка языка C++
  
  
  • Улучшения в таких подсистемах парсера, как list initialization и name lookup
  • Поддержка расширений специфичных для компилятора Microsoft Visual C++
  • Поддержка макроса __COUNTER__
  • И не только!
• Новые инструменты и фреймворки
  
  
  • Valgrind Memcheck
  • Boost.Test
  • CMake 3.9, GDB 8.0, LLDB 5.0
• Существенные переработки и расширение возможностей в настройке компилятора, окружения, CMake, отладчика, и пр.
• Возможность запуска почти произвольной функции main, иконки для запуска функций main и тестов
• Возможность разрабатывать на Kotlin/Native в CLion

Можно прямо сейчас скачать бесплатную 30-дневную версию с нашего сайта и попробовать новые возможности (для этого мы даже подготовили специальный небольшой демо-проект). А ниже мы поговорим об улучшениях более подробно.

В этой статье я хочу обсудить шаблон проектирования «сущность-компонент-система» (Entity-Component-System, ECS). По этой теме можно найти много информации в Интернете, поэтому я не буду глубоко вдаваться в объяснения, а больше расскажу о моей собственной реализации.

Часть 1: Реализация шаблона Entity-Component-System на C++

Начнём сначала. Полный исходный код моей реализации ECS можно найти в репозитории на github.

Entity-Component-System, в основном используемый в играх — это шаблон проектирования, обеспечивающий огромную гибкость в проектировании общей архитектуры программного обеспечения^[1]. Такие большие компании, как Unity, Epic или Crytek используют этот шаблон в своих фреймворках, чтобы предоставить разработчикам очень богатый возможностями инструмент, с помощью которого они могут разрабатывать собственное ПО. Прочитать более широкое обсуждение по этой тематике можно в этих постах ^[2,3,4,5].

Недавно сайт Pinguem.ru совместно с командой PVS-Studio устраивали конкурс, в котором программистам было необходимо в течение месяца использовать статический анализатор PVS-Studio для нахождения и исправления ошибок в коде open-source проектов. Благодаря их стараниям, программы в мире стали чуточку безопаснее и надежнее. В статье мы рассмотрим парочку наиболее интересных ошибок, которые были найдены при помощи PVS-Studio.

Всем привет! В этой статье я расскажу об API BIM-системы Renga. О самой системе можно почитать тут, здесь же можно запросить версию для некоммерческого использования. Если вкратце, то Renga это трехмерная система автоматизированного проектирования в архитектуре и строительстве. В ней проектировщик/архитектор/конструктор работает с информационной моделью здания, получает ассоциативные чертежи, спецификации, в общем, создает проект.

Зачем нужно API CAD-системы

Сначала, как водится, немного водички.

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

Мы поговорим о восьми удобных изменениях, которые влияют на ваш повседневный код. Четыре изменения касаются самого языка, а ещё четыре — его стандартной библиотеки.

Вам также может быть интересна статья Десять возможностей C++11, которые должен использовать каждый C++ разработчик

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

Инфографика:



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

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

Вот почему мы создали Figma, командный инструмент работы над дизайном интерфейсов, как облачный сервис, распространяемый в виде веб-приложения.

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

Дорога к результату была очень непроста; в итоге, мы практически создали браузер внутри браузера.

Хотя Discord — это приложение для голосового и текстового чата, каждый день через него проходит более ста миллионов изображений. Конечно, мы бы хотели, чтобы задача была простой: просто перенаправить картинки вашим друзьям по всем каналам. Но в реальности доставка этих изображений создаёт довольно большие технические проблемы. Прямая ссылка на картинки выдаст хосту с картинкой IP-адреса пользователей, а большие изображения расходуют много трафика. Чтобы избежать этих проблем, требуется промежуточный сервис, который будет получать изображения для пользователей и изменять их размер для экономии трафика.

Встречайте Image Proxy

Для выполнения этой работы мы создали сервис Python и креативно назвали его Image Proxy. Он загружает картинки с удалённых URL, а затем выполняет ресурсоёмкую задачу по ресайзингу с помощью пакета pillow-simd. Этот пакет работает удивительно быстро, используя где только возможно для ускорения ресайзинга инструкции x86 SSE. Image Proxy будет получать HTTP-запрос, содержащий URL, чтобы загрузить, изменить размер и, наконец, выдать окончательное изображение.

Среди программистов очень популярны разговоры о «повторном использовании кода» — и в основном об этом говорят в позитивном ключе. Нам нравится говорить, что спроектированные нами конструкции являются «универсальными» и «пригодными к использованию в других проектах». Почему это считается хорошей вещью легко понять — всем хочется реализовать следующий проект вдвое быстрее предыдущего за счет использования уже имеющихся наработок.

Но когда дело доходит до этого на практике — чаще всего что-то идёт не так. Есть одна очень умная мысль на этот счёт: «Не пытайтесь делать код переиспользуемым, пока вы не видите как минимум три разных места, где его можно будет применить». Я считаю этот совет очень хорошим — я видел немало ситуаций, когда он помог (или помог бы) избежать одержимости попытками написания переиспользуемого кода там, где проблему можно было решить для одного конкретного случая «здесь и сейчас».

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

Здравствуйте. Сегодня речь пойдёт про Conan — современный менеджер зависимостей для C/C++. Если Вы уже активно работаете с ним, то навряд ли найдёте что-нибудь новое для себя. Иначе — прошу под кат.

Я продолжаю обзор кода музыкальных приложений, и перед нами первый представитель коммерческого программного обеспечения. В комментариях к предыдущим статьям я заметил популярность программы Cubase и решил почитать о ней. Это продукт компании Steinberg, у которой есть несколько программ с закрытым исходным кодом. Случайно на их сайте я нашёл SDK для сторонних разработчиков, и, изучив его, обнаружил множество интересных ошибок.

Ardour пока является самым крупным из музыкальных проектов, участвующих в обзоре дефектов кода. Проект включает около 1000 файлов исходного кода на языке C++. Проект активно поддерживается сообществом разработчиков, при этом я не нашёл упоминаний об использовании каких-либо инструментов статического анализа. Как следствие — множество ошибок разного характера. В статье будут описаны самые интересные из них.

Из центральной части Канады — на юго-запад США! Альбукерке расположен в штате Нью-Мексико:



На встрече международного комитета по стандартизации C++, которая прошла в этом городе, приняли одно очень большое нововведение в С++20 и несколько маленьких.

Продолжаем цикл статей по работе с API САПР КОМПАС-3D Сергея Норсеева, инженера-программиста АО «ВНИИ «Сигнал», автора книги «Разработка приложений под КОМПАС в Delphi». В качестве среды используется C++ Builder. В предыдущих уроках по API КОМПАС Основы и Оформление чертежа мы исходили из того, что КОМПАС не запущен, в уроке Корректное подключение к КОМПАС мы проверяли наличие уже запущенного КОМПАСа и подключались к нему. В уроке Основная надпись разбирали, как заполнить основную надпись чертежа. В прошлом уроке Графические примитивы мы начали чертить первые геометрические фигуры. В данной статье рассматриваются различные способы построения дуги окружности. В КОМПАС ее можно построить тремя различными способами. Мы рассмотрим их все.

Привет, Хабр! Это снова Larian Studios. Уф, у нас прошёл релиз, и теперь наконец-то появилось время продолжить делиться с вами нашим опытом и наработками.

Сегодня я расскажу о самом главном инструменте, с помощью которого родилось уже 4 проекта — о кофемашине внутреннем редакторе игры. Редактор доступен в ограниченном (для моддеров и игроков) виде в Steam/GoG, поэтому каждый, кто приобрел игру, может скачать его и попробовать бесплатно.

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

Ну и еще расскажу, чем занимаются Tools Programmer в нашей студии.