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

Цитата applegame @ 08.07.15, 13:57

который по D_KEY наконец-то станет поддерживать ПП

а так же поломает совместимость, потеряет в возможностях и станет нафиг не нужным

Цитата applegame @ 08.07.15, 13:57

Если мы в стандарте C++ разрешим в некоторых случаях не генерить специализации, а выкручиваться другими способами (например затирая тип или даже интерпретируя код шаблона)

Там другие особенности полезут. Например, можно ли привести тип List<A> к List<B>, если A приводимо к B?

Цитата D_KEY @ 08.07.15, 14:00

а так же поломает совместимость, потеряет в возможностях и станет нафиг не нужным

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

Добавлено 08.07.15, 14:49

Цитата D_KEY @ 08.07.15, 13:55

Потеряв таки типобезопасность. Это не считается

Ну в жабе ты это же не засчитал как минус

Цитата D_KEY @ 08.07.15, 13:42

Этого требует спецификация языка?

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

Цитата D_KEY @ 08.07.15, 13:42

Насколько я понимаю, Rust'у ничего не мешает работать более умно. Это в языке ничего не сломает.

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

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

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

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

Там другие особенности полезут. Например, можно ли привести тип List<A> к List<B>, если A приводимо к B?

Полезут, но кто сказал, что они неразрешимы?

Добавлено 08.07.15, 14:53

Цитата DarkEld3r @ 08.07.15, 14:49

но честно говоря, сомневаюсь, что реализация (в обозримом будущем) поменяется.

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

Добавлено 08.07.15, 15:01
Фактически внутри любого (хоть как-то поддерживающего ПП) статически типизированного языка, реализацию ПП можно условно разделить на два типа: генерация специализаций и различного вида обертки. Обертки могут быть вырожденными (отсутствовать) в некоторых случаях, вроде подсчета длины списка.
Всякие хаскели по всей видимости умеют и так и эдак, так как для них ПП - неотъемлемая часть, без которой язык теряет смысл. В C++ жестко задана только генерация специализаций, в результате бесконечные рекурсии фейлятся.

ИМХО, эти ограничения не дают оснований считать, что в C++ нет ПП. Некоторые считают иначе. Полагаю спор крутится вокруг терминологии, посему предлагаю забить.
Можно сказать что в C++ "утиный" ПП: выглядит как ПП, плавает как ПП и крякает как ПП, значит вероятно, это ПП.

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

Цитата applegame @ 08.07.15, 14:50

Полезут, но кто сказал, что они неразрешимы?

Вряд ли разрешимо в C++.

Добавлено 08.07.15, 15:12

Цитата applegame @ 08.07.15, 14:04

Цитата D_KEY @ 08.07.15, 13:55

Потеряв таки типобезопасность. Это не считается

Ну в жабе ты это же не засчитал как минус

А можно ткнуть носом где в жабе потерялась типобезовасность?

Добавлено 08.07.15, 15:13

Цитата applegame @ 08.07.15, 14:50

Можно сказать что в C++ "утиный" ПП: выглядит как ПП, плавает как ПП и крякает как ПП, значит вероятно, это ПП.

Вот именно - пэпэ

Цитата MyNameIsIgor @ 08.07.15, 15:11

А можно ткнуть носом где в жабе потерялась типобезовасность?

Не уверен, что это можно считать потерей типобезопасности, но проблемы таки есть: https://en.wikipedia.org/wiki/Generics_in_J...th_type_erasure

Цитата applegame @ 08.07.15, 15:19

Не уверен, что это можно считать потерей типобезопасности, но проблемы таки есть

Там разговор идёт об этом нашем примере со списками: в C++ затирание типа приводит к потере возможности сравнения их длины. В Java я такого не вижу.

Цитата MyNameIsIgor @ 08.07.15, 15:43

Там разговор идёт об этом нашем примере со списками: в C++ затирание типа приводит к потере возможности сравнения их длины.

Нет не ведет. Затирание типов происходит ПОСЛЕ проверки длины, a точнее типов.

В общем, я решил эту задачу на D (со стиранием типов), полагаю решение должно легко портироваться на C++. Никакого говна с бесконечной генерацией типов, оно тут не нужно. Я пошел по пути хаскельного исходника, а не по неверному пути, на который умышленно или по невежеству направил постановщик задачи. Позже распишу подробнее, так как он похоже, сцуко, всех на#$ал .
Жду критики:

http://dpaste.dzfl.pl/5f9517a34d6f

import std.stdio;
import std.conv;
 
