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

D_KEY, если любых, то std::function<> само напрашивается, и это даже не костыль.

Но std::function даст оверхед в рантайме. А было бы неплохо иметь возможность указать сигнатуру для шаблонного параметра без каких-либо оберток в рантайме. Думаю, что это возможно. Но смотреться будет страшно. Хотя может достаточно будет прочекать возможность создания std::function с нужной сигнатурой из объекта данного типа.

С концептами будет возможно. Я надеюсь, иначе какие же это тогда концепты будут.

Добавлено 06.07.15, 09:52
Вообще говоря, я подозреваю, что вы оба неправильно называете подразумеваемую вами сущность. Шаблонный параметр в данном случае не нуждается в специальных проверках. И вообще, сопоставление по образцу, реализуемое частичной специализацией, решает практически все подобные "концептуальные" проблемы. Вероятно, вы имели в виду параметры шаблонных функций. Это совершенно другой случай. Для шаблонных функций частичная специализация недоступна, вместо неё получается перегрузка. И подобным образом оформленное сопоставление с образцом вызывает иной механизм: разрешение перегрузки вместо выбора специализации. Работающий на иной стадии разбора сырцов к тому же. И решена поднятая проблема может быть только на стадии линковки в лучшем случае.

Сообщение отредактировано: Qraizer - 06.07.15, 09:53

Тут D_KEY приводил ссылку на бессмысленную задачку о compile-time проверки длины векторов с длиной задаваемой в run-time, в которой тролль-хаскелист обвинял C++ в отсутствии полноценного параметрического полиморфизма.
В той задачке суть свелась, к тому, что некий рекурсивный шаблон разворачивается в C++ в бесконечную рекурсию, так как ограничение этой рекурсии было уже в рантайме, что естественно в плюсах не сработает. Но аналогичный дженерик в Java и C# компилируются успешно.
D_KEY полагает, что это такое свойство дженериков. Типа вот, чем дженерики отличаются от шаблонов. А по-моему - это просто тонкости реализации. В жабе от бесконечной рекурсии спасает type erasure, в шарпе стирания типов нет, но инстанцирование шаблонов происходит в рантайме. В Хаскеле, по-видимому, все работает из-за повальной ленивости.
Вопрос, как реализованы дженерики в Rust и будет ли там компилироваться что-то вроде такого:

template<int N>
int test(int b) {
    if(b == 0) {
        return 0;
    } else {
        return test<N + 1>(b - 1);
    }
}
 
int main() {
    test<0>(5);
}

Сообщение отредактировано: applegame - 06.07.15, 10:11

applegame, там не задачка бессмысленна, а её постановка. Нельзя в compile-time что-либо сделать с сущностями, чьи свойства определяются в run-time, можно только создать алгоритм этого чего-то. С якобы compile-time алгоритмом его не Плюсовые примеры справляются сугубо из-за подмены понятий. А с определением алгоритма шаблоны справляются куда лучше, чем дженерики, только задачу для них найти надо. Типа шаблонов выражений.

Цитата Qraizer @ 06.07.15, 10:26

applegame, там не задачка бессмысленна, а её постановка.

По мне так, задача с бессмысленной постановкой - бессмыслена.

Сообщение отредактировано: applegame - 06.07.15, 10:43

Цитата Qraizer @ 06.07.15, 10:26

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

А с ними ничего и не делается. Доказывается утверждение, что у двух векторов/списков будет одна и та же длина. А конкретное значение длины, естественно, неизвестно.

Добавлено 06.07.15, 11:04

Цитата applegame @ 06.07.15, 10:09

Тут D_KEY приводил ссылку на бессмысленную задачку о compile-time проверки длины векторов с длиной задаваемой в run-time, в которой тролль-хаскелист обвинял C++ в отсутствии полноценного параметрического полиморфизма.

Все дело в том, что шаблоны генерируют код. Сам код не является параметрически-полиморфным.

Цитата

D_KEY полагает, что это такое свойство дженериков. Типа вот, чем дженерики отличаются от шаблонов. А по-моему - это просто тонкости реализации.

