C++ *

 Отличный онлайн-учебник по C++

⏩Держите годный онлайн-учебник по C++, здесь обсуждаются самые нужные темы, много кода с детальным объяснением, много практических заданий

Вот некоторые из обсуждаемых тем: 

 • Множественное и виртуальное наследование

 • Идентификация типов во время выполнения

 • Определение шаблона функции

 • Абстрактные контейнерные типы

 • Перегрузка операторов

 • Область видимости и время жизни

 • Инициализация, присваивание и уничтожение класса

📎 Учебник

А здесь еще 13 ресурсов для C++ разработчиков , которые помогут закрепить теорию и поупражняться в программировании 

27 и 28 марта в Лондоне проходила конференция Rust Nation 24. На конференции выступал Ларс Бергстром [Lars Bergstrom], который занимает в Google пост технического директора. Доклад Ларса носил название «Beyond Safety and Speed: How Rust Fuels Team Productivity» (дословно «Кроме безопасности и скорости: как Rust заряжает команду продуктивностью»).

Во время выступления технический директор Google заявил, что команды Rust в Google в два раза продуктивнее команд C++. Этот мощный посыл успел разлететься фотографией с конференции.

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

Как выяснилось, на переписывание на Rust нужно примерно столько же времени и людей, сколько уходит на написание продукта на Go. При этом памяти приложения на Rust используют куда меньше, в них меньше дефектов. Когда компонент на C++ переписывают на Rust при одинаковом размере команд, в два или более раз сокращаются время и усилия как для написания, так и поддержки кода.

Слегка портит картину то, что Бергстром — это ещё и председатель совета директоров Rust Foundation, поэтому делать такие заявления он непосредственно заинтересован.

На записи видеотрансляции с конференции обсуждение деталей производительности идёт с отметки 7:30:13.

Проклятие дженериков 💀

Дженерики могут показаться очень простой темой.
Например, вот так в Java выглядят классные и простые методы интерфейса List:

interface List<E> extends Collection<E> {
	boolean add(E e);
	E set(int index, E element);
}

Но у обобщений много нюансов: вложенность, вариантность, границы и т.д. Это сильно усложняет их использование.
Вот не менее классный, но совсем непростой flatMap интерфейса Stream🙈:

interface Stream<T> extends BaseStream<T, Stream<T>> {
	<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper);
}

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

Из-за таких сложностей, в языке Go (философия которого - простота и минимализм) дженерики появились аж через 12 лет после релиза языка. А первый коммент про то что нужны дженерики появился меньше чем через 24 часа🙃

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

• С++ вышел в 1979, дженерики - 1986

• Java - 1996, дженерики - 2004

• C# - 2001, дженерики - 2005

• Go - 2009, дженерики - 2021

Состоялся релиз открытой библиотеки Intel x86-simd-sort 5.0, в которой представлен новый API для сортировки пользовательских объектов C++ с помощью object_qsort.

Согласно тестам разработчиков проекта, новая поддержка сортировки пользовательских объектов C++ может быть в 4-5 раз быстрее, чем использование std::sort в системах AVX-512, но в конечном итоге влияние на производительность будет варьироваться в зависимости от используемых задач.

Также в выпуске x86-simd-sort 5.0 добавлен новый API-интерфейс keyvalue_qsort для сортировки массивов, представляющих пары «ключ-значение», и этот новый API тоже работает намного быстрее.

В версии x86-simd-sort 5.0 добавлена поддержка AVX2 для методов argosrt и argselect. Эти дополнения AVX2 уже вошли в исходную версию NumPy для NumPy 2.0, причем эта библиотека Python была одним из первых проектов, который добавил поддержку высокопроизводительной библиотеки Intel.

Состоялся релиз мажорной версии библиотеки GLM 1.0.0 (OpenGL Mathematics).

OpenGL Mathematics (GLM) — это header only математическая библиотека C++, предназначенная для графического ПО, основанная на спецификациях языка шейдинга OpenGL (GLSL).

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

