LINUX.ORG.RU

История изменений

Исправление Siborgium, (текущая версия) :

Правильнее задать вопрос, когда это Царь хоть в чём-то был прав.

Хватит «вертеть жопой». Ты ни на что не ответил, и теперь пишешь «ну это же он, он же всегда неправ, все знают».

Где ты тут видишь появление хоть какого-то полиморфизма?

Ты кретин. Тебе многократно написали, что должен писаться auto&&, но до тебя так и не дошло. Ты сделал из visit свой match, который не является полиморфным, и спрашиваешь: «а где полиморфизм»?

Если ты пишешь визит(оверлоадед) c auto, ты получаешь семантический аналог цепочки if (x is Y), так как полнота никак не проверяется и всё падает в else,

Ты кретин. Я многократно писал, что полнота проверяется/

Ты кретин. Я многократно писал, что ты не знаешь кресты, так как код ты так и не понял. Никакого else там не существует, потому что там не должно быть никаких конкретных типов кроме auto&&. Обработчик auto&& сам по себе является полиморфным, поскольку вызывается для разных типов. visit([](auto && x){ ... }, x) – этого достаточно.

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

ты же у нас предупреждения GoF не слушаешь и активно агитируешь за наследование реализации

Цитату и ссылку на сообщение, где я активно агитирую за это.

Кстати, а чем же так плохо наследование реализации? Или мидлу не положено это знать?

Нет, ничего не выйдет. Напоминаю легенду:

Напоминаю легенду: ты виляешь жопой и выдумываешь новые легенды, жидко обосрался и теперь начинаешь фантазировать. Для Rust ты никаких легенд не придумал, фантазии не хватило?

Так что даже не зная про YAGNI никаких контекстов ты, ленивая жопа, писать бы не стал.

Ты кретин. Контексты ввел ты, и уже активно их используешь для обработки в своих матчерах. Обернуть их в структурку и написать auto& get_ctx(SuperCtx& ctx, Id id) для каждого варианта – дело трех минут.


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

Ты лжешь.

Даю «приблизительную» оценку: ни одна библиотека из most downloaded на первой странице crates.io не использует в публичном интерфейсе enum ни для чего, кроме передачи флагов.

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

Идиоматическая обработка ошибок в расте – Result<T, Box<dyn Error>>. Знаешь, почему? Потому что enum не скейлятся. Каждый новый слой enum должен включать предыдущий, разрастаясь бесконечно в размере и приводя к лавинообразным изменениям в коде в случая изменения любого элемента обработки ошибок. Популярность anyhow – отличное доказательство тому.

Указатели на функции типизированы

Поработай хоть раз с таким API.

Видимо не только в rustc не осилили, а примерно во всех языках последних 20 лет.

Те же программисты, которые пишут в MS шлабоны для компилятора плюсов, сразу же теряют этот навык, когда приходится пилить компилятор C#.

«Все языки последних 20 лет» не претендовали на место С/С++, и никакого превосходства над ними не заявляли. А вот в Haskell например осилили, пусть и в крайне кастрированном виде (см. Template Haskell). Но они осилили и свой компилятор, до чего rustc как до звезд.

Давай я ещё раз раздавлю тебя авторитетом. Знаешь такого Александреску? Большой авторитет по шаблонной магии.

Не имеет никакого отношения к современному С++.

он ушёл пилить язык D

В который перетащил фишки, разработанные и предложенные в комитет, но в то время еще не принятые. С тех пор D сдох, никому не нужный, никакой конкуренции современному С++ по возможностям он не составляет.

Насколько же хорош язык go

В котором не нужно делать impl Trait for Type, а просто описываешь интерфейс – и проходить будут все типы, подходящие под этот интерфейс. Ты вообще понимаешь, насколько ты сейчас себя закопал?

пишешь то же самое что и я, просто я описываю твою лень и распиздяйство честно,

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

я правильно понимаю, что C с классами было до 2011? А когда он расцвёл тогда?

Да. Расцвел после С++03, что вылилось в публикацию С++11.

Мало ли что ты написал?

Все, что я написал, ты проигнорировал. Почитай еще раз.

Rust: преобразования указателя на трейт в конкретный тип (комментарий)