class List {
    int head;
    List tail;
    this(int head_, List tail_) {
        head = head_;
        tail = tail_;
    }
    int scalarProduct(List other) {
        return head * other.head + (tail ? tail.scalarProduct(other.tail) : 0);
    }
}
 
class ListN(int N) : List {
    this(int head, List tail) { super(head, tail); }
}
 
auto nil() { return cast(ListN!0) null; }
auto cons(int head, List tail = nil) { return new ListN!1(head, tail); }
auto cons(int N)(int head, ListN!N tail) { return new ListN!(N + 1)(head, tail); }
 
void main() {
    
    int n;
    readf("%s", &n);
    
    int main_(int M, int N)(int n, int i, ListN!N as, ListN!M bs) if(M == N) {
        return ((int n, int i, List as, List bs) {
            if(n == 0) {
                return as.scalarProduct(bs);
            } else {
                return main_(n - 1, i + 1, cons(2*i+1, as), cons(i*i, bs));
                //return main_(n - 1, i + 1, cons(2*i+1, cons(1, as)), cons(i*i, cons(2, bs))); // compiles
                //return main_(n - 1, i + 1, cons(2*i+1, as), nil);                             // fails
                //return main_(n - 1, i + 1, cons(3, cons(2*i+1, as)), cons(i*i, bs));          // fails
            }
        })(n, i, as, bs);
    }
 
 
    int calc()(int n) {
        return main_(n, 0, nil, nil);
        //return main_(n, 0, cons(2), cons(3)); // compiles
        //return main_(n, 0, nil, cons(1));     // fails
    }
    
    writeln(calc(n));
}

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

Вот это, для наглядности:

int main_(int M, int N)(int n, int i, ListN!N as, ListN!M bs) if(M == N)

Можно легко заменить на:

int main_(T)(int n, int i, T as, T bs)

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

Цитата applegame @ 08.07.15, 21:43

Жду критики

Легко.

Цитата applegame @ 08.07.15, 21:43

Позже распишу подробнее, так как он похоже, сцуко, всех на#$ал

Неа. Он, конечно, сцуко, но прав.

Сообщение отредактировано: MyNameIsIgor - 08.07.15, 22:16

Цитата D_KEY @ 08.07.15, 09:22

Я считаю, что нет, т.к. все портит специализация и перегрузка, которая делает код обобщенной функции/класса зависимым от типов-параметров, что прямо противоречит определению ПП

Не используй специализацию и/или перегрузку. Поверь на слово, это возможно. Скажу даже больше: оказывается, вполне реально не использовать квалификацию у виртуальных методов. Да-да, ей богу не вру.
D_KEY, может хватит валенком прикидываться, а?

Добавлено 08.07.15, 22:27

Цитата D_KEY @ 08.07.15, 10:34

В том-то и дело, что с ПП мне все равно, что там будет делать компилятор. А в случае с шаблонами - нет. Мне нужно знать, что зависит от параметра шаблона, а что нет, подхватит ли он нужные мне перегрузки и специализации или нет. И т.д.

Давай я открою ещё одну страшную тайну. Когда ты используешь шаблон, тебе не надо ничего этого знать. Оно само работает. Если вдруг понадобилось, значит с вероятностью 86% у тебя хреновый код или с вероятностью 14% хреновый код у автора шаблона.

Цитата MyNameIsIgor @ 08.07.15, 22:16

Легко.

Ну ты исправил само затирание, не думаю, что это по правилам.

Цитата applegame @ 08.07.15, 22:38

Цитата MyNameIsIgor @ 08.07.15, 22:16

Легко.

Ну ты исправил само затирание, не думаю, что это по правилам.

Конечно, я исправил само затирание. Я об этом и говорил выше, что при ручном затирании будет место для ошибки. И да, это по правилам - вот пишу я эту функцию main_, приходится мне ручками затирать тип, не уследил и ошибся.

Добавлено 08.07.15, 22:42
Иными словами, если инкапсулируете что-то, то это облегчит тестирование, но гарантию не даст, ибо это тоже код.

Цитата MyNameIsIgor @ 08.07.15, 22:41

Конечно, я исправил само затирание. Я об этом и говорил выше, что при ручном затирании будет место для ошибки. И да, это по правилам - вот пишу я эту функцию main_, приходится мне ручками затирать тип, не уследил и ошибся.

Ну я не знаю. Взять и исправить, грубо говоря

List ea = a;

на

List ea = пишу что захочу;

Я могу с тем же успехом заменить в Хаскельном исходнике n - 1 на n + 1 и оно уйдет в переполнение стека.

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