C++ Moscow
СтатистикаИнформационный канал московского сообщества программистов на C++ Чат: @cppmoscow_chat Бот обратной связи: @cppmoscow_bot Организатор: @eoanermine
- Последний пост
- 11 авг. 2024 г.
- Последнее чтение
- 14 авг.
- Постов за неделю
- 0
- Всего постов
- 20
- Тип
- открытый
- Язык
- русский
- Категория
- Технологии
- В каталоге с
- 14 авг.
- 1/24сутки в ленте
- —
- 1/48двое суток
- —
- 1/72трое суток
- —
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
#article #original Реализуем эффективный тупль с помощью C++26 Свет видел много любительских реализаций std::tuple, и реализация своих велосипедов — наверное, это действительно действенный способ обучения: вряд-ли можно сказать, что ты что-то по-настоящему понимаешь, если не можешь объяснить, как это что-то устроено. Многие пытливые умы на протяжении десятилетий задавались вопросом: как же реализован std::tuple, как мне реализовать свой тупль (кортеж)? [1] И немало было дано ответов на такие вопросы и написано статей ([2]). Однако я берусь утверждать, что все они имеют один фатальный недостаток! Конкретнее, они все рассматривают в основном лишь один (и при этом неэффективный) способ реализации: с помощью множественного наследования или рекурсивного инстанцирования, имеющий в свой очередь множество своих недостатков, главный из которых — неэффективное использование памяти. В то время как современный C++ позволяет реализовать тупль гораздо проще (без обилия шаблоноты) и эффективнее. Подробнее на Хабре
Интересный пример, когда объявление friend T (где T — шаблонный параметр) имеет смысл: template <typename T> class Badge { friend T; Badge() { } }; Допустим, у нас есть какой-нибудь публичный метод, и предполагается, что круг его пользователей ограничен лишь одним классом, например: class VFS { ... public: void register_device(Device&); void unregister_device(Device&); }; Предполагается, что эти методы будут вызываться внутри конструкторов (и деструкторов соответственно) Device и нигде (и никем) больше. Но как закрепить наше ожидание на уровне API? Сейчас эти методы может вызывать каждый. Распространенное решение — вынести (un)register_device в приватную часть, а Device объявить дружественным: class VFS { ... private: friend class Device; void register_device(Device&); void unregister_device(Device&); }; И это действительно запрещает всем кроме Device обращаться к данным методам. Но это так же разрешает Device обращаться ко всем остальным приватным членам VFS! Кажется, будто мы позволяем ему слишком многое. Выразить же желаемое наиболее четко и ясно нам помогает как раз таки класс Badge, приведенный в самом начале статьи: мы можем оставить методы (un)register_device в публичной части, но при этом сделать их первым аргументом значение Badge<Device>: class VFS { ... public: void register_device(Badge<Device>, Device&); void unregister_device(Badge<Device>, Device&); }; Теперь чужак не может использовать эти методы, потому что он не может сконструировать Badge<Device> (его конструктор приватный и доступен только Device), а сам Device может вызывать их где и как пожелает: Device::Device() { VFS::instance().register_device({}, *this); }
#обсуждение Вечернее обсуждение. Пост от @eoanermine Кажется, будто C++ идёт не в том направлении: комитет втаскивает и втаскивает фичи, при этом не имея четкого видения: корутины затащим? Затащим! Senders/Receivers? А давайте тоже затащим, чего мелочиться, и про корутины можно будет забыть! Слишком мало рефлексии, слишком мало оптимизации существующего. И слишком много необдуманных новинок. Может, вместо того, чтобы добавлять, наконец следует остановиться и подумать? Десяток видов инициализаций, множество раз перегруженных ключевых слов (имеющих по 5 различных значений в различных контекстах), иногда потерявших свое первоначальное значение, но сохранивших имя — это не красит язык. Как вы думаете: разве это не путь в пропасть? Кажется, однажды плюсы просто схлопнутся под давлением легаси. А с учётом того, как много новых пропозалов стали принимать с каждым новым стандартом, кажется, это время уже близко. И что можно сделать?
#meetup Первый неформальный митап C++ Moscow пройдет 3 марта (Вс) с 15:00 до 17:00–18:00 в антикафе «12 Ярдов» (г. Москва, ул. Братьев Фонченко, д. 10, стр. 1, м. Парк Победы) в офлайн формате. Познакомимся, попьем чай-кофе с печеньками, обсудим последние…
20 марта: C++ митап в Петербурге и онлайне Нас ждет классический вечерний бесплатный митап с докладами, круглым столом и возможностью пообщаться с докладчиками, даже если вы смотрите трансляцию. - Константин Владимиров (Syntacore) расскажет про цену, которую разработчик платит за использование виртуальных функций, исключений, ranges и coroutines. И объяснит, что можно улучшить грамотным использованием компилятора. - Евгений Фёклин (PVS-Studio) покажет, почему линтеров мало, и объяснит, как работает статический анализ кода. - Илья Казаков (YADRO), Андрей Аксенов (Avitotech, по видео), Станислав Юрченко (VK) и Александр Еналдиев (Kaspersky) расскажут, как организовано код-ревью в их командах и как можно решать самые острые и частые проблемы, встающие при настройке этого процесса. Забирайте место в зале или получите ссылку на трансляцию — и увидимся вечером 20 марта!
Пока мы проводим митапы в Москве, наши коллеги из YADRO планируют митап в Санкт–Петербурге! Чем не повод прокатиться на денек-другой в Питер? 😉 Подробности — в посте ниже
#meetup Первый неформальный митап C++ Moscow пройдет 3 марта (Вс) с 15:00 до 17:00–18:00 в антикафе «12 Ярдов» (г. Москва, ул. Братьев Фонченко, д. 10, стр. 1, м. Парк Победы) в офлайн формате. Познакомимся, попьем чай-кофе с печеньками, обсудим последние стандарты, помечтаем о будущем C++ и просто поболтаем! Так как митап пройдет в антикафе, всем его участникам нужно будет заплатить за пребывание в нём. Стоимость пребывания в антикафе за весь митап: 500 рублей. Чай, кофе, сладости в неограниченных количествах и уютные диванчики включены :) Успейте зарегистрироваться на митап по ссылке! Количество место ограничено!
#article #original Какой тип ordering должен возвращать мой operator<=> в C++? Во всех подробностях об этих многочисленных _ordering, попавших в C++23: strong_ordering, weak_ordering, partial_ordering Подробнее на Хабре
#meetup С приближением весны приближаются и наши митапы! Но на этот раз мы думаем над экспериментом: неформальной встрече в антикафе, где мы могли бы попить чай, кофе; покушать печеньки и хорошо поболтать за плюсы :) Как вы относитесь к этой идее? И как думаете, как провести этот эксперимент наиболее удачно?
#cpp26 План по улучшению средств метапрограммирования в C++26 Читая принятый в C++26 пропозал «Pack Indexing» (P2662) (и даже уже реализованный в clang 19!), делающий возможным следующий код: template <typename ...T> constexpr auto first_plus_last(T... values) -> T...[0] { return T...[0](values...[0] + values...[sizeof...(values) - 1]); } int main() { static_assert(first_plus_last(1, 2, 10) == 11); ] Внезапно обнаружил существование пропозала с таким интригующим названием как «A plan for better template meta programming facilities in C++26» за авторством многих видных комитетчиков, ставящего цель протащить в стандарт вместе с уже принятым «Pack Indexing» такие пропозалы как 1. «Generalized pack declaration and usage» (P1858) namespace xstl { template <typename... Ts> struct tuple { Ts... elems; } } xstl::tuple tup{1, 2, 3}; 2. Reflection for C++26 (P2996) constexpr auto r = ^int typename[:r:] x = 42; // Same as: int x = 42; typename[:^char:] c = '*'; // Same as: char c = '*'; 3. Universal Template Parameters (P1985) template <template auto> struct takes_anything { }; int main() { takes_anything<int> a; takes_anything<1> b; } Планы Наполеновские, но смотря на то, как живо комитет начал голосовать за продвижение хоть какой-то рефлексии в C++26... Невольно думаешь, что все возможно. А какие из этих пропозалов вы бы хотели видеть в стандарте больше всего? Или, может, вы мечтаете о чем-то другом?
#article #original Многообразие функциональных обёрток. В далёком 2002-ом комитет по стандартизации C++ посетил пропозал, предлагавший ввести шаблонный класс, некий обобщенный «указатель на функцию», способный работать как с простыми указателями на функции, указателями на методы классов, так и с произвольными функциональными объектами [1]. В качестве мотивации к принятию он приводил несколько весомых юзкейсов: колбэки и функции высших порядков. Кто же знал, что его окажется недостаточно, а один из его юзкейсов — вовсе не его юзкейс? Читать далее на Хабре
#atomics На днях решил наконец-то твердо разобраться в Модели памяти C++ (до этого лишь всякие доклады по теме смотрел, но там как в мозг втекало, так через некоторое время и вытекало). В процессе задумался: а все эти happens before, synchronizes with и более сложные отношения между операциями — их ведь можно было бы визуализировать! Погуглил, а, оказывается, такой инструмент уже существует: CppMem. Но печаль: его не прогнать на плюсовом коде; и даже на произвольном сишном коде его не прогнать. Он умеет лишь в свой ограниченный синтаксис. И это понятно: CppMem был создан лишь для демонстрации папиры Mathematizing C++ Concurrency. Пилить полноценный такой инструмент — раньше, чем допилишь, наверное, сам выпилишься. А знаете ли вы какие-либо другие инструменты для статического анализа корректности атомарных операций? Как думаете, будет ли когда-либо написан полноценный инструмент для этого, или нам в этом плане до конца веков остается полагаться лишь на нейронку в своей голове?
Наш организаторский комитет и редакторский совет ежеденно и еженощно планирует митапы и пишет новые посты. Но ядро C++ Moscow — это вы, наши читатели и завсегдатаи наших митапов! И мы приглашаем вас стать активным членом сообщества! 1. Присылайте нам идеи для постов или сами ваши оригинальные материалы — мы их зарепостим и сохраним ваше авторство. И если у вас есть любые иные идеи и предложения — не стесняйтесь, так же пишите нам! Будущее C++ Moscow в ваших руках!
#wg21 Их не часто видно или слышно, но они существуют! Национальная рабочая группа по стандартизации С++, РГ21 C++ Россия! Давно мечтали внести свой вклад в развитие плюсов? Изложите и обсудите свою идею с экспертами! А если вы считаете, что уже готовы написать свой пропозал — флаг вам в руки, прочтите инструкцию и начните писать; будут вопросы — члены РГ21 с радостью вам помогут. Будущее C++ в наших руках!
#practice Литкод это, конечно, хорошо.. Но одни алгоритмические задачи очень быстро наскучивают, да и много ли литкодных задач плюсовый программист решает обычно на работе? Для всех новичков и не только, ищущих идей для практики: 1. Coding Challenges, сборник 38 идей для разработки: от таких простых утилит как cat и wc до git-клиентов, брокеров соощений и интерпретаторов. Пригодных к написанию на любом языке. Сложностью не более чем на 8 часов работы. 2. Проектно-ориентированное обучение. Список пошаговых туториалов: реализация аллокаторов, файловых систем, текстовых редакторов, баз данных с нуля. 3. Programming Challenges. Знаменитый список родом с 4chan.org: 145 идей, ранжированных по уровню сложности и разбитых на категории: прикладные программы, алгоритмы, ИИ, интерпретаторы (компиляторы), эмуляторы, игры. Нечего делать по вечерам? 200+ идей доступны выше по ссылкам :)
Наш редакторский состав несколько недель боролся с хворью, но в конечном итоге победил и возвращается, чтобы радовать вас плюсовыми постами. На последнем плюсовом митапе был поднят очень интересный вопрос: почему следующий код компилируется и gcc и clang и успешно выполняется, когда, казалось бы, согласно [module.global.frag], совсем не должен (см. объяснение Константина Владимирова)? // global.hpp #include <iostream> template <typename T> void dump(T val) { std::cout << val << std::endl; } // global.cppm module; #include "global.hpp" export module global; export template <typename T> void output(T item) { dump(item); } // main.cpp import global; int main() { output(42); } Мы честно пытались это нагуглить, но у нас не получилось. Каким образом в данном примере происходит инстанцирование? clang и gcc сохраняют в pcm дополнительные данные, необходимые для него? Если вы знаете секрет этих колдунств — мы с радостью ждем вас в комментариях. Если не знаете — ждём вас не менее. Разберёмся в компиляторной магии вместе!
#proposals #wg21 Trip report: Autumn ISO C++ standards meeting (Kona, HI, USA) Чуть больше, чем неделю назад, появились первые трип-репорты с недавней встречи WG21 (Комитет по стандартизации C++) в Коне По ее итогам в C++26 вошли: 1. Возможность обращения к parameter pack'ам как к массивам (P2662R3) template <typename... T> constexpr auto first_plus_last(T... values) -> T...[0] { return T...[0](values...[0] + values...[sizeof...(values)-1]); } int main() { static_assert( first_plus_last(1, 2, 10) == 11 ); } 2. Огромное количество функций линейной алгебры в стиле фортрановского BLAS, <linalg> (P1673R13) template<in-matrix InMat, class Triangle, in-vector InVec, out-vector OutVec> void cholesky_solve(InMat A, Triangle t, InVec b, OutVec x) { using std::linalg::explicit_diagonal, std::linalg::transposed, std::linalg::triangular_matrix_vector_solve; if constexpr (std::is_same_v<Triangle, upper_triangle_t>) { // Solve Ax=b where A = U^T U. Solve U^T c = b, using x to store c. triangular_matrix_vector_solve(transposed(A), opposite_triangle(t), explicit_diagonal, b, x); // Solve U x = c, overwriting x with result. triangular_matrix_vector_solve(A, t, explicit_diagonal, x); } else { // ... } } 3. Более удобный и безопасный способ форматирования рантаймовых строк (P2905R2, P2918R2) // Before: std::vformat(str, std::make_format_args(42)); // After: std::format(std::runtime_format(str), 42); 4. Возможность создания в рантайме точек останова для отладки, <debugging> (P2546R5) // Здесь мы хотим переключиться в отладчик std::breakpoint_if_debugging(); // А здесь мы из него возвращаемся И многое, более мелкое, другое. Как вы думаете, комитет тратит свои силы на стоящие вещи? И что бы хотели видеть вы в C++26?
#meetup Доклады на какие темы вам было бы интересно послушать в следующий раз? Как можно было бы сделать доклады с предыдущей встречи лучше? Помогите нам стать лучше и сформировать интересную программу для следующей встречи, поделитесь своим мнением через Яндекс.Формы!
#meetup #videos #slides Записи докладов с прошедшей встречи теперь доступны на нашем канале! 1. Корутины и Qt. Библиотека QCoro — Илья Быконя — C++ Moscow №2 2. ООП в Clickhouse — Дмитрий Косенко — C++ Moscow №2 Кроме того, был размещен в публичный доступ репозиторий с кодом к вопросам, которые были на прошедшей викторине. А для быстрой навигации по всем материалам, связанным с прошедшим мероприятием, был создан отдельный репозиторий.
#meetup Наш митап начнется уже через несколько минут! Смотреть онлайн