Во-первых, LLVM это компилятор, написанный для крестов и на крестах. GCC не целиком, но на большую часть для крестов, и на значительную – на крестах. Во-вторых, фронт фронту рознь, и это становится понятно, если сравнить количество работы, проделываемой clang и rustc. При на порядки более высокой сложности С++ порождаемый clang код вполне достойно выглядит, даже если не сравнивать его с гигабайтами мусора на выходе rustc.

LLVM создана по образу и подобию сишной модели для крестов. Rust был создан для LLVM.

Но если хочешь, можешь разжевать, почему CLANG+LLVM не делает плюсы языком для виртуальных машин, а rustc+LLVM - делает.

Не существует clang+LLVM, clang это часть проекта LLVM. Весь проект LLVM был создан для С++, от фронта до бэка, по модели С++. rustc это убогий фронт для LLVM. Нет LLVM – нет rustc, это сугубо вторичный язык. Вместо того, чтобы писать свой компилятор, бездарности пытаются портировать фронт на gcc – а ведь даже у маргинальных функциональных язычков часто бывают полностью самостоятельные компиляторы. Некто Drew DeVault написал для своего Hare компилятор в одиночку, и это уже полностью рабочий язык – меньше чем за год, если я не ошибаюсь, а ведь язык не из самых примитивных, примерно уровня гошки.

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

Ты кретин. Тебе уже много раз привели в пример Boost.Variant и объяснили, что это реализуется с С++98 – нужны лишь шаблоны и перегрузка.

Ты поехавший. Даже я так плюсы не решился бы обосрать

Это был даже не С++, а С с классами – а задача уже решалась.

со мной, что писать придётся одно и то же число строчек,

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

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

Представь, что на 1 увеличивается не N, а M.

Только с енумами/вариантами это будет локально, а с наследованием - куча строчек по всем файлам.

Бред. При соблюдении правил классического ООП код класса будет инкапсулирован, что по определению исключает «кучу строчек по всем файлам».

Когда ты ссылаешься на авторитет Царя,

Ты кретин. Я ссылаюсь на сообщение, а не на авторитет, о чем явно написано в цитате, которую ты же и приводишь.

Если ты не заметил, я ссылался не на их «авторитет», а на их сообщения,

Исходная версия Siborgium, :

Правильнее задать вопрос, когда это Царь хоть в чём-то был прав.

Хватит «вертеть жопой». Ты ни на что не ответил, и теперь пишешь «ну это же он, он же всегда неправ, все знают».

Где ты тут видишь появление хоть какого-то полиморфизма?

Ты кретин. Тебе многократно написали, что должен писаться auto&&, но до тебя так и не дошло. Ты сделал из visit свой match, который не является полиморфным, и спрашиваешь: «а где полиморфизм»?

Если ты пишешь визит(оверлоадед) c auto, ты получаешь семантический аналог цепочки if (x is Y), так как полнота никак не проверяется и всё падает в else,

Ты кретин. Я многократно писал, что полнота проверяется/

Ты кретин. Я многократно писал, что ты не знаешь кресты, так как код ты так и не понял. Никакого else там не существует, потому что там не должно быть никаких конкретных типов кроме auto&&. Обработчик auto&& сам по себе является полиморфным, поскольку вызывается для разных типов. visit([](auto && x){ ... }, x) – этого достаточно.

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

ты же у нас предупреждения GoF не слушаешь и активно агитируешь за наследование реализации

Цитату и ссылку на сообщение, где я активно агитирую за это.

Кстати, а чем же так плохо наследование реализации? Или мидлу не положено это знать?

Нет, ничего не выйдет. Напоминаю легенду:

Напоминаю легенду: ты виляешь жопой и выдумываешь новые легенды, жидко обосрался и теперь начинаешь фантазировать. Для Rust ты никаких легенд не придумал, фантазии не хватило?

Так что даже не зная про YAGNI никаких контекстов ты, ленивая жопа, писать бы не стал.

Ты кретин. Контексты ввел ты, и уже активно их используешь для обработки в своих матчерах. Обернуть их в структурку и написать auto& get_ctx(SuperCtx& ctx, Id id) для каждого варианта – дело трех минут.


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

Ты лжешь.

Даю «приблизительную» оценку: ни одна библиотека из most downloaded на первой странице crates.io не использует в публичном интерфейсе enum ни для чего, кроме передачи флагов.

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