Тут принципиальная разница как раз в том, что в C++(и в D?) у нас нет полиморфных типов/функций, у нас есть механизм генерации конкретных типов и функций в зависимости от параметров.
И это разница не в реализации.

Цитата D_KEY @ 06.07.15, 10:57

Доказывается утверждение, что у двух векторов/списков будет одна и та же длина. А конкретное значение длины, естественно, неизвестно.

Не доказывается, а создаётся алгоритм доказательства. Тот факт, что C# умеет в run-time делать докомпиляцию, не меняет сути тезиса о том, что понятия подменены.

Цитата D_KEY @ 06.07.15, 10:57

Все дело в том, что шаблоны генерируют код. Сам код не является параметрически-полиморфным.

Забыл добавить "исходный" к "код". Шаблон не существует после компиляции единицы трансляции ...даже не так... после конкретизации в точке инстанцирования. Всё, в этой точке его больше нет. Вот в чём отличие шарповых дженериков. Шаблоны ровно такими свойствами и наделялись, чтобы не быть адовыми дженериками. Обвинять шаблоны в невлиянии на run-time всё равно, что Джаву в наличии виртуальной машины. Или std::vector<> в копировании свойств C-массива. Шаблонный код является абсолютно полным параметрически-полиморфным, если применять те же термины к тем же фазам жизненных циклов. Автор шаблонного кода наделяет его полиморфным поведением, которое доопределяется в точке использования. Всем бобра.

Цитата D_KEY @ 06.07.15, 10:57

Все дело в том, что шаблоны генерируют код. Сам код не является параметрически-полиморфным.

Цитата D_KEY @ 06.07.15, 10:57

Тут принципиальная разница как раз в том, что в C++(и в D?) у нас нет полиморфных типов/функций, у нас есть механизм генерации конкретных типов и функций в зависимости от параметров.
И это разница не в реализации.

Не согласен. На самом деле парметрический полиморфизм существует только в головах программистов и в текстовом редакторе с искходником функции.
А по сути любой параметрический полиморфизм конвертируется в итоге в ad-hoc полиморфизм. Не думаешь же ты, что для работы, например c int и float применяется один и тот же машкод? Будь-то хваленный Хаскель или Java. Просто в C++ это явно прописано, а в всяких хаскелях спрятано под капотом.

Добавлено 06.07.15, 12:56

Цитата Qraizer @ 06.07.15, 12:53

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

Полностью согласен!

Цитата Qraizer @ 06.07.15, 12:53

Не доказывается, а создаётся алгоритм доказательства. Тот факт, что C# умеет в run-time делать докомпиляцию, не меняет сути тезиса о том, что понятия подменены.

Я тут даже не знаю какой смайлик подобрать этой цитате: . Или все сразу? D_KEY, как думаешь?

Цитата Qraizer @ 06.07.15, 12:53

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

Именно, вот в чём отличие обобщений - они не генерируют новые сущности. Шаблоны генерируют. Этот факт и позволяет сомневаться в том, что они являются реализацией параметрического полиморфизма.

Цитата applegame @ 06.07.15, 12:55

Не согласен. На самом деле парметрический полиморфизм существует только в головах программистов и в текстовом редакторе с искходником функции.

Т.е. там же, где и типы данных. А между тем Agda статически доказывает, что в программе нет деления на ноль, а в мейнстриме всё ещё неопределённое поведение и null reference exception. Так может быть среда существования чего-то ничего не говорит об этом чём-то?

Цитата applegame @ 06.07.15, 12:55

А по сути любой параметрический полиморфизм конвертируется в итоге в ad-hoc полиморфизм. Не думаешь же ты, что для работы, например c int и float применяется один и тот же машкод?

Как он там в реализации - абсолютно не важно. Потому что пример нагружает систему типов.
А так в C# обобщения реализованы вполне себе через динамический полиморфизм. И только если CLR захочет, может с'jit'ить специальный.

Добавлено 06.07.15, 13:37

Цитата D_KEY @ 06.07.15, 10:57

Тут принципиальная разница как раз в том, что в C++(и в D?) у нас нет полиморфных типов/функций, у нас есть механизм генерации конкретных типов и функций в зависимости от параметров.