Проект GLM не ограничивается функциями GLSL. Системные расширения проекта основаны на extension conventions GLSL и предоставляют расширенные возможности, включая матричные преобразования, кватернионы, упаковку данных, случайные числа, шум и так далее.

Разработчики пояснили, что библиотека стабильно работает с OpenGL, но также обеспечивает совместимость с другими сторонними библиотеками и SDK. Это хороший кандидат для программного рендеринга (трассировка лучей/растеризация), обработки изображений, физического моделирования и любого контекста разработки, требующего простой и удобной математической библиотеки.

GLM написан на C++98, но может использовать преимущества C++11, если он поддерживается компилятором. Это независимая от платформы библиотека, независимая и официально поддерживающая следующие компиляторы:

• GCC 4.7 and higher;

• Intel C++ Compose XE 2013 and higher;

• Clang 3.4 and higher;

• Apple Clang 6.0 and higher;

• Visual C++ 2013 and higher;

• CUDA 9.0 and higher (experimental);

• Any C++11 compiler.

Что нужно учитывать, используя std::vector?

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

std::vector имеет:

• [+] Доступ к произвольному элементу за O(1).

• [-] Проблема: При превышении capacity - долгая вставка нового элемента (даже в конец), тербующая поэлементного копирования.
  
  Решение: С этим можно побороться, если зарезервировать заранее всю нужную память под все элементы, но мы редко знаем каким будет максимальное количество элементов. И памяти на все процессы так не напасёшься, даже учитывая оптимизацию современных ОС: когда ОС физически выделяет память только когда процесс начинает её использовать.

• Хороший cache coherence:

  • [+] В общем случае это означает более быстрый обход контейнера vector по сравнению с контейнерами а-ля list (map, set, forward_list etc.).

  • [-] Проблема: В частности, нужно разбиратсья с cache sharing.
    Если vector параллельно обходят два потока и каждый из них модифицирует его содержимое, то вероятно кэши этих потоков будет смотеть на смежную область памяти vector-а. Тогда каждая из записей будет инвалидировать содержимое кеша ядра другого потока, тем самым приводя к регулярному refetch-у. В некоторых корнер кейсах замена vector на list может внезапно привести к улучшению перфоманса.
    
    Решение: Лечится такая проблема обычно увеличением размера элемента до размера кэшлайна. Либо же выдачей каждому потоку по N элементов, где (N * sizeof(ElementT)) == cacheline size.

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

Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра.

С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков ядра в компании Intel и создатель таких проектов, как syslinux, klibc и LANANA, разработавший для ядра Linux систему автомонтирования, реализацию RAID 6, драйвер CPUID и x32 ABI. По мнению Анвина, который является автором многочисленных макросов и ассемблерных вставок в ядре, с 1999 года языки С и С++ значительно продвинулись вперёд в своём развитии, а язык С++ стал лучше подходить для разработки ядра операционных систем, чем С.

Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.

Источник: OpenNET.

Вышел исследовательский проект Vcc (Vulkan Clang Compiler), нацеленный на создание компилятора, способного транслировать код на языке С++ в представление, выполняемое на GPU, поддерживающих графический API Vulkan. В отличие от моделей программирования GPU на базе языков шейдеров GLSL и HLSL в Vcc развивается идея полного отказа от использования отдельных языков шейдеров и предоставляется возможность прямой компиляции кода C/C++ для Vulkan. Наработки проекта Vcc распространяются под лицензией MIT.

Для компиляции кода в Vcc задействованы компоненты проекта LLVM и Clang в качестве фронтенда. Для выполнения на GPU развивается собственное промежуточное представление шейдеров Shady и компилятор для преобразования кода в это представление. По возможности поддерживается компиляция обычного стандартного кода C/C++, а для поддержки специфичных для GPU возможностей предоставляются дополнительные встроенные функции.

