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

и вас корежит множественное наследование плюсов

А давайте с пруфами? Где именно меня корежит и где именно я как-то отрицательно отзывался о множественном наследовании?

Я сказал, что множественное наследование мало когда нужно, а когда нужно, то хорошо, что оно есть.

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

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

Про ромбовидное наследование я вообще не заикался.

Достаточно, чтобы ваши множественные предки не имели предка общего.

Достаточно, чтобы в предках был виртуальный метод с одинаковой сигнатурой, чтобы начались приключения. От которых, например, избавлен Eiffel, но не избавлен C++.

и не собираюсь читать ссылы

Т.е. вы декларируете, что не хотите учиться? Смело, но в вашем случае, вполне ожидаемо.

Если вы сами не поняли, про что там - зачем даете ссылку?

Чтобы не получилось, как в анекдоте про то, что Карузо не такой уж и великий певец.

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

Я ее не придумывал. Был код, который при работе расходовал сотни мегабайт ОП. Этот расход нужно было сократить.

Сокращать можно было:

• либо перепроектировав решение;
• либо соорудив лисапед.

Соорудить лисапед оказалось проще и быстрее.

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

И вот что из этого специфического опыта выходит: по прошествии некоторого (не очень продолжительного времени) всегда оказывается, что не бывает так, чтобы все было сделано хорошо с первого раза.

По крайней мере, навскидку, в вашем кодике видно переувлечение руководствами по с++, всякой требухой из std, и особенно внушают нотации вида «m_member»

Так, к вашему сведению, в C++ нет официально установленного code style. Во множестве проектов используется PascalCase, во множестве camelCase, во множестве snake_case. Во множестве проектов нет префиксов для членов класса (но в части таких проектов заставляют к ним обращаться только через this->), во множестве – суффикс _, во множестве – префиксы _, m_ или m.

Использование любой из вышеперечисленных нотаций ни о чем не говорит кроме как о том, что используется конкретная нотация. Делать из этого какие-то выводы… Ну такое себе. Еще одна грань «малолетнего дебилизма», не более.

Ладно, я всегда питал некую привязанность к крестам, но все-таки.

[:expand(std::meta::nonstatic_data_members_of(^^T, ctx)):] >> [&]<auto member>{

Достаточно. Это говно должно сдохнуть. Пусть оно сдохнет.

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

посмотрел. это пять. это как «множественное наследование не нужно». Это типичный пример неверного проектирования данных.

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

struct Data {
  int _x; ///обязательные поля
  int _y;
  Extension* _ext = nullptr; ///расширение данных если надо
}

struct Extension {
  vector<int> _optional;
  Extension* _next = nullptr; ///можно прицеплять дополнительные расширения.
}

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

Эта фигня пишется на паскале, вообще без всякой плюсишной шаблонной магии. :)

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

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

Так, к вашему сведению, в C++ нет официально установленного code style.

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

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

У любой задачи есть простое, очевидное неправильное решение.

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

Так а что с пруфами?

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

Я не говорил, что оно что-то нарушает.

Вы говорите что оно не нужно

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

Но вы либо не читаете, что вам пишут, либо читаете не тем местом.

потому и не используйте натужный от майкрософта.

Не говорите людям что им делать и они не скажут вам куда вам пойти.

Это самое худшее, что можно представить.

Гораздо хуже – это Ыксперты вроде вас, которые все знают и на все у них готовые рЫцепты.

Раньше можно было народ пугать перлом, теперь – крестами.

Синтаксис да: говно лютейшее.

У любой задачи есть простое, очевидное неправильное решение.

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

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

Короче «сложная задачка» не стоит и выеденного яйца. Одна ключница делала, вторая стала исправлять. :)))

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

Вот именно, вы «привели».

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

До вашей самоуверенности даже мне очень далеко, хотя казало бы…

и если обьекты будет менять свои данные динамически(массивы появляться и исчезать) - оно будет работать.

Так и предыдущее работало. Но с недостатками. Как и ваше.

