trait + impl vs class , навеяно Rust'ом

Цитата MyNameIsIgor @ 07.07.15, 11:23

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

Рассуждать да, бессмысленно. Там все всегда полиморфно. Просто korvin зачем-то вспомнил про похапе.

Цитата applegame @ 07.07.15, 11:14

Все зависит от того как эта функция будет определена в точке вызова/инстанцирования шаблона.

И именно поэтому это не параметрический полиморфизм

Цитата

Using parametric polymorphism, a function or a data type can be written generically so that it can handle values identically without depending on their type

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

Цитата

bar тут совсем не причем. Полиморфность функции bar никак не влияет на полиморфность foo.

Чем докажешь?

Цитата D_KEY @ 06.07.15, 23:22

Но вывод там в том, что на C++ такую проверку сделать нельзя. И ведь действительно нельзя.

Можно.

Добавлено 07.07.15, 14:22

Цитата D_KEY @ 07.07.15, 11:07

Так получается, что вот тут:

template<typename T>
void foo(T a)
{
    bar(a);
}

мы не можем сказать, есть ли тут параметрический полиморфизм. Ведь мы не знаем, будет ли специализация. Более того, мы не знаем, что за bar у нас тут Тут же будет учтена перегрузка, так? А ведь это не параметрический полиморфизм.

struct A
{
  virtual void f() const { std::cout << "I'm A::f()" << std::endl; }
};
 
struct B: A
{
  virtual void f() const { std::cout << "I'm B::f()" << std::endl; }
};
 
void foo(const A& a)
{
  a.f();
  a.A::f();     // внезапно испаряющийся динамический полиморфизм
}
 
int main()
{
  foo(B());
}

Добавлено 07.07.15, 14:27
В C++ нет динамического полиморфизма, потому что A не знает, будет ли кто-нибудь явно квалифицировать метод f() маршрутом к A. Всё правильно, D_KEY?

Добавлено 07.07.15, 14:30
P.S. Перегрузка – это вообще мультиметоды, только статически полиморфные. За динамическими мультиметодами добро пожаловать в C++ Общие, я там темку создавал.

Сообщение отредактировано: Qraizer - 07.07.15, 14:48

Цитата Qraizer @ 07.07.15, 14:11

Цитата D_KEY @ 06.07.15, 23:22

Но вывод там в том, что на C++ такую проверку сделать нельзя. И ведь действительно нельзя.

Можно.

Покажешь?

Добавлено 07.07.15, 14:50

Цитата Qraizer @ 07.07.15, 14:11

В C++ нет динамического полиморфизма, потому что A не знает, будет ли кто-нибудь явно квалифицировать метод f() маршрутом к A. Всё правильно, D_KEY?

Неверная аналогия.

А что тут показывать? Проблема подсчитать длину списка? Или сравнить два числа? Это азы метакодирования.
Аналогия абсолютная. Полиморфизм сознательно выключен для конкретного случая. И вообще, специализации имеют весьма опосредованное отношение к полиморфизму, скорее тогда уж к его отмене. Замечу: это делает программист, и делает это сознательно, а по дефолту полиморфизм будет продолжать иметь место. К слову, явная квалификация отнюдь не обязана его отключить, можно привести примеры с множественным наследованием, когда квалификацией переключается маршрут по иерархии. В моих мультиметодах подобным образом Visitor восстанавливает динамический тип очередного позднесвязываемого параметра, только там для этого используется static_cast<>. Аналогично частичная специализация может не отменять статически полиморфное поведение, а переключить полиморфный алгоритм в другое направление.

Добавлено 07.07.15, 16:00
P.S. Внезапно всплыл термин "полиморфный алгоритм". Готовить попкорн?

Сообщение отредактировано: Qraizer - 07.07.15, 16:00

Цитата Qraizer @ 07.07.15, 15:57

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

Покажи решение данной задачи на C++.

Цитата

Аналогия абсолютная. Полиморфизм сознательно выключен для конкретного случая.

Она выключена в разных местах. В твоем примере клиент выбирает, какой вызов ему делать.

Цитата

И вообще, специализации имеют весьма опосредованное отношение к полиморфизму, скорее тогда уж к его отмене.

Цитата

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

Цитата

Замечу: это делает программист, и делает это сознательно, а по дефолту полиморфизм будет продолжать иметь место.

Я говорил не об отмене полиморфизма, я говорил об "отмене" параметрического полиморфизма(если таковой вообще был изначально). В параметрическом полиморфизме код не зависит от того, с какими данными мы работаем. А в C++ зависит. Из-за перегрузки функций и из-за специализации шаблонов.

Цитата D_KEY @ 07.07.15, 16:07

Она выключена в разных местах. В твоем примере клиент выбирает, какой вызов ему делать.

