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

Я ответил на все хоть сколько-то вменяемые утверждения.

Нет, ты ответил только на те, на которые было удобно написать «не нужно».

Можно было бы со мной спорить, наверное

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

Ты-то писал, но это не соответствует действительности. Полнота не проверяется даже когда ты не пишешь ветку с auto&&. А когда пишешь - ещё хуже.

Соответствует. Ты неспособен разделить полноту проверки вариантов и типизацию символьных литералов.

Вообще, я тебе привёл код

Ну давай разберем по частям тобою написанное.

Да и на самом деле хреново он это делает.

[код]

Ты в std::variant<int, float, char> записываешь символьный литерал. Символьный литерал имеет тип int. visit корректно обрабатывает вариант, в который записан int. На этом можно заканчивать. Ты – бездарность.

Оказалось, даже требование в качестве параметра неконстантной ссылки не спасёт.

Ты не понимаешь принципа работы ссылок, если ты считаешь, что она должна от чего-то спасти.

Как показала практика, я знаю кресты лучше тебя.

Ты сел в лужу только что – и многократно раньше. Rust: преобразования указателя на трейт в конкретный тип (комментарий) Rust: преобразования указателя на трейт в конкретный тип (комментарий)

факт есть факт: кресты не могут контролировать типы в варианте.

Факт есть факт: ты – бездарность.

Какая разница, претендовали ли они?

Запиши тогда python и bash в список. Они тоже не претендовали, но это ведь не важно.

Ты опять пытаешься смухлевать.

Ты ссылаешься на Александреску (ссылки я, кстати, таки не увидел) и пишешь, что он «большой авторитет». Александреску хвалит golang за его генерацию исходников. Ты согласен с ним или нет?

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

Ты сел в лужу.

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

Цитату и ссылку на сообщение.

И ты опять соврал. Я всего лишь написал правдоподобный код извлечения данных из БД.

Ты написал дерьмо. И ты снова лжешь – у тебя в твоем же коде есть s_dbAccessor, контекст операции.

Вообще, забавно как ты писал resolve(id) до того как я поймал тебя, и вдруг резко переобулся и добавил какие-то методики получения правильного «контекста».

Ты лжешь. Изначально речь шла про print, а не про resolve. Затем ты заблеял про ресолв, требующий каких-то операций с БД – и я показал, как это реализовать в полиморфном виде, не потеряв расширяемости.

Какие твои слова я переврал? Ты пишешь «не надо писать дополнительные строки».

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

Я устал повторять, сколько раз я уже писал, что это не ради написания 1x(число match’ей в проекте) строчек, а ради возможности расширять множество типов, не изменяя при этом код обработчика.

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

Я не то что бы копенгаген, но в общем слышал мнение плюсовиков, что 2003 - это минорщина

Создание С++11 – труд многих лет. Публикация стандарта – дата отсечки, тогда как сами предложения в стандарт вносились на протяжении всех лет между 03 и 11, а часть предложений – и вовсе были сформированы ранее, для 03, но в него не попали.

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

Цитату и ссылку на сообщение.

Я же пишу обратное: C++ с самого начала, с 80х предлагал решение этой проблемы. Просто решение было плохое.

Ты идиот. То, что ты называешь «решением» (наследование) вообще не является типом-суммой. Rust: преобразования указателя на трейт в конкретный тип (комментарий)

Итак, до boost::variant была ли, и если была, то какая технология, для представления ситуации «переменная может быть типа А или Б»?

Boost.Variant это просто занесение в библиотеку того, что часто использовалось. Создание Boost.Variant ничего не добавило в язык, это не является «технологией» – это просто библиотечное дополнение, реализуемое всегда существовавшими средствами. Для реализации variant достаточно массива байтов, placement new и шаблонов. Для visit – перегрузки. Это механизмы языка, существовавшие с его появления.

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

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

Не будет он никуда инкапсулирован. Ты просто добавишь абстрактный draw(XxxCanvas) в базовый класс и потом реализуешь его в потомках.

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

оказался бы несовместим

Блин, а для трейтов/match оказался совместим. Хватит вилять.

LLVM

right_security исчерпывающе ответил на твой бред.