И у сделанного мной есть недостатки. Повторюсь: не бывает ничего идеального, даже то, что кажется сделанным хорошо, спустя время оказывается из категории «ключница делала», особенно если оценку дает кто-то вроде вас, с самомнением выше Эвереста.

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

Термин «статические специализации» в рамках разговора о C++ нуждается в расшифровке.

А не вашей шизофренией с темплейтами.

Ниасилили, теперь бегаете по LOR-у доказывая, что шаблоны и обобщенное программирование нинужна?

вот точная ваша цитата, как «особый взгляд» на програмирование вообще и с++ в частности.

Вот есть множественное наследование в C++. Практически никогда не надо. Но когда надо, то хорошо, что оно есть. Подозреваю, что интроспекция будет востребована чуть чаще, чем множественное наследование.

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

А ваша интроспекция нужна чуть более чем никому. И большинство ее не будет использовать в принципе, за ненадобностью, и возможными рантаймовыми довесками. Вангую что будет такой ключик -no-introspection, и он будет стоять по умолчанию. :)

Ниасилили, теперь бегаете по LOR-у доказывая, что шаблоны и обобщенное программирование нинужна?

вам точно не нужно. вы пока просто поупражняйтесь со списками. и смените эту страшную нотацию от MS, фу.

да каждый пятый класс в с++ реализует какой-нибудь «интерфейс»(причем с дефолтной реализацией части методов и внутренним состоянием)

Покажите на каком-то открытом проекте?

Желательно на своем, если таковой есть.

И большинство ее не будет использовать в принципе, за ненадобностью, и возможными рантаймовыми довесками. Вангую что будет такой ключик -no-introspection, и он будет стоять по умолчанию. :)

Вы бы хоть ознакомились бы с предметом разговора. Узнали бы, что это исключительно compile-time штука.

А то выступаете в роли «Пастернака не читал, но осуждаю».

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

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

Как можно «вдуматься» в задачу, если она не сформулирована.

Она сформулирована.

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

Вы бы хоть ознакомились бы с предметом разговора. Узнали бы, что это исключительно compile-time штука.

Вы такой авторитет, что придется перепроверять у дипсика. Я вот чета не уверен, что они остановятся чисто на времени компиляции.

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

впрочем не думайте об этом. пока думайте про списки.

то могли бы вопрос(ы) позадавать.

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

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

Вы просили пример – пример я вам привел. А жалобы на «отсутствие постановки задачи» начались поже, когда вы пёрднули в лужу и пошли отмазки.

Да и с ключиком «no-introspection» вы свой малолетний дебилизм подтверждаете просто «на ура».

Ваш код где-нибудь в открытом доступе увидеть можно?

не знаю. обычно это под disclosure agreement.

Т.е. подтвердить то, что вы хотя бы где-то как-то пишете хоть какой-то работающий код вы не можете?

Так и запишем.

Примеры классов со множественным наследованием данных там же, под NDA?

Так и запишем.

Зайцы! А ежик всех записывает!

Примеры классов со множественным наследованием данных там же, под NDA?

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

Парадигма классификации она везде одна, что плюсы, что шарп с явой.

И получаешь множественное наследование на с++.

Вас что, в школе читать не научили?

Так не сложно повторить то, что уже было написано: «Да, сразу не сделал уточнение для персонажей, вроде вас, что речь идет о наследовании классов с данными внутри. Но потом это уточнение было сделано.»

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

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

Ну вообще было бы неплохо.

Чисто моё имхо:

Если переменная просто объявлена - она считается инициализированной нулём или соответствующим значением.

Если переменная объявлена с неким спецсловом, например int x = undefined, она считается неинициализированной, как сейчас.

Конечно код вида int x; x = 1 будет оптимизатором оптимизирован.

Не знаю, кому от этого будет хуже.

При чём здесь и сейчас:

Глобальные переменные уже инициализируются нулём.

У объектов вызывается конструктор по умолчанию.

То бишь это лишь сделает всякие int-ы работающими чуть логичней и весь язык чуть более разумным.

чем вам мешает множественное «наследование с данными внутри»?

Потому что тогда начинают «плыть» смещения внутри объекта и если кто-то злоупотребляет static_cast-ами, то могут начаться проблемы.

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

