Герб Саттер — отчёт о встрече по стандартам ISO C++ в июне 2025 года

не соответствует.

Давайте я вам вашу же постановку задачи еще раз процитирую, а то вы что-то запамятовали:

Задача: У Вас есть внешняя либа(не ваших рук дело) в которой есть не ваш класс A c функцией g, которую вам надо вызывать.

И тут вы такой:

в таком случае ни наследование, ни встраивание не нужно

А где в вашей задаче, позвольте спросить, про наследование? И хоть мы и говорим про наследование, то каким боком наследование к простому вызову g?

вопрос - будут ли в коде отличаться варианты вызова функции g(), при наследовании A, и при встраивании как поля A _a

В каком таком коде?

Я вот вам выше привел два варианта call_g, где g вызывается, – и с шаблоном, и без (на чистом ООП). В этих вариантах отличается и, я бы сказал, драматически.

Причем в обоих вариантах отношение is-a сохраняется. Что, собственно, и требуется.

Про какой код говорите вы мне не ведомо.

еще раз. шаблоны тут не причем. когда говорят о множ наследовании(как принципе) никто не говорит о «шаблонах».

Отучаемся говорить про всех (c)

не парьтесь с «виртуальными методами» и шаблонами, пока не решили проблемку с обычными и без шаблонов.

Так вы бы обозначили проблемку то хоть.

А то от вас ни кода, ни объяснений, ни подтверждений тех слов, что вы мне приписывали. Малолетний дебилизм есть, конкретики нет.

Так вы бы обозначили проблемку то хоть.

обозначаю проблемку - показать разницу между множественным наследованием класса и его встраиванием. там кто-то говорил, что если множественное -смещаются указатели и вообщем караул. Вроде уже обозначал и не раз.

Опять же - требуется вызвать ОДНУ И ТУ ЖЕ функцию класса A, а не разные функции с одним именем из разных классов.

Шаблоны не тащить, «наследование и встраивание» к шаблонам не относится, это относится к классам. И потому шаблоны никак не могут быть использованы в данном вопросе(не привнося в него ничего нового).

меняется имя поля

Само меняется, спонтанно?

котом. кот прошел по клавиатуре и сменил имя поля. или погромистом, что взял, и имя поля сменил. он неделю как работал, и сменил, а потом все упало. но не сразу. а когда самолет взлетел. вот он взлетел и упал.

обозначаю проблемку - показать разницу между множественным наследованием класса и его встраиванием

Вот здесь: Герб Саттер -- отчёт о встрече по стандартам ISO C++ в июне 2025 года (комментарий)

и пояснение текстом, и два работающих примера на godbolt, в которых видно изменение значения this.

Это факты.

Если вы хотите поспорить с реальностью и опровергнуть эти факты, то приведите свой пример, доказывающий обратное.

В общем, пруфы, где пруфы?

Шаблоны не тащить, «наследование и встраивание» к шаблонам не относится, это относится к классам

Отношение is-a вполне себе относится и к шаблонам, а принцип подстановки Лисков вовсе не требует, чтобы подтип выражался именно через наследование.

Вот здесь: Герб Саттер – отчёт о встрече по стандартам ISO C++ в июне 2025 года (комментарий)

и пояснение текстом, и два работающих примера на godbolt, в которых видно изменение значения this.

Вам сто пицот раз говорили - проверить свои выводы не на бессмысленных рассуждалках с привлечением темлейтов и вирт функций, а ВОТ НА ЭТОМ КОДЕ.

struct A {
  int _a;
};

struct B {
  int _b;
  void fun() {} /// ЖЫРНО ТАК - ВОТ ЭТУ ФУНКЦИЮ НАДО ВЫЗВАТЬ и смотреть сдвиг this!!!
};

///множ наследование
struct C0: public A, public B {
  void test() { fun(); }
};

///просто встраивание
struct C1: public A {
  B _b;
  void test() { _b. fun(); }
};

Тут код упрощен до предела и функция, которую вызывать - только одна, чтобы вы опять не пошли по граблям.

А у вас - то вы вызываете разные функции с одним именем!!!, то пишете какие-то темплейты вызовов не пойми чего, то виртуальные функции(это опять физически разные функции!!!).

Зачем вам шаблоны, вы сначала разберитесь в тривиальном коде.

«Горшочек, не вари!» уже говорили?

А теперь вопрос: и зачем в вашем примере C0 наследуется от B?

В чем смысл?

