Поэтому мой всем совет. Встречаете убийцу C++: подходите и задаёте

ТРИ ГЛАВНЫХ вопроса

(1) typeid
(2) ошибки в конструкторах
(3) делегация сестринскому типу

Всё. Дальше всё ясно сразу. Люди выкручиваются, ссылаются на бедный LLVM, предлагают аборт, людей корёжит. Почему? Потому что это настоящие проблемы. И настоящие недостатки C++. И красивого решения я тут не видел нигде ни разу. Либо отказ от самой концепции (что сразу проигрыш) либо аборт.

А что такое (3)?

Я выше ответил: при виртуальном наследовании dynamic cast к сестринскому типу и вызов там метода. Очень интересная проблема. Очень криво решена в C++. Никак (вообще НИКАК) не решена нигде кроме C++.

Понятно. А вам доводилось встречаться в своей практике с виртуальным наследованием?

Да конечно. Вам тоже. Вы хотя бы раз писали cout << "Hello world"? Вот. Это оно =)

Вот сейчас не понял. Каким образом это оно?

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

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

Это ошибка. Для индустрии важна фильтрация дураков на ранних подступах. Но с этим и C справляется.

А где оно? Если честно, я всё ещё не понимаю, хотя иерархию наследования вроде бы представил.

в std::ostream

адский дизайн из 90х, хорошо, что сегодня так не делают

class basic_istream : virtual public std::basic_ios<CharT, Traits>

Чем фильтрация дураков поможет индустрии?

«Ошибки в конструкторах» это какая-то дичь, не должны конструкторы быть настолько пробздетыми. Помню был у нас товарищ, который в конструкторе делал HTTP-запрос, но ему быстро настучали по тыкве

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

Хм!

Ага худший способ вывода, который сделан настолько убого что потребовал имплементации с виртуальным наследованием, по вашем формат и его аналоги на ровном месте появились? В общем довольно слабая аргументация

Там точно оно есть?

Да https://github.com/llvm/llvm-project/blob/main/libcxx/include/istream#L180

Ты на стандарт укажи а не имплиментацию

Эм речь про имплементацию

Эм, выйдет новый llvm и не будет

Угу за 30 лет не вышел что то

Кого? Ллвм?

У всех реализаций

iostream отличный способ вывода так как позволяет легко переопределить вывод для пользовательских классов. Он несравнимо лучше printf и любых аналогов в любых других языках. Просто небо и земля. Если вы этого не понимаете, то в общем разговаривать не о чем. boost::format появился на базе iostream как забавные вариации на тему. Широкого распространения не получил.

fmt format с некоторыми изменениями принят в стандарт

он отвратителен.

Тут стоило бы задуматься, iostream – это способ вывода или способ форматирования? И уже в этом вопросе видно невооружённым взглядом проблему. Он бросается решать больше, чем одну проблему и решает их все одинаково. Одинаково плохо

В absl есть Substitute, в folly Format, в бусте реализация довольно плохая. По поводу юзер типов не вижу проблемы https://fmt.dev/latest/api.html#formatting-user-defined-types

я кстати не вижу ничего плохого в printf, более того, многие компиляторы умеют его статически проверять

Разнаная размерность типов на платформах

а где это конкретно создаёт проблему?

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

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

Угу иначе как сверхгениальным и не назовешь

жаль что в плюсах нет такого принтф как в D

Ты берёшь либу где писали под 32 и компилишь как 64, или наоборот

не юзай %ld и не страдай

:) я бы тебя расцеловал, еслиб ты работал с легаси

привет, у меня в легаси куча лонгов :)

Лонги тут при чем?

а какой ещё тип имеет такую проблему?

Главная проблема что на разных ос может либо лонг разного размера быть, либо тайпдефы испольщуют разные типы

int_fast_32_t x = 5; printf("???", x);

где ты в легаси такие типы видел?

На android чар, вот прям разное поведение при переполнении

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

Ну мне теперь стало легче

"%"PRIdLEAST32

Что за легаси ?

любой старый как труха код

это неизбежные издержки множественного наследования. А от него отказываться не хочется, очень сильная вещь

ну если рассматривать iostream как вещь, где скорость неособо важна, а удобство нужно - он действительно хорош. И добавлять пользовательские типы даже легче чем с std::format(там явно что-то не доглядели в этом плане) Но скорость у стримов страдает и они правда пытаются решить слишком много проблем. И напрягает что добавляют новые стримы(spanstream например) вместо того чтобы как-то переделать концепцию, чтобы убрать виртуальные функции и наследование (повысить производительность)

Ну нет же

Ну и проблема перфа стримов концептуальная Смотри по своей сути format это конкатенация н строк А stream это аппенд н строк Второе by design делает log n аллокация вместо 1

По поводу того что user defined для стримов удобнее чем для формата я в целом согласен, но я предпочитаю ToString метод

Но это менее оптимально да

там буфер так что это даже лучше

Мне кажется не корректно сравнивать format и cout, логичнее со stringstream. Или cout с print Ну и в случае format или stringstream речь как раз о кейсе который я описал