Идиоматическая обработка ошибок в расте – Result<T, Box>. Знаешь, почему? Потому что enum не скейлятся. Каждый новый слой enum должен включать предыдущий, разрастаясь бесконечно в размере и приводя к лавинообразным изменениям в коде в случая изменения любого элемента обработки ошибок. Популярность anyhow – отличное доказательство тому.

Указатели на функции типизированы

Поработай хоть раз с таким API.

Видимо не только в rustc не осилили, а примерно во всех языках последних 20 лет.

Те же программисты, которые пишут в MS шлабоны для компилятора плюсов, сразу же теряют этот навык, когда приходится пилить компилятор C#.

«Все языки последних 20 лет» не претендовали на место С/С++, и никакого превосходства над ними не заявляли. А вот в Haskell например осилили, пусть и в крайне кастрированном виде (см. Template Haskell). Но они осилили и свой компилятор, до чего rustc как до звезд.

Давай я ещё раз раздавлю тебя авторитетом. Знаешь такого Александреску? Большой авторитет по шаблонной магии.

Не имеет никакого отношения к современному С++.

он ушёл пилить язык D

В который перетащил фишки, разработанные и предложенные в комитет, но в то время еще не принятые. С тех пор D сдох, никому не нужный, никакой конкуренции современному С++ по возможностям он не составляет.

Насколько же хорош язык go

В котором не нужно делать impl Trait for Type, а просто описываешь интерфейс – и проходить будут все типы, подходящие под этот интерфейс. Ты вообще понимаешь, насколько ты сейчас себя закопал?

пишешь то же самое что и я, просто я описываю твою лень и распиздяйство честно,

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

я правильно понимаю, что C с классами было до 2011? А когда он расцвёл тогда?

Да. Расцвел после С++03, что вылилось в публикацию С++11.

Мало ли что ты написал?

Все, что я написал, ты проигнорировал. Почитай еще раз.

Rust: преобразования указателя на трейт в конкретный тип (комментарий)

Во-первых, LLVM это компилятор, написанный для крестов и на крестах. GCC не целиком, но на большую часть для крестов, и на значительную – на крестах. Во-вторых, фронт фронту рознь, и это становится понятно, если сравнить количество работы, проделываемой clang и rustc. При на порядки более высокой сложности С++ порождаемый clang код вполне достойно выглядит, даже если не сравнивать его с гигабайтами мусора на выходе rustc.

LLVM создана по образу и подобию сишной модели для крестов. Rust был создан для LLVM.

Но если хочешь, можешь разжевать, почему CLANG+LLVM не делает плюсы языком для виртуальных машин, а rustc+LLVM - делает.

Не существует clang+LLVM, clang это часть проекта LLVM. Весь проект LLVM был создан для С++, от фронта до бэка, по модели С++. rustc это убогий фронт для LLVM. Нет LLVM – нет rustc, это сугубо вторичный язык. Вместо того, чтобы писать свой компилятор, бездарности пытаются портировать фронт на gcc – а ведь даже у маргинальных функциональных язычков часто бывают полностью самостоятельные компиляторы. Некто Drew DeVault написал для своего Hare компилятор в одиночку, и это уже полностью рабочий язык – меньше чем за год, если я не ошибаюсь, а ведь язык не из самых примитивных, примерно уровня гошки.

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

Ты кретин. Тебе уже много раз привели в пример Boost.Variant и объяснили, что это реализуется с С++98 – нужны лишь шаблоны и перегрузка.

Ты поехавший. Даже я так плюсы не решился бы обосрать

Это был даже не С++, а С с классами – а задача уже решалась.

со мной, что писать придётся одно и то же число строчек,

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

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

Представь, что на 1 увеличивается не N, а M.

Только с енумами/вариантами это будет локально, а с наследованием - куча строчек по всем файлам.

Бред. При соблюдении правил классического ООП код класса будет инкапсулирован, что по определению исключает «кучу строчек по всем файлам».

Когда ты ссылаешься на авторитет Царя,

Ты кретин. Я ссылаюсь на сообщение, а не на авторитет, о чем явно написано в цитате, которую ты же и приводишь.

Если ты не заметил, я ссылался не на их «авторитет», а на их сообщения,