Наследование – это способ выражения отношения is-a. Следовательно, если вы C0 наследуете от B, значит C0 у вас может выступать в качестве B.

Но C1 не может выступать в качестве B.

Следовательно для C1 отношение is-a не выполняется. А значит C1 здесь «не пришей кобыле хвост», в нем нет смысла.

Посему ваш пример ни о чем. Чего и следовало от вас ожидать.

А для чего еще оно надо, кроме сериализации, каких-то отладочных рефлексий?

Это уже само по себе важно. Тебе реально нравится руками описывать сотни полей структур через убогие макросы, или писать скрипты для генерации?

Куда? Он только-только начал варить что то вкусное.

А теперь вопрос: и зачем в вашем примере C0 наследуется от B? В чем смысл?

в чем смысл множ. наследования? чисто формальное расширение одинарного наследования. Если можно наследоваться один раз, то почему нельзя два и больше? Если нельзя больше одного, то должно быть некое фундаментальное утверждение на этот счет в виде аксиомы - почему нельзя. А его нет. Потому и множественное.

Следовательно, если вы C0 наследуете от B, значит C0 у вас может выступать в качестве B.

а когда вы там рассуждали о вреде множ. наслеждования вы говорили о сдвиге this. а не о том, кто и кем выступает.

Вы утверждали что множ. наследование двигает this. На что я вам сказал, что все прочие способы получения доступа к такой вот функции fun() - тоже его двигают, и потому являются эквивалентами. После чего я спросил - если они эквиваленьы - то почему вы так множ. наследования боитесь…

после чего начался ваш субмур с вызовом разных функций. :)))

Следовательно для C1 отношение is-a не выполняется. А значит C1 здесь «не пришей кобыле хвост», в нем нет смысла.

то есть теперь вы стали доказывать что множ наследование «плохо»… потому что там отношение - является??? и что. ну «является» экземпляр некоего класса A и экземпляром класса X и экземпляром класcа Y. У вас есть запрещающая это аксиома? (читайте пост сначала, откуда все пошло).

Тебе реально нравится руками описывать сотни полей структур через убогие макросы, или писать скрипты для генерации?

тебе надо просто сераилизовать или сделать это в некоем фиксированном формате, поскольку потом это все придется грузить назад, и может даже лет через несколько?

вот если так - то интроспекция тут лучший способ все похоронить. Потому что формат данных для внешнего хранения - это один такой документ с подписью и круглой печатью. А поля в классах и их имена - это другой документ, навроде стайлгайда. Вот осилятор шаблонов вообще пишет m_foo. Он так и будет в долговременное хранение запуливать свои m_foo??? А Найдутся и те, кто и венгерскую нотацию так запулят, дурное дело нехитрое.

в чем смысл множ. наследования?

Это не ответ на мой вопрос.

Есть наследование. Наследование нужно для выражения отношения is-a, т.е. когда наследник может использоваться там, где ждут родительский тип.

Соответственно, множественное наследование может позволить наследнику использовать сразу в нескольких местах, где ждут разные родительские типы.

Это прописные истины, которые не нужно повторять. Вопрос был в другом: зачем вы C0 отнаследовали от B? Для того, чтобы C0 мог заменять B? Или что?

а когда вы там рассуждали о вреде множ. наслеждования вы говорили о сдвиге this. а не о том, кто и кем выступает.

Потому что если наследник не выступает вместо родителя, то нет надобности и в самом наследовании(сноска1). Следовательно, если нет надобности в отношении is-a, то нет и наследования.

Вы утверждали что множ. наследование двигает this.

Более того, я показал это на примерах.

На что я вам сказал, что все прочие способы получения доступа к такой вот функции fun() - тоже его двигают, и потому являются эквивалентами.

Ну вот здесь и начинается херня с вашей стороны, потому что просто «получение доступа к такой вот функции fun()» нахер не упало, если у нас нет наследования для выражения отношения is-a. Это самое «получение доступа» вообще не имеет отношения к разговору о наследовании.

сноска1: не рассматриваем сейчас наследование+шаблоны в случаях, когда это используется для наполнения класса разным содержимым в зависимости от параметров шаблона.

И без интроспекции можно экспортировать поля m_lpsznimFoo, твои рассуждения тут лишние.

Есть наследование. Наследование нужно для выражения отношения is-a, т.е. когда наследник может использоваться там, где ждут родительский тип.