Дело осталось за малым: доказать, что лучше иметь правильный параметрический полиморфизм, чем генерацию сущностей.

Сообщение отредактировано: MyNameIsIgor - 06.07.15, 13:37

Цитата Qraizer @ 06.07.15, 12:53

Не доказывается, а создаётся алгоритм доказательства.

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

Цитата

Тот факт, что C# умеет в run-time делать докомпиляцию, не меняет сути тезиса о том, что понятия подменены.

Эм. При чем тут какая-то докомпиляция?

Цитата

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

Именно. Именно то, что шаблонный тип/функция являются сущностями времени компиляции, предназначенными для генерации "настоящих" типов и "настоящих" функций, которые уже неполиморфны.

Цитата

Шаблонный код является абсолютно полным параметрически-полиморфным, если применять те же термины к тем же фазам жизненных циклов.

Шаблонный код не полиморфен уже на уровне системы типов. Вот в чем проблема(для данного примера).

Добавлено 06.07.15, 13:41

Цитата applegame @ 06.07.15, 12:55

Не согласен. На самом деле парметрический полиморфизм существует только в головах программистов и в текстовом редакторе с искходником функции.

Он существует в системе типов. Или не существует(как в С++).

Цитата

Не думаешь же ты, что для работы, например c int и float применяется один и тот же машкод? Будь-то хваленный Хаскель или Java. Просто в C++ это явно прописано, а в всяких хаскелях спрятано под капотом.

Вот у них как раз это дело реализации, а в C++ это делается в самом языке.

Добавлено 06.07.15, 13:47

Цитата MyNameIsIgor @ 06.07.15, 13:30

Цитата D_KEY @ 06.07.15, 10:57

Тут принципиальная разница как раз в том, что в C++(и в D?) у нас нет полиморфных типов/функций, у нас есть механизм генерации конкретных типов и функций в зависимости от параметров.

Дело осталось за малым: доказать, что лучше иметь правильный параметрический полиморфизм, чем генерацию сущностей.

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

Цитата D_KEY @ 06.07.15, 13:40

Не думаю, что это можно доказать. Это вопрос цены и достоинств того или другого подхода.

А по-моему, это вопрос применения инструмента. Ибо в обсуждаемом примере параметрический полиморфизм применяется для имитации зависимых типов. Получается то лажа на самом деле.

Цитата D_KEY @ 06.07.15, 13:40

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

Так вот Rust же. Ну, или я чего-то не знаю, но в любом случае они очень близко подошли.

Цитата applegame @ 06.07.15, 12:55

На самом деле парметрический полиморфизм существует только в головах программистов и в текстовом редакторе с исходником функции.

Даже более того, процедуры, циклы, типы тоже существуют только в головах программистов и в текстовом редакторе с исходником программы! All Hail Machine code!

Цитата D_KEY @ 06.07.15, 13:40

Шаблонный код не полиморфен уже на уровне системы типов.

Я не понимаю, что значит не полиморфен на уровне системы типов? Вот тебе код:

template<typename T> foo(T param)

Ты хочешь сказать, что T - это не плиморфный тип?

Цитата D_KEY @ 06.07.15, 13:40

Вот у них как раз это дело реализации, а в C++ это делается в самом языке.

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

Цитата D_KEY @ 06.07.15, 13:40

Эм. При чем тут какая-то докомпиляция?

Потому что шарп тоже генерит для каждого типа свой код как и плюсы. Только шарп это делает run-time, а плюсы compile-time.

Цитата MyNameIsIgor @ 06.07.15, 13:55

Так вот Rust же. Ну, или я чего-то не знаю, но в любом случае они очень близко подошли.

И в Rust такая вот фигня скомпилится?

template<int N>
int test(int b) {
  if(b == 0) {
    return 0;
  } else {
    return test<N + 1>(b - 1);
  }
}
    
int main() {
   test<0>(5);
}

Цитата applegame @ 06.07.15, 14:10

Я не понимаю, что значит не полиморфен на уровне системы типов? Вот тебе код:

template<typename T> foo(T param)

Ты хочешь сказать, что T - это не плиморфный тип?

Эм... Конечно не полиморфный. А foo - неполиморфная функция, потому, что это вообще не функция.