у вас тут только два варианта - встроить или множественно отнаследовать. и в обоих случаях будет смещение от указателя на обьект. по эффективности (и в бинарном виде) код будет одинаковым. но при наследовании будет еще и совместимость по этой базе.

итак - что вас пугает?

итак - что вас пугает?

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

Для малолетних дебилов: я не считаю множественное наследование злом и не говорю, что но неизбежно ведет к проблемам.

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

Вас это, по видимому, как-то задевает. Но вы не можете в пруфы.

зело плюсую ваши посты в этой теме.

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

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

рефлексии

Горячо одобряю. Я лет 10 жду эту фичу. Но синтаксис сделали говно.

Глобальные переменные уже инициализируются нулём.

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

Откуда вообще взято, что у типов обязано быть дефолтное значение? ну вот какое дефолтное значение у типа - «дни недели»? понедельник, что ли?

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

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

Не путай семантику языка и оптимизатор. Это никак не скажется на производительности корректного кода.

Откуда вообще взято, что у типов обязано быть дефолтное значение? ну вот какое дефолтное значение у типа - «дни недели»? понедельник, что ли?

В C++ нет типа «день недели».

Потому что тогда начинают «плыть» смещения внутри объекта и если кто-то злоупотребляет static_cast-ами, то могут начаться проблемы.

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

Говорю последний раз - в множ. наследовании одна реальная проблема - ромб. И ее приходится решать вводя специальные декларации о виртуальности баз. Если запретить ромб - декларации о виртуальности баз можно выкинуть.

В C++ нет типа «день недели».

тогда давай введем:

enum class Weekdays {….};

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

нулем естессно. а это вообще не наш день недели. это вовсе не то что мы хотим.

Инициализируй тем, чем хочешь, если нуль не нравится. Это то, как язык работает здесь и сейчас. Можешь попросить добавить для enum-ов возможность указывать значение по умолчанию, отличное от нуля, я не против, но это вопрос совершенно независимый от обсуждаемого. Обсуждается вопрос в том, чтобы инициализировать нулём значения локальных переменных, так же, как это сейчас делается для глобальных переменных. И добавить специальный синтаксис, позволяющий отменить эту инициализацию на свой страх и риск, опять же для обоих случаев.

я второй раз, но менее развернуто, говорю, что этот ваш аргумент - чушь собачья.

Какие ваши доказательства?

У вас выбор - либо встройка, либо множ. наследование.

При первом варианте в классе, куда что-то было включено в виде простого члена класса, this не меняется.

class A {...};

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

Тогда как здесь у вас в методе g() «возможны варианты» (c)

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

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

Пруф: https://wandbox.org/permlink/FPS4E1e3ilhEkGZH

в множ. наследовании одна реальная проблема

Нет. И об этом я писал, но вы не читатель. Да и писатель так себе.

А почему 0? Это каким-то образом следует из применяемой аппаратной платформы или из условий задачи? Неужели обязательно надо инициировать все переменные (вместо тех, которые действительно надо инициировать)? Чем неправильная обработка неинициированных переменных отличается от неправильной обработки неправильно (по-умолчанию == 0) инициированных переменных?

ваш пруф у меня не открывается. попробуйте пруфить через godbolt

ваш пруф у меня не открывается. попробуйте пруфить через godbolt

Не вопрос: https://godbolt.org/z/37a3YbP51

Вопрос в том, когда вы приведете хоть один пруф тому, что говорили выше.

вы явно не разобрались с вопросом.

у вас функция g должна быть в первом случае тоже в A. вот туда ее нарисуйте и вызовите от мембера _a. :)

у вас класс A разный, а должен быть один. Мы говорим о наследовании или включении ОДНОГО И ТОГО же класса. А у вас разные классы и вы вызываете функции g из разных классов.

не нелзья же так мелко жулить.

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

Чем неправильная обработка неинициированных переменных отличается от неправильной обработки неправильно (по-умолчанию == 0) инициированных переменных?