Когда наш колумб поехал открывать америку, в аэропорту его встретили негры полицейские и попросили паспорт. Вs делаете неожиданные открытия, прям как первопроходец :)

Соответственно, множественное наследование может позволить наследнику использовать сразу в нескольких местах, где ждут разные родительские типы.

Что вам не нравится во множественном наследовании? Вы ж начали с этого. У вас есть чем его запретить, закрыть, дать альтернативу?

Это прописные истины, которые не нужно повторять. Это вы должны повторять себе. :)

Ну вот здесь и начинается херня с вашей стороны, потому что просто «получение доступа к такой вот функции fun()» нахер не упало,

То есть за всю свою богатую практику вы не вызывали функции внешнего класса??? вы тридцать лет в с++ и каждый день как первый.:)))

И без интроспекции можно экспортировать поля m_lpsznimFoo, твои рассуждения тут лишние.

а как с этой вашей «рефлексией» (ну или интроспекцией) запросто экспортировать поле m_lpsznimFoo с тегом my_great_data_field? вводить еще алиасы что-ли? я не знаю что они там удумали.

Что вам не нравится во множественном наследовании?

На вопрос ответьте. Зачем вы наследовали C0 от B?

Вы ж начали с этого.

Для дебилов мне не сложно повторить в N-ый раз: " Вот есть множественное наследование в C++. Практически никогда не надо. Но когда надо, то хорошо, что оно есть." И еще раз прошу указать где вы в моих словах нашли «не нравится».

Хоть сейчас вы в пруфы сможете?

а как с этой вашей «рефлексией» (ну или интроспекцией) запросто экспортировать поле m_lpsznimFoo с тегом my_great_data_field? вводить еще алиасы что-ли? я не знаю что они там удумали.

Блин, дебилушка, по ссылкам бы сходили: https://brevzin.github.io/c++/2024/09/30/annotations/

Пример оттуда для совсем уже не желающих ничему учиться:

struct [[=derive<serde::Serialize>]] Person {
    [[=serde::rename("first name")]]
    std::string first;

    [[=serde::rename("middle name")]]
    [[=serde::skip_serializing_if(&std::string::empty)]]
    std::string middle = "";

    [[=serde::rename("last name")]]
    std::string last;
};

И да, все это разруливается еще в compile-time.

На вопрос ответьте. Зачем вы наследовали C0 от B?

это конечно понять сложно… отвечаю - чтобы в обсуждении множественного наследования получить это самое множественное наследование! у вас есть какой-то другой способ получить множественное наследование??? тогда срочно пишите в спортлото. Вот у меня другого способа нет. Потому в спортлото я не пишу.

И да, все это разруливается еще в compile-time.

по поводу рефлексий я буду говорить с морковкиным. у него мозги работают, а вас клинит на эксперименте c выяснением сдвига this.:)

отвечаю - чтобы в обсуждении множественного наследования получить это самое множественное наследование!

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

Т.е. множественное наследование не как «вещь в себе», а как инструмент для достижения конкретной цели.

Правильно ли я понимаю, что в ваших примерах нет никакой другой цели кроме как «множественное наследование» именно как «множественное наследование» безотносительно того, зачем при программировании оно вообще нужно?

serde

какое отношение имеет эта либа из раста к пропозалам в с++? вернитесь с дерева на землю! мы обсуждаем рефлексию(интроспекцию) в С++! что вы спамите своими линками, лишь опосредованно относящимися к вопросу.

в пропозалах алиасы полей есть?

Правильно ли я понимаю, что в ваших примерах нет никакой другой цели кроме как «множественное наследование» именно как «множественное наследование» безотносительно того, зачем при программировании оно вообще нужно?

правильно ли я понимаю, что вы тут(запутавшить в том, что вызывать) написали множественное наследование с непонятными для себя целями? вы не осознавали себя, и были как тумане, если задаете мне такой вопрос?

class A {
  void g() { /* здесь у this не такое же значение, как в B::f() */ }
  ...
};

class B : public C, public A {
...
  void f() { /* здесь у this не такое же значение, как и в g() */ }
};

Герб Саттер -- отчёт о встрече по стандартам ISO C++ в июне 2025 года (комментарий)

правильно ли я понимаю

Нет.

что вы тут(запутавшить в том, что вызывать)

Это не я запутался, это вы не поняли.

написали множественное наследование с непонятными для себя целями?

Цель понятна: B может выступать в качестве подтипа A. И уже приводился пример, как это может выглядеть. Но чтобы его понять, нужно хоть немного разбираться в C++ных шаблонах.

