Я вот считаю, что наследование должно быть виртуальным по умолчанию

а я вот - что компилятор должен взрываться с воплем "dreaded diamond detected, define your intentions with virtual or nonvirtual" )

А, это... Вижак вроде бы варнил ...

вижак нем как рыба с enable all warnings (смотрел на последнем релизе 15.7.4)

вижак нем как рыба с enable all warnings (смотрел на последнем релизе 15.7.4)

Когда я последний раз с ним общался на эту тему , он был 5-ой версии.

Когда я последний раз с ним общался на эту тему , он был 5-ой версии.

ты хочешь подчеркнуть свою дремучесть? :)

Нет, но я за правду...

Нет, но я за правду...

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

Я вот считаю, что наследование должно быть виртуальным по умолчанию

это же очень большой оверхэд по сравнению с обычным наследованием

это же очень большой оверхэд по сравнению с обычным наследованием

Вот ответь пож. на вопрос, когда ты пишешь class MyClass : public YourClass { }; ты сколько экземпляров YourClass ожидаешь увидить в своём объекте ?

это же очень большой оверхэд по сравнению с обычным наследованием

Оверхед побоку. Логика важна

Вот ответь пож. на вопрос, когда ты пишешь class MyClass : public YourClass { }; ты сколько экземпляров YourClass ожидаешь увидить в своём объекте ?

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

Ты на вопрос не ответил.

Оверхед побоку. Логика важна

не скажи

я посчитал, что он не требует ответа). На уровне MyClass ожидаю один

я посчитал, что он не требует ответа). На уровне MyClass ожидаю один

Вот, это и означает, что ты ожидаешь, что наследование должно быть виртуальным. А оно -- невиртуальное.

Вот, это и означает, что ты ожидаешь, что наследование должно быть виртуальным. А оно -- невиртуальное.

и какая разница? вроде ж multiple inheritance признали плохим тоном, в чем в случае одиночного разница?

и какая разница? вроде ж multiple inheritance признали плохим тоном, в чем в случае одиночного разница?

Да ты что, такую ересь в С++ чате произносить вслух...

и какая разница? вроде ж multiple inheritance признали плохим тоном, в чем в случае одиночного разница?

Кто признал множественное наследование плохим тоном? Java-телепузики?

Вот, это и означает, что ты ожидаешь, что наследование должно быть виртуальным. А оно -- невиртуальное.

я ожидаю это на уровне MyClass, а то что произойдёт при наследовании от него нужно думать уже по месту тому, кто это делает

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

я ожидаю это на уровне MyClass, а то что произойдёт при наследовании от него нужно думать уже по месту тому, кто это делает

некошерно

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

Про потоки в std почитай, да?

некошерно

А как кошерно?:)

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

Вот ответь пож. на вопрос, когда ты пишешь class MyClass : public YourClass { }; ты сколько экземпляров YourClass ожидаешь увидить в своём объекте ?

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

Я о логике говорил только. О семантике объектной модели при MI. Оверхед -- это фигня, ты бы знал, какой оверхед скажем в LISP при множественной диспетчеризации методов, и нифига, терпят... Оверхэд может рассматриваться ПОСЛЕ того, как предложена одна или другая семантическая модель объектной системы. Можно рассмотреть их возможные реализации и возможный оверхэд... Но это не интересно, если тебе базовая семантическая модель не подходит. Грубо говоря, если ты хочешь constexpr в compiletime, ты же не думаешь об оверхеде компилятора ? Нет. Ты просто хочешь и все. К тому же, когда Страус делал MI, там не проблемы оверхеда решающими были...

Очевидно, когда используется Lisp, Java, C#, то нужно быть готовым к оверхеду большему, чем у плюсов или ассемблера, а в случае C++ не хочется платить за неиспользуемое. И про преждевременную оптимизацию тоже уже много раз обсуждалось. Но постоянное виртуальное наследование, имхо, не совсем вопрос tradeoff, т.к., во-первых, оно редко используется (нормально же живут люди в C#/Java), во-вторых, при множественном наследовании в C++ нужно чётко понимать, что ты делаешь и на что это влияет.