В Vcc применяются штатные возможности C/C++ для управления ходом выполнения программы, включая возможность использования оператора goto. Допускается вызов функций, рекурсивное выполнение функций, использование физических указателей, теггированных указателей и указателей на функции, выполнение арифметических операций над указателями, а также определение раскладки типов в памяти. Из ограничений реализации упоминается отсутствие поддержки исключений C++, недоступность функций malloc/free и непереносимость функций и указателей между хост-системой и GPU.

Источник: OpenNET.

Здравствуйте, достала навязчивая реклама. Наберёшь в поисковике "купить диван". Диван давно куплен, а тебе со всех щелей ещё долго лезет реклама разных мебельных магазинов. Вот я что придумал: Нужно сделать программу, которая с компа раздает запросы по случайному закону. Например " купить прокатный стан" через минуту " купить зубочистку" ещё через минуту " построить дом" потом " как стать космическим туристом" и тому подобное и пусть ихние алгоритмы сдохнут от перегрузок. Что Вы думаете по этому поводу?

Поскольку на Хабре нет механизма оповещения об обновлениях статьи, решил написать про это пост.

Если вам посчастливилось одними из первых увидеть мою последнюю статью Глубина кроличьей норы: бинарная граница и ABI C++, то возможно, вы захотите к ней вернуться, когда узнаете что я добавил в неё несколько важных уточнений, которые перечислены в секции UPD (среди минорных исправлений пунктуационных ошибок и т.п.):

15.10.23:

1. Добавил разьяснение про то, почему при переходе бинарной границы не стоит рассчитывать на copy elision. Ссылка на уточнение тут.

17.10.23:

1. Добавил новый пункт про POD-типы: 2.3. Суровая реальность.

2. Обновил заключение: В одном чёрном-чёрном доме ...

18.10.23:

1. Добавил в пункт 2.1. Не позволяйте исключениям переходить бинарную границу подробный анализ причин почему не стоит пропускать исключения через бинарную границу.

Благодарю вас за уделённое время!

Расскажите своё мнение: на чём актуально писать более-менее крупную софтину под windows?

Работаю в проекте, нужна программа контроля доступа сотрудникам. БД + GUI + работа с устройством (перезаписывалка RFID меток). Проект - студенчесский стартап, так что пишем сами, не используем интеграции с крупными решениями.

Встал вопрос на чём писать. У меня компетенций в равной степени хватает на QT + C++, .NET + C# или Electron + js. Поэтому сложно определиться, важна скорость разработки и количество гайдов. По скорости выигрывает electron, а по гайдам .net.

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

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

Заранее спасибо!

P.S. Надеюсь не вызвал постом ощущение что я не желаю думать свой бОшкой, просто есть внутренний крик души, подумал, почему бы не посоветоваться с умными хабрятами)

Вышла новая версия статического анализатора кода cppcheck 2.11, позволяющего выявлять различные классы ошибок в коде на языках Си и Си++, в том числе при использовании нестандартного синтаксиса, типичного для встраиваемых систем. Предоставляется коллекция плагинов, через которые обеспечена интеграция cppcheck с различными системами разработки, непрерывной интеграции и тестирования, а также предоставлены такие возможности как проверка соответствия кода стилю оформления кода. Для разбора кода может применяться как собственный парсер, так и внешний парсер от Clang. В состав также входит скрипт donate-cpu.py для предоставления локальных ресурсов для выполнения работы по совместной проверке кода пакетов Debian. Исходные тексты проекта распространяются под лицензией GPLv3.

Развитие cppcheck сосредоточено на выявлении проблем, связанных с неопределённым поведением и применением конструкций, опасных с точки зрения безопасности. Целью также является минимизация ложных срабатываний. Среди выявляемых проблем: указатели на несуществующие объекты, деления на ноль, целочисленные переполнения, некорректные операции битового сдвига, некорректные преобразования, проблемы при работе с памятью, некорректное использование STL, разыменование нулевых указателей, применение проверок после фактического обращения к буферу, выход за границы буферов, использование неинициализированных переменных.

Источник: OpenNET.