какое отношение имеет эта либа из раста к пропозалам в с++?

lavrov.jpg

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

оскорбят и прилюдно унизят? Это школа жизни такая? Чтобы вечером орать от обиды на свою жену и детей?

у кого что болит…

Но чтобы его понять, нужно хоть немного разбираться в C++ных шаблонах.

уважаемый. множественное наследование отношения шаблонам(тепллейтам классов) не имеет. В языке, где ваших шаблонов нет в принципе, запросто может быть множ. наследование.

Также в языке могут быть темплейты, но не быть множ. наследования.

Мухи и котлеты - это разное, уважаемый.

множественное наследование отношения шаблонам(тепллейтам классов) не имеет.

Множественное наследование – это инструмент для выражения отношения is-a для случая «один наследник у нескольких родителей».

Но отношение is-a не имеет ценности если мы не можем «потреблять» экземпляры производных классов там, где ожидаются экземпляры родительских.

Шаблоны (в обсуждаемом примере шаблон функции) являются одним из способом такого «потребления». В частности, шаблон функции call_g ожидает A или его подтип. Подтип в C++ может быть выражен, как наследованием, как и «утиной типизацией». Что и показано в моем примере здесь.

В языке, где ваших шаблонов нет в принципе, запросто может быть множ. наследование. Также в языке могут быть темплейты, но не быть множ. наследования.

Мы сейчас про C++, поэтому нефиг уводить разговор в сторону.

Я вам вопросы задавал выше. Вы реально дебил, не способный на них ответить, или притворяетесь?

Мухи и котлеты - это разное, уважаемый.

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

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

вы уж не нервничайте так. если вам какие-то там рефлексии и темплейты нужны, чтобы поля из классов удалять, то и слава богу.

Если без рефлексий вам прям неосилить сериализацию, то пусть умные дяди соберутся и вам сделают для этого рефлексию, но пусть и будет ключик - fno-introspection, для нормальных.

Для тех, кто может скинуть поле в поток, и прочитать из потока, без изучения талмудов стандартов и пропозалов в ожидании с++26. Эту невозможную задачку решили лет 70 назад, а вы все сравниваете раст с с++26, вместе с каким-то клоуном, да еще и ссылки всем на это даете

Если без рефлексий вам прям неосилить сериализацию

Специально для альтернативно одаренных: речь не о том, чтобы «осилить», речь о том, чтобы делать это проще, удобнее, быстрее и дешевле.

Люди давно научились передавать информацию на расстояния. Только почему-то прогресс в этой области не останавливается. Почему-то не застряло человечество на стадии пеших гонцов и голубиной почты. А дошло до спутниковой связи и Интернета. Да и останавливаться не собирается.

Зачем сидеть в каменном веке и ограничивать себя скудными возможностями «Си с классами», когда можно достигать лучших результатов быстрее и легче?

В чем смысл вашего луддизма?

У вас настолько реверсивное умственное развитие, что учиться новому ну вот вообще никак?

Вы реально дебил, не способный на них ответить, или притворяетесь?

Вам сказали - не нервничайте так. Вопросов от вас я не помню. Кроме каких-то несерьезных криков про пруфы, и манно-кашечных на голубом глазу - а зачем вообще оно надо? Уж сто пицот раз я сказал зачем она нужна.

Вам не надо, другим надо. Мне вот рефлексия не нужна, а вам - нужна позарез. У вас видимо встала вся сериализация, а у других все отлично.

Вопросов от вас я не помню.

Зачем помнить то, что можно просто перечитать отмотав диалог назад.

А то у вас удобная позиция: обвинить собеседника в том, что он не говорил, уйти от прямого вопроса, а потом такой «а я не помню».

Фу таким быть.

чтобы делать это проще, удобнее, быстрее и дешевле.

Это понятия не относятся к разработке по. Вы счас в темном лесу заблудитесь со своими оценочными суждениями качества ПО. У вас нет меры простоты, удобства, и дешивизны. Дешевое в производстве может стать слишком дорогим в эксплуатации. И так далее. А без способов измерить ваши оценочные суждения, они являются просто балабольством.

уйти от прямого вопроса

какого «прямого вопроса»? пишите его прямо тут.

какого «прямого вопроса»? пишите его прямо тут.

Все уже написано, если вы заикаетесь об экономии времени, то не заставляйте собеседников повторять то, что уже было написано: Герб Саттер -- отчёт о встрече по стандартам ISO C++ в июне 2025 года (комментарий)

