Компиляторы тоже путаются в именах

Это продолжение темы начатой в статье Важны ли компилятору имена , и продолженой в Ночью все кошки серы, а using'и одинаковы , и если вам нужна полная картина, как компилятор превращает текст в программу, то без понимания поиска имён (name lookup) дальше двигаться уже не получится. Имена в тексте исходника это просто удобные ярлыки для людей: переменные, функции, типы. Но для компилятора имя являеются точкой входа в довольно сложный алгоритм, который должен однозначно определить, что именно вы имели в виду . И вот здесь начинается самое интересное: одинаково написанное имя в разных контекстах может означать совершенно разные вещи, а иногда даже не означать ничего вовсе, в зависимости от того, где и как оно используется. C++ в этом месте особенно коварен. Язык рос десятилетиями, и правила поиска имён эволюционировали вместе с ним: добавлялись пространства имён, шаблоны, ADL, двухфазный поиск. Всё это не просто усложнило модель, оно сделало её местами неинтуитивной даже для опытных разработчиков, добавим сюда еще, что разные компиляторы исторически реализовывали эти правила (по-своему) по-разному, и часть этих различий до сих пор всплывает в коде. Не нужно воспринимать компилятор как чёрный ящик, хотя порою поиск имён действительно выглядит как магия, но если разобрать его на отдельные шаги, то становится видно, что за этой «магией» стоит вполне строгая (хоть и исторически нагруженная) система правил. Попробую о ней рассказать. Какой-то странный, этот ваш с++

https://habr.com/ru/articles/1023334/

#с++ #с++_программирование #ненормальное_программирование #разработка_игр #компиляторы

Программа смены фона рабочего стола

Программа смены фона рабочего стола. При запуске, программа циклически меняет фон рабочего стола: Файл ->Solid Color->Файл ->Solid Color->…

https://habr.com/ru/articles/1022508/

#с++ #desktop #wallpaper

Ахиллесова пята C++ и будущая р̶е̶ эволюция

Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен . Но чтобы оставаться честным перед читателями, решил опубликовать и статью-контраргумент с описанием обратной стороны медали, то есть почему C++ всё равно будет рано или поздно заменён, а заодно попробовать разобрать, каким будет новый язык программирования, который неминуемо придёт на смену C++.

https://habr.com/ru/articles/1021684/

#программирование #с++ #развитие_языков_программирования #эволюция_языка

С++26 — готов! Итоги встречи ISO C++ в Кройдоне

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. На днях в Кройдоне состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз (как и в прошлый), всё внимание было сосредоточено на C++26 и… теперь он готов! Осталось пройти формальные этапы в вышестоящих инстанциях ISO, и мы получим C++26 который заслужили. В нём будут: – reflection, – контракты, – SIMD, – линейная алгебра, – расширенные возможности сonstexpr, – hardening, – Hazard Pointer и RCU, – #embed, – executors, – и многие другие полезные вещи. Подробности и новинки

https://habr.com/ru/companies/yandex/articles/1015474/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1015474

#contracts #reflection #c++26 #с++26 #с++ #программирование #simd #compiletime #compile_time #hardening

С++26 — готов! Итоги встречи ISO C++ в Кройдоне

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. На днях в Кройдоне состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз (как и в прошлый), всё внимание было сосредоточено на C++26 и… теперь он готов! Осталось пройти формальные этапы в вышестоящих инстанциях ISO, и мы получим C++26 который заслужили. В нём будут: – reflection, – контракты, – SIMD, – линейная алгебра, – расширенные возможности сonstexpr, – hardening, – Hazard Pointer и RCU, – #embed, – executors, – и многие другие полезные вещи. Подробности и новинки

https://habr.com/ru/companies/yandex/articles/1015474/

#contracts #reflection #c++26 #с++26 #с++ #программирование #simd #compiletime #compile_time #hardening

Асинхронное логирование в C++ — не серебряная пуля: что на самом деле ограничивает производительность

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее. Но если копнуть глубже, оказывается, что это не совсем так. В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры: 👉 https://habr.com/ru/articles/1012874/ Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым. В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе , и что на самом деле происходит внутри:

https://habr.com/ru/articles/1017842/

#с++ #логирование #асинхронное_программирование #производительность #многопоточность