Тем, что инициализированные нулём переменные всегда инициализируются нулём. Поэтому код работает одинаково. Если он всегда работает неправильно, наверное это заметят при первом запуске и исправят. Неинициализированные переменные содержат в общем случае случайное значение и работают в разное время по-разному. Что приводит к багам, которые сложно находить и отлаживать.

у вас функция g должна быть в первом случае тоже в A.

Схерали?

Допустим, у меня есть код:

template<typename T>
void call_g(T & obj) { obj.g(); }

При подходе с множественным наследованием я спокойно могу сделать так:

B b;
call_g(b);

В случае же, когда экземпляр A инкапсулируется внутрь B, я так сделать смогу только в случае, когда g() определена непосредственно в B. Что и было показано в примере.

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

Уважаеммый, не бейтесь в истериках.

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

у вас два варианта:

1. Отнаследоваться и вызвать ее «от себя»
2. Встроить класс А как поле _a и вызвать от этого поля.

и в общем случае(кроме особо экзотических) никаких других вариантов, у вас нет.

вот и дерзайте )

///— вы же просто вызывали функции с одним именем!!!, но совершенно разной семантикой(у них разные контексты) - из разных классов, чтобы что-то там проиллюстрировать. :))

Сегодняшний день знаменует собой поворотный момент в развитии C++:

У кого-нибудь еще осталось желание усердно изучать Си++, чтобы в итоге очутиться в рабочем коллективе, в котором за малейшую ошибку в коде «обольют грязью», оскорбят и прилюдно унизят? Это школа жизни такая? Чтобы вечером орать от обиды на свою жену и детей?

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

Никто никого не унизит. Главное держаться вместе и бить одновременно в слабые места противника.

Поражаюсь твоему терпению.

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

Да уж, просто мастер-класс в постановке задачи. Снимаю шляпу.

Про темплейты забудьте, на замусоревайте вопрос.

Ах да, вы же не осилили. Ну ладно, тогда ниже обойдемся просто чистым ООП.

и в общем случае(кроме особо экзотических) никаких других вариантов, у вас нет.

А просто создать локальную переменную типа A и вызвать у нее метод g не вариант? Ведь вашей «задаче» вполне соответствует.

В общем, если вы не умеете в шаблоны, то давайте для вас на базе ООП.

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

Например:

struct A {
  virtual void g() { ... }; // Раз уж мы про наследование реализации,
    // то пусть будет тело прямо в A.
  ...
};

void call_g(A & a) { a.g(); }

Это значит, что у класса B должен быть метод g, причем не абы какой, а именно что от класса A. Отсюда и вылазииит множественное наследование: https://godbolt.org/z/r964hdaeM И у нас «плывет» значение this.

Если же мы не хотим имееть множественное наследование реализации, но подсунуть B в call_g хочется, то остается пойти по пути «интерфейсов» и агрегации, на котором нам и потребуется g в B: https://godbolt.org/z/ev715nWE4 И здесь у нас что в B::f(), что в B::g(), this один и тот же.

///— вы же просто вызывали функции с одним именем!!!, но совершенно разной семантикой(у них разные контексты) - из разных классов, чтобы что-то там проиллюстрировать. :))

А вы сейчас трезвы вообще?

Ну мне жаль,

Прекрати выть как баба, соберись, тряпка, будь мужыком!

сегменты нужны ld, а на железе они настолько низко «проваливаются», что мапятся на входы/выходы железки.

Да пусть мапяться хоть господу в задницу, к языку си это какое отношение-то имеет?

В vectors когда железка создаст прерывание (которое полностью гробит текущее выполнение кода) она возьмет переменную, что написана по адресу и сделает indirect jump по этому адресу,

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

А просто создать локальную переменную типа A и вызвать у нее метод g не вариант? Ведь вашей «задаче» вполне соответствует.

ну прям штаны на лямках. не соответствует. в таком случае ни наследование, ни встраивание не нужно. а мы обсуждаем их.

Мы выясняем отличие множ.наследования от встраивания, и для этого проводим эксперимент вида - берем внешний класс A с функцией g()
class A {
  int _var{0};
public:
  bool g();
}

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

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

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

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

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

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