C++ Moscow

#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 различных значений в различных контекстах), иногда потерявших свое первоначальное значение, но сохранивших имя — это не красит язык.
Как вы думаете: разве это не путь в пропасть? Кажется, однажды плюсы просто схлопнутся под давлением легаси. А с учётом того, как много новых пропозалов стали принимать с каждым новым стандартом, кажется, это время уже близко. И что можно сделать?

Спасибо всем зарегистрировавшимся, и до скорой встречи! Нам хотелось бы собрать как можно больше людей, но, чтобы всем было комфортно в условиях ограниченной площади нашей комнаты в антикафе, мы вынуждены закрыть регистрацию. Если вы не смогли попасть на митап, не расстраивайтесь — мы обязательно вернемся с новыми мероприятиями! Будем оставаться на связи!

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

Наш митап начнется уже через несколько минут!

Смотреть онлайн