чтобы делать это проще, удобнее, быстрее и дешевле.

Это понятия не относятся к разработке по.

Да вы что?!!!

напишите вопрос явно. то что написано там - это болтология о «смыслах», это тот самый «манно-кашечный вопрос на голубом глазу» - а зачем оно вообще?

Да вы что?!!!

а вот так. интроспекция не увеличивает простоту, «скорость», удобство.

качество ПО впрямую связано с проектированием, сталгайдами, технологиями, методологиями, уровнем команды, ресурсами, и тыщами прочих причин… и не связано с интроспекцией.

если вам так нужна интроспекция для качества ПО - берете лисп, она там полная, забываете обо всем другом, и пишете свое ПО.

то что написано там - это болтология о «смыслах»

Не болтология, а ключевой вопрос.

Но если после всех сделанных мной объяснений вы так и не поняли, то дальше нет смысла.

Реверсивный уровень развития интеллекта помноженный на сверхсамоуверенность – страшная сила.

качество ПО впрямую связано с проектированием, сталгайдами, технологиями, методологиями, уровнем команды, ресурсами, и тыщами прочих причин… и не связано с интроспекцией.

До добавления шаблонов в C++ тоже разрабатывалось ПО на C++. Контейнеры люди делали. Алгоритмы, применяющие одни и те же действия к разным типам данных. От дублирования кода избавлялись как-то (через макросы, например).

Только вот шаблоны вывели удобство при выполнении таких действий на совершенно другой уровень. Сократили сроки работ, повысили качество.

Да появление одних только std::auto_ptr/unique_ptr сняло кучу головной боли и избавило от сотен тысяч (если не миллионов) багов.

И вот хз куда шаблоны отнести в вашем списке. Может к «технологиям»?

И если к технологиям можно, то почему там не может оказаться и интроспекция? Хотя, вопрос в вашем случае, риторический.

Но если после всех сделанных мной объяснений вы так и не поняли, то дальше нет смысла.

вам реально нет смысла. еще в самом начале вам было указано, что в с++ нет никаких implement для «интерфейсов», а есть множественное наследование для всего сразу.

если после этого вы спрашиваете - зачем оно?, значит вам нужно долго обьяснить зачем вообще интерфейсы нужны, что они бывают и целиком абстрактные и частично, и даже полностью дефолтно реализованные, и по сути в с++ «интерфейсы» это просто такие классы с виртуальными методами… и вы после этого опять спрашиваете - зачем множ. наследование???

Да ладно - «интерфейсы». Как вам было заявлено, нет никаких теоретических ограничений на множ. наследование в принципе. Потому оно реализовано в с++. В этом смысле в си++ все сделано честнее, чем в жаве и шарпе.

Простите, вы не понимаете совсем простых вещей? Вы по прежнему нуждаетесь в ответе на вопрос - зачем множ. наследование в с++.

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

если после этого вы спрашиваете - зачем оно?

Я не спрашиваю у вас зачем множественное наследование в C++. Я спрашиваю почему в вашем примере сделано так как сделано, с какой целью и какой в этом смысл. Ибо смысла не видно.

Но вы не можете объяснить даже свой собственный код. Что меня уже ничуть не удивляет. Удивляет то, что кто-то вам платит за «работу». Подозреваю, что вы тупо на*бываете своего работодателя своим луддизмом и нежеланием изучать новое.

Как вам было заявлено, нет никаких теоретических ограничений на множ. наследование в принципе.

Вы упорно проигнорировали мой намек на существование проблемы с виртуальными методами с одним именем и одинаковой сигнатурой. По-моему, даже дважды проигнорировали. В C++ это проблема не решается. А в Eiffel-е, где множественное наследование было с самого начало и сделано оно там на загляденье, решается.

Вы по прежнему нуждаетесь в ответе на вопрос - зачем множ. наследование в с++.

Повторю еще раз: я знаю, зачем оно в C++ и как применяется. А судя по вашей невмняемости, то знаю и побольше вашего.

И повторю еще раз посыл, на который вы возбудились, но не смогли как-то опровергнуть: множественное наследование от классов с данными внутри в C++ нужно редко, скорее всего, даже очень редко.

https://brevzin.github.io/c++/2024/09/30/annotations/

это барри сцуко чокнутый. он хочет чтобы в с++ было как в расте, типа так:

#[derive(Serialize)]
struct Person {
    #[serde(rename = "first name")]
    first: String,

