tgindex
C++ Moscow

Информационный канал московского сообщества программистов на C++ Чат: @cppmoscow_chat Бот обратной связи: @cppmoscow_bot Организатор: @eoanermine

Последний пост
11 авг. 2024 г.
Последнее чтение
14 авг.
Постов за неделю
0
Всего постов
20
Тип
открытый
Язык
русский
Категория
Технологии
В каталоге с
14 авг.
Подписчики
443
−1 за 3 дн.
Сутки
−1
−0,23%
Неделя
 
Месяц
 
Просмотров на пост
1 165
20 постов
Вовлечённость
263,0%
к подписчикам
Постов в день
0,0
всего 20
Упоминаний
1
каналов
Охват размещения
оценка
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 Наш митап начнется уже через несколько минут! Смотреть онлайн