В твоём тоже. Да и в принципе я могу и в struct A выключить, не проблема добавить A::g() с вызовом A::f() внутри.
D_KEY, перегрузка и специализации ортогональны полиморфизму. Их наличие или отсутствие конкретно где-то там никак не влияют на наличие или отсутствие полиморфизма вообще.

Цитата Qraizer @ 07.07.15, 16:39

Их наличие или отсутствие конкретно где-то там никак не влияют на наличие или отсутствие полиморфизма вообще.

Цитата

Я говорил не об отмене полиморфизма, я говорил об "отмене" параметрического полиморфизма(если таковой вообще был изначально). В параметрическом полиморфизме код не зависит от того, с какими данными мы работаем. А в C++ зависит. Из-за перегрузки функций и из-за специализации шаблонов.

Добавлено 07.07.15, 17:38
Qraizer, так будет решение задачи на плюсах?

На лоре приводили решение.

Знаешь, D_KEY, я сейчас разрываюсь между следующими вариантами:

• D_KEY хочет 100500-ый раз посмотреть на 100499 раз виденные метасписки и метафункции;
• D_KEY знает, что именно он увидит, и хочет ткнуть носом в решение не той задачи, несмотря на то, что это исходно другая задача, и разница между ними коллинеарна к обсуждаемому вопросу;
• D_KEY хочет потроллить Qraizer-а тем, что у того нет на ноуте жены и коммуникаторе в роуминге никаких средств разработки, а через Крымский Wi-Fi этот пост он пытается отправить уже третий раз;
• D_KEY хочет потролить Qraizer-а тем, что ideone что-то колбасит уже 6 часов.

Свой вариант?

Сообщение отредактировано: Qraizer - 07.07.15, 21:27

Цитата applegame @ 07.07.15, 20:40

На лоре приводили решение.

Там нет подходящего решения. Тем более после усложнения.

Цитата Qraizer @ 07.07.15, 21:26

Свой вариант?

Qraizer нихрена задачу не понял и потому думает, что может её решить. А на самом деле кишка тонка.

Цитата applegame @ 07.07.15, 20:40

На лоре приводили решение.

Там вроде типы руками стирают? Это можно да(хотя... надо подумать). И что, это не проясняет для тебя мою позицию?

Qraizer какой-то другой вариант подразумевает.

Добавлено 07.07.15, 22:53

Цитата Qraizer @ 07.07.15, 21:26

Знаешь, D_KEY, я сейчас разрываюсь между следующими вариантами:

• D_KEY хочет 100500-ый раз посмотреть на 100499 раз виденные метасписки и метафункции;
• D_KEY знает, что именно он увидит, и хочет ткнуть носом в решение не той задачи, несмотря на то, что это исходно другая задача, и разница между ними коллинеарна к обсуждаемому вопросу;

Так я тебе и рассказал Зависит от.

А со сроками я не торопил, можешь хоть через пару месяцев написать

Сообщение отредактировано: D_KEY - 07.07.15, 22:57

Цитата D_KEY @ 07.07.15, 22:51

Там вроде типы руками стирают?

Да. Выше я тоже писал, что это должно помочь. Сейчас я передумал. Потому что стирание типа позволяет остановить инстанцирование, но и уничтожает тип, т.е. не позволяет во время компиляции определить, что списки одинаковой длины. На практике это сводится к тому, что если мы ошибёмся при создании обёртки из оригинальных списков, то компилятор это не поймает, а по задумке должен. Понимаешь меня?

Цитата D_KEY @ 07.07.15, 22:51

И что, это не проясняет для тебя мою позицию?

Твоя позиция мне ясна.

Добавлено 08.07.15, 06:38

Цитата MyNameIsIgor @ 08.07.15, 00:01

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

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

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

Вообще Хаскель очень красивый язык, но как кто-то точно выразился:

Цитата

Хаскель — это как ламборджини в деревне. Немного подрочил — и пошел работать на тракторе.

Сообщение отредактировано: applegame - 08.07.15, 06:41

Цитата MyNameIsIgor @ 08.07.15, 00:01

Цитата D_KEY @ 07.07.15, 22:51

Там вроде типы руками стирают?

Да. Выше я тоже писал, что это должно помочь. Сейчас я передумал. Потому что стирание типа позволяет остановить инстанцирование, но и уничтожает тип, т.е. не позволяет во время компиляции определить, что списки одинаковой длины. На практике это сводится к тому, что если мы ошибёмся при создании обёртки из оригинальных списков, то компилятор это не поймает, а по задумке должен. Понимаешь меня?

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

Добавлено 08.07.15, 07:56
applegame, не надо на haskell сворачивать. С данной задачей справляются и более слабые языки

Надо таки посмотреть, что rust скажет по этому поводу.

Сообщение отредактировано: D_KEY - 08.07.15, 07:56