Я ответил на все хоть сколько-то вменяемые утверждения.

Нет, ты ответил только на те, на которые было удобно написать «не нужно».

Можно было бы со мной спорить, наверное

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

Ты-то писал, но это не соответствует действительности. Полнота не проверяется даже когда ты не пишешь ветку с auto&&. А когда пишешь - ещё хуже.

Соответствует. Ты неспособен разделить полноту проверки вариантов и типизацию символьных литералов.

Вообще, я тебе привёл код

Ну давай разберем по частям тобою написанное.

Да и на самом деле хреново он это делает.

[код]

Ты в std::variant<int, float, char> записываешь символьный литерал. Символьный литерал имеет тип int. visit корректно обрабатывает вариант, в который записан int. На этом можно заканчивать. Ты – бездарность.

Оказалось, даже требование в качестве параметра неконстантной ссылки не спасёт.

Ты не понимаешь принципа работы ссылок, если ты считаешь, что она должна от чего-то спасти.

Как показала практика, я знаю кресты лучше тебя.

Ты сел в лужу только что – и многократно раньше. Rust: преобразования указателя на трейт в конкретный тип (комментарий) Rust: преобразования указателя на трейт в конкретный тип (комментарий)

факт есть факт: кресты не могут контролировать типы в варианте.

Факт есть факт: ты – бездарность.

Какая разница, претендовали ли они?

Запиши тогда python и bash в список. Они тоже не претендовали, но это ведь не важно.

Ты опять пытаешься смухлевать.

Ты ссылаешься на Александреску (ссылки я, кстати, таки не увидел) и пишешь, что он «большой авторитет». Александреску хвалит golang за его генерацию исходников. Ты согласен с ним или нет?

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

Ты сел в лужу.

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

Цитату и ссылку на сообщение.

И ты опять соврал. Я всего лишь написал правдоподобный код извлечения данных из БД.

Ты написал дерьмо. И ты снова лжешь – у тебя в твоем же коде есть s_dbAccessor, контекст операции.

Вообще, забавно как ты писал resolve(id) до того как я поймал тебя, и вдруг резко переобулся и добавил какие-то методики получения правильного «контекста».

Ты лжешь. Изначально речь шла про print, а не про resolve. Затем ты заблеял про ресолв, требующий каких-то операций с БД – и я показал, как это реализовать в полиморфном виде, не потеряв расширяемости.

Какие твои слова я переврал? Ты пишешь «не надо писать дополнительные строки».

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

Я устал повторять, сколько раз я уже писал, что это не ради написания 1x(число match’ей в проекте) строчек, а ради возможности расширять множество типов, не изменяя при этом код обработчика.

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

Я не то что бы копенгаген, но в общем слышал мнение плюсовиков, что 2003 - это минорщина

Создание С++11 – труд многих лет. Публикация стандарта – дата отсечки, тогда как сами предложения в стандарт вносились на протяжении всех лет между 03 и 11, а часть предложений – и вовсе были сформированы ранее, для 03, но в него не попали.

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

Цитату и ссылку на сообщение.

Я же пишу обратное: C++ с самого начала, с 80х предлагал решение этой проблемы. Просто решение было плохое.

Ты идиот. То, что ты называешь «решением» (наследование) вообще не является типом-суммой. Rust: преобразования указателя на трейт в конкретный тип (комментарий)

Итак, до boost::variant была ли, и если была, то какая технология, для представления ситуации «переменная может быть типа А или Б»?

Boost.Variant это просто занесение в библиотеку того, что часто использовалось. Создание Boost.Variant ничего не добавило в язык, это не является «технологией» – это просто библиотечное дополнение, реализуемое всегда существовавшими средствами. Для реализации variant достаточно массива байтов, placement new и шаблонов. Для visit – перегрузки. Это механизмы языка, существовавшие с его появления.

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

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

Не будет он никуда инкапсулирован. Ты просто добавишь абстрактный draw(XxxCanvas) в базовый класс и потом реализуешь его в потомках.

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

оказался бы несовместим

Блин, а для трейтов/match оказался совместим. Хватит вилять.

LLVM

right_security исчерпывающе ответил на твой бред.