    #[serde(rename = "middle name", skip_serializing_if = "String::is_empty")]
    middle: String,

    #[serde(rename = "last name")]
    last: String,
}

налицо непонимание, что сериализация это чисто имплементация, и не должна торчать наружу в дефиниции класса.

сто пицот лет(вроде еще с первой жавы) сериализацией занимаются не сами классы, а «сериализаторы» - классы-френды, которые могут залезть внутрь класса, спасти его требуху и восстановить. Если сам класс виден наружу(чтобы его отнаследовать), то его сериализатор не должен никому светить внутренности и является по сути final.

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

У одного класса может быть несколько сериализаторов, в разные форматы и по разным поводам!!! у одного класса может быть сериализатор в бинарный формат, в жысон, в xml, еще парочку, и даже в формат памяти Васи Перепелкина - осилятора темплейтов, погибшего под трамваем.

А тут - открываешь такую либу линейной алгебры к примеру, а там куча классов, явным образом разукрашенных хинтами о сериализации этих классов. Оно пользователю надо? Какое ему дело, как эта либа спасается в свое внутреннее представление?

То есть вопрос - как размалевать хинтами экспортируемую декларацию класса не имеет никакого практического интереса. Так делать - это ошибка проектирования.

Вообщем пока - стыд и позор. продолжаю наблюдение.

Вообщем пока - стыд и позор

Продолжайте держать нас в курсе, ваше мнение очень важно для нас.

барри предлагает раскрашивать хидеры вот такой вот мутотой, даже если она пользователю не нужна.

struct [[=derive<serde::Serialize>]] Person {
    [[=serde::rename("first name")]]
    std::string first;

    [[=serde::rename("middle name")]]
    [[=serde::skip_serializing_if(&std::string::empty)]]
    std::string middle = "";

    [[=serde::rename("last name")]]
    std::string last;
};

это у него типа с++. :)))

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

Никому вовне не интересно, что поле «last» куда-то запишут как «last name» (ну кроме хакира тру васи, что полезет это поле искать в каких-нить файлах.). А кому оно еще надо?

продолжаю наблюдение.

барри предлагает раскрашивать хидеры вот такой вот мутотой

Он этого не предлагает. Он показывает, как это сделать, если кому-то нужно именно это.

Описанные в его блоге механизмы derive<Debug> и derive<serde::Serialize> всего лишь примеры использования C++ной рефлексии, а не предполагаемая часть стандарта C++26.

facepalm.jpg

пока что он предлагает всякий вздор, не имеющий смысла, и я сказал почему.

а как он предлагает писать нормальные сериализаторы, чтобы был например сериализатор в бинарный формат(для передачи по сети), и сериализатор в текстовый(навроде жысона) для сброса состояния на диск.

чтобы как у людей.

ладно буду читать, вы все равно не знаете.

дочитал. вроде ничего такого нет. полчаса прошли впустую… я ж говорю - ссылочный спам.

дочитал. вроде ничего такого нет. полчаса прошли впустую…

У него там отдельный раздел на эту тему есть: https://brevzin.github.io/c++/2024/09/30/annotations/#library-design

Впрочем, опыт общения с вами уже показал, что вы не тем местом читаете.

Он показывает, как это сделать, если кому-то нужно именно это.

а вам интересно так вот раскрашивать хидеры? :)

template <Serializer S>
auto serialize(Person const& p, S& serializer) -> void {
    auto state = serializer.serialize_struct(
        "Person",
        2 + (p.middle.empty() ? 0 : 1));
    state.serialize_field("first name", p.first);
    if (not p.middle.empty()) {
        state.serialize_field("middle name", p.middle);
    } else {
        state.skip_field("middle name", p.middle);
    }
    state.serialize_field("last name", p.last);
    state.end();
}

а где тут «интроспекция»? тут явно связывается поле с тегом. так сейчас ручками делают.

state.serialize_field("last name", p.last);

вот знчение поля p.last записывается куда-то там с тегом - «last name». ааа понял. это с ключиком - no-introspection! :)

и вообще, не будьте наивным мальчиком, нормальный сериализатор целиком отвечает за формат представления, и может делать с ним все что угодно, что и не снилось вашей интроспекции.

Например он может делать бинарный формат вообще без имен полей, а сериализовать просто по порядку, или иметь произвольные, ему удобные имена полей. Карочи, просто разметкой декларации класса с каким-то там тегами полей тут не обойтись.