лисп давно себя позиционирует как язык с минимальным оверхедом и исповедует принцип "не используешь - на платишь"?

а то можно и ЖС привести как пример, чо

Я о логике говорил только. О семантике объектной модели при MI. Оверхед -- это фигня, ты бы знал, какой оверхед скажем в LISP при множественной диспетчеризации методов, и нифига, терпят... Оверхэд может рассматриваться ПОСЛЕ того, как предложена одна или другая семантическая модель объектной системы. Можно рассмотреть их возможные реализации и возможный оверхэд... Но это не интересно, если тебе базовая семантическая модель не подходит. Грубо говоря, если ты хочешь constexpr в compiletime, ты же не думаешь об оверхеде компилятора ? Нет. Ты просто хочешь и все. К тому же, когда Страус делал MI, там не проблемы оверхеда решающими были...

Ильюхо, я благодарен тебе, что не ты был автором C++

Про потоки в std почитай, да?

хорошее оправдание, да, апплеяция к авторитету во всей красе

Очевидно, когда используется Lisp, Java, C#, то нужно быть готовым к оверхеду большему, чем у плюсов или ассемблера, а в случае C++ не хочется платить за неиспользуемое. И про преждевременную оптимизацию тоже уже много раз обсуждалось. Но постоянное виртуальное наследование, имхо, не совсем вопрос tradeoff, т.к., во-первых, оно редко используется (нормально же живут люди в C#/Java), во-вторых, при множественном наследовании в C++ нужно чётко понимать, что ты делаешь и на что это влияет.

бэд дизайн СТЛ вот использует же

Да нет, все верно. Я очень долгое время думал, что ОпенОффис на яве написан, именно из-за таких вещей.

Ильюхо, я благодарен тебе, что не ты был автором C++

ахахах

Пока хлеб не отняли - https://bincrafters.github.io/2018/06/28/OSS-vs-Enterprise-Dependency-Management/

Это статья? Ты накрапал?

Это статья? Ты накрапал?

не, это не моя статья

union AudioCodecProfile { struct { unsigned int channels : 8; unsigned int frame_size : 24; unsigned int sample_rate : 16; unsigned int extradata_size : 16; } s; uint64_t u64; }; AudioCodecProfile p = {0}; кланговский анализатор предупреждает что missing field 'frame_size' initializer это получается {0} здесь кастуется на внутреннюю структуру, а не на весь объект?

union AudioCodecProfile { struct { unsigned int channels : 8; unsigned int frame_size : 24; unsigned int sample_rate : 16; unsigned int extradata_size : 16; } s; uint64_t u64; }; AudioCodecProfile p = {0}; кланговский анализатор предупреждает что missing field 'frame_size' initializer это получается {0} здесь кастуется на внутреннюю структуру, а не на весь объект?

да, { 0 } работает с массивами, как положено, со структурами - по сути, инициализирует в 0 первый подобъект

https://en.cppreference.com/w/c/language/struct_initialization

ох и впрямь, забыл что оно только на массивах себя ведёт как memset

ох и впрямь, забыл что оно только на массивах себя ведёт как memset

а зачем тебе для глобального объекта иницилизатор?

а зачем тебе для глобального объекта иницилизатор?

не глобального, внутри функции

не глобального, внутри функции

а почему ты не используешь value initialization AudioCodecProfile p{};?

хотя тут говорят иначе... https://stackoverflow.com/questions/1538943/why-is-the-compiler-throwing-this-warning-missing-initializer-isnt-the-stru

а почему ты не используешь value initialization AudioCodecProfile p{};?

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

не по теме, может сталкивался кто, Как получить физический серийный номер процессора без dmidecod и cpuid, из /sys? если без рута, то вообще огонь

а почему ты не используешь value initialization AudioCodecProfile p{};?

Это структура, поэтому это будет не value-initialisation, а agregate-initialisation

"In all cases, if the empty pair of braces {} is used and T is an aggregate type, aggregate-initialization is performed instead of value-initialization. "