GDB для тех, кто думает, что отладка — это фантастика

cout - плохой отладчик! Как за 30 секунд найти место падения программы? Какие 7 команд GDB нужно знать каждому C++ разработчику? В этой статье я делюсь личным опытом: как я боялся GDB, думал, что это «магия для гуру», а потом понял, что 70% задач решается простыми командами. Спойлер: главный страх - это неизвестность. А когда знаешь backtrace , break , next , print и info locals , GDB становится лучшим другом. Статья рассчитана на начинающих C++ разработчиков, которые хотят перестать бояться терминала и начать отлаживать системно.

https://habr.com/ru/articles/1016430/

#gdb #с++ #отладка

Ночью все кошки серы, а using'и одинаковы

Одной из самых сложных частей C++ до сих пор считаются правила поиска имён, и ошибки связанные с name lookup проявляются обычно уже в рантайме. Код компилится и даже работает какое-то время, но при свете луны ведёт себя не так как ожидает программист. За простыми идентификаторами скрывается многоуровневая система областей видимости, категорий имён и специальных правил, и очень многое в нашем текущем стандарте растёт прямиком из восьмидесятых, частенько без изменений. Давайте посмотрим как компилятор видит имена в C++, какие области видимости существуют и почему они ведут себя по-разному. В C++ есть несколько типов областей видимости, вы наверное сходу назовёте глобальное пространство имён, область параметров шаблона, область видимости класса и область параметров функции, но также есть блочная область видимости и область видимости перечислений. Между этими областями есть исторически сложившаяся асимметрия, которая частенько удивляет: два объявления using, которые вводят одно и то же имя в одну и ту же область видимости внутри пространства имён компилятор съест без возражений, но если попытаться сделать то же самое других областях видимости, то получим ошибку на повторное объявление. В серии статей про "нескучное программирование" я разбираю скользкие случаи и как мы докатились до такого. Это продолжение темы, начатой в "Важны ли компилятору имена" , поэтому чтобы картинка была цельной, лучше пробежать её по диагонали.

https://habr.com/ru/articles/1015492/

#с++ #программирование #игры #разработка_игр #ненормальное_программирование

Нескучное программирование. Обобщения (ч.2)

Это не отдельная статья, а продолжение статьи про теорию объектов в с++ , почему объекты в плюсах такие какие есть. Все завершенные главы я также выкладываю на github'e в английском и русском варианте . Продолжаем разбираться в теории С++... Отдельного разговора заслуживает идентичность объектов, потому что в реальном мире конкретные сущности обладают идентичностью и Сократ останется Сократом независимо от того, перекрасил ли он волосы, сменил адрес или умер, а государство остаётся тем же государством, даже если меняет флаг, конституцию или размер населения. Чтобы отразить это в программе, объекты, представляющие конкретные сущности, нуждаются в своём определении идентичности, которая отделена от текущего состояния. Удобный способ ввести такую идентичность будет сделать некий токен идентичности, уникальное значение, которое выражает "кто это", а не "в каком он сейчас состоянии". Таким токеном может быть, например, адрес объекта в памяти, индекс в массиве, или табельный номер сотрудника в кадровой системе и проверяя равенство токенов идентичности, мы фактически проверяем тождественность объектов: один и тот же объект или разные. На протяжении жизни программы конкретный объект может менять свои токены идентичности, потому что его могут переместить в другой участок памяти или переложить из одного контейнера в другой, или назначить ему новый идентификатор, но логическая идентичность сохраняется, если мы поддерживаем сопоставление между "старым" и "новым" токеном.

https://habr.com/ru/articles/1011012/

#с++ #программирование #разработка_игр #алгоритмы #комплияторы

[Перевод] Как мы подружили однопоточный C++ с многопоточным Rust

Этот пост написан по мотивам выступления, с которым мы с Шисянь Ван ездили на конференцию Rust UnConf , организованную нью-йоркским сообществом Rust . Конференция UnConf собрала поистине потрясающий коллектив энтузиастов a Rust, в компании которых мы более двух часов посвятили глубоким техническим дискуссиям (а также поеданию мороженого). Далее при необходимости я буду ссылаться на опыт нашей компании Antithesis.

https://habr.com/ru/articles/1010062/

#rust #с++ #компиляторы #программирование #фаззингтестирование #оптимизация #исследование