Автор Nuxt.JS вперше в Україні на конференції JavaScript fwdays | 14 березня, Київ
×Закрыть

C++ дайджест #23: оптимізація компіляції та підсумки року

Привіт, мої любі сішники! Вітаю вас з Новим роком та Різдвом! Нехай у цьому році код стає якіснішим, компіляція швидшою, а проекти цікавішими! ;)

Новорічний випуск пропоную присвятити підсумкам року та оптимізації компіляції. То ж почнімо? :)

Підсумки 2019

C++ at the end of 2019 — детальний підсумок в подіях та фактах.

На Meeting C++ запущено опитування, за яким маємо такі цікаві результати (результати актуальні на 10 січня та можуть змінюватися в зв’язку з тим, що опитування ще триває).

Найчастіше зі стандартів використовуються:


Бібліотеки:


Середовище:

Оптимізація часу компіляції

Досить тривалий час компіляція є одним із суттєвих недоліків С++. Хоча тривала компіляція забезпечує нам можливість заварювати каву та переглядати останні новини/дайджести без поспіху, вона може стати суттєвим головним болем перед дедлайном. Тож розглянемо, як оптимізувати.

Герб Саттер для вирішення цієї проблеми пропонує перевірити хедери та використовувати Pimpl, як і хлопці в цьому блозі:

Онлайн книга С++ best practices пропонує більш розширений список рекомендацій.

З цієї теми корисно буде почитати:

Відео з CppCon:

Modern C++

C++20: Concepts — What we don’t get

C++20: Concepts, the Placeholder Syntax

C++ coroutines: Getting started with awaitable objects

A beginner’s guide to C++ Ranges and Views

Корисні посилання

Substitution Failure is Error and Not An Error

Named Template Arguments

What Is MISRA and how to Cook It

Modern C++ type CoDec Challenge

Dry-comparisons: A C++ Library to Shorten Redundant If Statements

Accidentally Overwriting Another Local Variable in C and C++

A Compiler Writing Journey

The Eight Rules of Multithreaded Qt

Open sourcing Google Cardboard

Waiting for std::embed: Very Large Arrays in Clang

C++ UI Libraries

Інструменти

Top 10 Bugs Found in C++ Projects in 2019 PVS studio

CMake 3.16 added support for precompiled headers & unity builds

The Qt Marketplace has landed

A Gentle Intro to Developing C++ Apps for AWS and S3

CLion: Our Plan for Next Year and the 2020.1 Roadmap

Build C++ Applications in a Linux Docker Container with Visual Studio

Оновлення

Цього місяця маємо такі оновлення:

Хвилиночка флуду




← Попередній випуск: C++ дайджест #22

LinkedIn

19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо, много интересных ссылок.
Графики тоже порадовали. Теперь ещё больше кекаю с ДОУ-синьоров, которые утверждают, что ни нужОны никому эти новые стандарты.

Ты лучше посмотри на график юзания фич из стандартов. Он хорошо показывает, что там получилось, а что совсем не получилось.
Основная дурь этих стандартов С++ сейчас, что туда пихают всё, нужное и не нужное в STL.
А многое, как бы и нужное, но в безумно кривом варианте, а потом через несколько стандартов объявляют deprecated.
А вот с важным — UB и не собираются разбираться и чинить.

UB нельзя починить, не став Джавой без указателей. Это — цена скорости и ручной оптимизации.

А там не только с указателями UB, а даже на простом сложении.

Но есть и более тривиальная вешь, которой ни в С ни в С++ так и не появилось. Где в С и С++ операции по модулю? Если нужны, то или извращайся или юзай асм.
Но зато кривую хрень std::thread добавили и еще более кривую std::future и std::async — и еще чего в голову пришло и в стиле ***к-хуяк и в продакшен. Не настолько убого уже, как auto_ptr когда-то, но через жопу всё одно.

Ну вот нечего натягивать сову на глобус. Архитектуры разные бывают, и не зря они такие. Наверняка еще есть какой-то DSP на котором это UB не такое как на x86.

Сложения не UB на x86. UB они стали в C и C++.

Но не везде х86. Поэтому чтобы язык мог везде, надо все различия между платформами записать в UB.

Вероятно, DSP. Там в char 16 битов и прочие приколы, вроде постраничного обращения к памяти.

И где там UB на сложениях. Там нюансы с адресацией памяти, они и на x86 были и есть?
И вот в этой части UB я не помню в C или C++. Ошибся с адресацией — получишь исключение от проца однозначное.

Какое исключение? Ты можешь ошибиться на 16 байт и записать в соседнюю переменную или на килобайт — в системную область.

И где там UB на сложениях?
Ты можешь ошибиться на 16 байт и записать в соседнюю переменную или на килобайт — в системную область.

Так ты сам это сделал, сам ошибся, а не призрак оперы.

Про сложение пишут, что там UB чтобы компилер мог раскрывать цикл или еще что-то злое делать (может, когда тип данных шире регистра) и не гарантировать правильность результатов при переполнении.

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

Тем не менее, обычно она едет — те, кто не доехал, на форуме уже не сидят.

Он хорошо показывает, что там получилось, а что совсем не получилось.

Не показывает. Нельзя оценивать «получившиеся» фичи по количеству использований. std::uncaught_exceptions, например, штука полезная. Но нужна крайне редко, вот и на графиках на дне. А if constexpr реально не получился (всеми обожаемый Александреску объяснял, почему) — но его всё равно будут использовать где возможно, потому что даже в таком виде он очень сильно облегчает разработку и поддержку шаблонного кода.

Основная дурь этих стандартов С++ сейчас, что туда пихают всё, нужное и не нужное в STL.

Тебе не нужное — не используй. А кому-то другому оно нужное.
Почему это должно быть проблемой? Сравни со стандартной библиотекой джавы или дотнета — стандартная библиотека плюсов на их фоне всё равно крошечная.

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

Да, это проблема. Обусловленная в первую очередь тем, что плюсы развиваются главным образом энтузиастами в свободное от основной работы время. Щито поделать.

А вот с важным — UB и не собираются разбираться и чинить.

Категорически не согласен, что его нужно «чинить». Оно нужно в языке по причинам. Убрать UB — значит отказаться от множества полезных оптимизаций.
Вот что нужно чинить, так это тулы, которые работают с плюсами (всякие статические анализаторы и т.д.): их нужно развивать, чтобы они лучше отлавливали UB в компайл/линк тайме и выдавали ворнинги разработчикам.

Не показывает. Нельзя оценивать «получившиеся» фичи по количеству использований.

Почему нельзя? Это график как раз и показывает потребность в фичах от пользователей продукта.

Потому что одни фичи нужны чаще, другие реже. Это не говорит о том, кто из них лучше получился.

Спасибо за Ваш комментарий. Согласна — графики порадовали :)

Подписаться на комментарии