Это структура, поэтому это будет не value-initialisation, а agregate-initialisation

в деталях вы правы, но в общем, я не сильно ошибся ;): This is the initialization performed when a variable is constructed with an empty initializer.

и частный случай value initialization - aggregate-initialization.

Anton или вы не согласны с тем, что мемберы юниона при этом не будут zero инициализированы?

в деталях вы правы, но в общем, я не сильно ошибся ;): This is the initialization performed when a variable is constructed with an empty initializer.

Я как раз согласен с тем, что мемберы будут zero-инициализированы)

Я как раз согласен с тем, что мемберы будут zero-инициализированы)

ну, а терминологически вы абсолютно правы, хотя агрегатная частный случай для value initialization

ну, а терминологически вы абсолютно правы, хотя агрегатная частный случай для value initialization

Короче хронология такая: Имеем выражение вида AudioCodecProfile p{}; Для объекта p это будет означать агрегатную инициализацию, т.к. AudioCodecProfile - агрегатный тип В свою очередь, из за того, что initializer list в данном случае пуст, для всех полей типа AudioCodecProfile вызовется value-initialization. А т.к. все поля у него - простые типы, для всех вызовется zero-initialisation, в результате которого они обнулятся Как то так))

Короче хронология такая: Имеем выражение вида AudioCodecProfile p{}; Для объекта p это будет означать агрегатную инициализацию, т.к. AudioCodecProfile - агрегатный тип В свою очередь, из за того, что initializer list в данном случае пуст, для всех полей типа AudioCodecProfile вызовется value-initialization. А т.к. все поля у него - простые типы, для всех вызовется zero-initialisation, в результате которого они обнулятся Как то так))

на самом деле как-то так:

ERROR: S client not available

наш случай (8.4)

наш случай (8.4)

Это драфт или электронная версия стабильного стандарта от ISO?

Это драфт или электронная версия стабильного стандарта от ISO?

драфт

наш случай (8.4)

Ну, в моём сообщении это последний этап) Просто если бы было выражение вида AudioCodeProfile p{0}, то это была бы уже copy-initialization

драфт

Ты в интернете его так смотришь? Или у тебя офлайн версия?

Ты в интернете его так смотришь? Или у тебя офлайн версия?

оффлайн

оффлайн

А через какую программу? ? У меня на винде в SumatraPDF крашится при поиске слова...

А через какую программу? ? У меня на винде в SumatraPDF крашится при поиске слова...

в акробате

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

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

https://g.redditmedia.com/6KXBnnAAlbCsV5A-4d23dS-FrxjNxyO5FGVMKIL_SCk.gif?fm=mp4&mp4-fragmented=false&s=ab7dc37a40bc4a7c10188e69bce4876b

Ты в интернете его так смотришь? Или у тебя офлайн версия?

http://eel.is/c++draft/ а ещё бывает так

http://eel.is/c++draft/ а ещё бывает так

О, вот это царский подгон. Там ещё и разные стандарты есть

http://eel.is/c++draft/ а ещё бывает так

опа-опа

спасибо за полгон

не знаете есть ли либы под c++ для генерации фейковых данных? https://github.com/ffaker/ffaker типа такого (оно для руби)

не знаете есть ли либы под c++ для генерации фейковых данных? https://github.com/ffaker/ffaker типа такого (оно для руби)

а онлайн пойдут? https://mockaroo.com/

а онлайн пойдут? https://mockaroo.com/

надо подумать

но хотелось бы либу оффлайн)

не знаете есть ли либы под c++ для генерации фейковых данных? https://github.com/ffaker/ffaker типа такого (оно для руби)

фаззеры?

фаззеры?

не

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

но хотелось бы либу оффлайн)

нагуглил https://github.com/schoentoon/cxxfaker

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

ээ, фаззеры?

ээ, фаззеры?

https://github.com/aoh/radamsa

ээ, фаззеры?

и как мне фазер заюзать для генерации протокола нужного?

и как мне фазер заюзать для генерации протокола нужного?

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

что значит нужного протокола?