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

Цитата MyNameIsIgor @ 08.07.15, 13:40

Нет, не один. Ещё раз: Стандарт требует генерироваться специализации. Потому если программист не написал пользовательскую специализацию, то компилятор сгенерирует свою.

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

Цитата Qraizer @ 08.07.15, 22:52

Я наконец-то понял, в чём косяк,applegame! Эти кадры называют специализацией любую конкретизацию! Ононокак. Ты их не переубедишь. Любая машина, что с крыльями, что без, не машина, потому что внутри у каждый из экземпляров детали все с разными серийниками, и у каждой уникальный номерной знак. Не важно совершенно, что все они одной модели и серии, важно то, что любой сошедший с конвейера экземпляр отличается от чертежей конструктора, а ведь именно там, на чертеже, надписано "машина". Ты понял, да? В общем, кому ехать, а кому-то шашечки.

Да, я уже понял это. Именно так и обстоят дела.

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

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

Да. Из этого будет однозначный вывод: хаскель не может детектировать переполнение стека при компиляции (или может, но программист это не сделал - но это другая история). Но поставленную задачу - статически гарантировать обработку списком одинакового размера - он выполнил. А в C++, D и т.п. мы не гарантировали ничего: ни списков, ни стека

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

Да. Из этого будет однозначный вывод: хаскель не может детектировать переполнение стека при компиляции (или может, но программист это не сделал - но это другая история). Но поставленную задачу - статически гарантировать обработку списком одинакового размера - он выполнил. А в C++, D и т.п. мы не гарантировали ничего: ни списков, ни стека

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

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

Цитата applegame @ 08.07.15, 23:01

Ибо само заполнение к задаче имеет отношение, чуть менее, чем никакое.

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

Цитата applegame @ 08.07.15, 23:01

но ее можно переписать так, что уже не зафейлишь.

applegame, задача простая даже для C++03. Подсказать?

Цитата Qraizer @ 08.07.15, 22:52

Я наконец-то понял, в чём косяк,applegame! Эти кадры называют специализацией любую конкретизацию! Ононокак. Ты их не переубедишь.

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

Цитата ISO/IEC 14882, 14.7/4

An instantiated template specialization can be either implicitly instantiated (14.7.1) for a given argument
list or be explicitly instantiated (14.7.2). A specialization is a class, function, or class member that is either
instantiated or explicitly specialized (14.7.3).

Цитата ISO/IEC 14882, 14.7.1/1

Unless a class template specialization has been explicitly instantiated (14.7.2) or explicitly specialized (14.7.3),
the class template specialization is implicitly instantiated when the specialization is referenced in a context
that requires a completely-defined object type or when the completeness of the class type affects the semantics
of the program.

Цитата ISO/IEC 14882, 14.7.1/3

Unless a function template specialization has been explicitly instantiated or explicitly specialized, the function
template specialization is implicitly instantiated when the specialization is referenced in a context that
requires a function definition to exist.

Ну, и далее по тексту.

А теперь обращение к нормальным людям: да пусть даже инстанцирование не приводит к появлению специализаций, но чем сгенерированные при инстанцировании типы/функции отличаются от явных специализаций, который есть ad-hoc полиморфизм?

Цитата Qraizer @ 08.07.15, 22:52

В общем, кому ехать, а кому-то шашечки.

Мы тут пытаемся ехать. Кто-то нам даже обещал, что ехать получится на "азах метакодирования", но всё закончилось балабольством.

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

Ты не открыл Америку, MyNameIsIgor. Некто, то ли Вандевурд, то ли Джосаттис, запамятовал, кто из них из EDG, которая единственная в мире реализовала экспорт шаблонов, а может и оба, английским по белому возмущались непродуманностью терминологии в Стандарте, что может запутать, если не читать его очень вдумчиво. Вот прям как ты возмущались. Моя терминология, кстати, от них. Можешь их тоже причислить к ненормальным. Впрочем, есть другой вариант: почитать Стандарт вдумчиво. Просто намекну.

Цитата MyNameIsIgor @ 08.07.15, 23:20

но чем сгенерированные при инстанцировании типы/функции отличаются от явных специализаций, который есть ad-hoc полиморфизм?

Ответ есть в Стандарте. Они качественные, с кучей следствий из этого.
А своё эго можешь потешить, сказав какое-нибудь слово последним. Я не буду ничего доказывать, ни одним из четырёх способов, три из которых доступны ещё с C++03, если не ещё раньше. Ибо возвращаю:

Цитата MyNameIsIgor @ 03.07.15, 15:09

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

За сим откланиваюсь.

Добавлено 09.07.15, 00:28
P.S. Четыре – не предел.

Цитата Qraizer @ 09.07.15, 00:19

Четыре – не предел.

Вы ещё поглубже затянитесь - там и пятый с шестым подоспеют.

Qraizer, не очень понимаю, в чем смысл твоих последних постов? "Я все знаю, я все умею, а вы кадры, я вам ничего не скажу, я вам ничего не покажу, хотя знаю 42 способа". Мог бы вообще ничего не писать Иногда лучше жевать.

Добавлено 09.07.15, 07:24

Цитата Qraizer @ 08.07.15, 22:20

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

И это как-то заставит компилятор не генерировать типы и функции?

Цитата

D_KEY, может хватит валенком прикидываться, а?

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

Цитата

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

Мы говорили о написании шаблона, а не использовании его.

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

Почему я должен был бы это делать, а вы, D_KEY, нет? Вам дали определение. Вы его проигнорировали, упёршись в реализацию. Это был аргумент, что ли? Ну так динамический полиморфизм тоже реализован посредством таблицы указателей, которая к слову может быть реализована на C, и именно так и реализуется, если кому надо, значит C++ не поддерживает динамический полиморфизм? Как это опровергать, кроме как отослать к учебникам? Ты красиво воспользовались возможностью Плюсов выключить полиморфизм, в результате чего подытожил, что эта возможность означает отсутствие поддержки полиморфизма. Я честно попытался указать тебе ошибочность такой точки зрения. И что? В качестве методички по основам затронутого материала можно ознакомиться с популярным изложением матчасти, которая лежала всё это время перед вашими глазами. Потом можно будет перейти к серьёзной литературе. Можете ваше виденье критериев соответствия оставить при себе для Никонова с Мастеровым.
Что касается личностей, так это его слова были. Если он так крут, чтобы наезжать на DarkEld3r, пусть сначала сам за себя ответит. И да, я не буду сюда постить цитаты из Стандарта. Отличия размазаны по всей главе, посвящённой шаблонам, а она большая.

P.S. Один из 4-ёх вариантов могу обрисовать прям счас без всякого кода. Он настолько элементарен, что о нём легко забыть. А именно: ... ничего для контроля длины не писать. Внезапно, да? При разной длине списков код гарантировано не скомпилится. Требование выполнено.

Добавлено 09.07.15, 08:23
P.P.S. В последний раз. Шаблоны полностью отвечают затронутому вопросу. Метакод прекрасно описывается алгеброй типизированного лямбда-исчисления. Ограничения шаблонов на возможность работы только с константными сущностями, будь то значения или типы, накладывают определённые ограничения на сферу их применимости. С этим спорить некто не собирался. Метакод не может менять сущности, но может создавать новые на основе существующих. Значения-типы в частности. Так что спорить с тем, что шаблоны реализуют параметрический полиморфизм, это то же, что утверждать, мол, фронт-энд компилятор с C++ в C – это не компилятор C++. Тогда и gcc не компилятор. И clang тоже. Удачи с бобами.

Сообщение отредактировано: Qraizer - 09.07.15, 08:24

Цитата Qraizer @ 09.07.15, 08:12

Почему я должен был бы это делать, а вы, D_KEY, нет? Вам дали определение.

Из определения ПП следует отсутствие зависимости кода(исходного, а не бинарного) от параметров. В C++ эта зависимость существует(в haskell, java, c# - нет). Отсюда и требование обязательной специализации, которое и мешает решить задачу. Дженерики и полиморфные типы обеспечивают типобезопасность без специализации всего и вся(т.к. они не обеспечивают специальный полиморфизм, который обеспечивают шаблоны).

Добавлено 09.07.15, 08:54

Цитата Qraizer @ 09.07.15, 08:12

Вы его проигнорировали, упёршись в реализацию.

В том и дело, что для C++ это вопрос не реализации, а спецификации языка. Вот в случае полиморфных типов или дженериков(хотя Rust, да) это вопрос реализации, будет она в отдельных случаях что-то специализировать или нет.

Добавлено 09.07.15, 08:58

Цитата Qraizer @ 09.07.15, 08:12

Ну так динамический полиморфизм тоже реализован посредством таблицы указателей, которая к слову может быть реализована на C, и именно так и реализуется, если кому надо, значит C++ не поддерживает динамический полиморфизм?

Нет, не означает.

Цитата

Ты красиво воспользовались возможностью Плюсов выключить полиморфизм, в результате чего подытожил, что эта возможность означает отсутствие поддержки полиморфизма.

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

Цитата

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

Могу дать тот же совет тебе

Цитата

Метакод прекрасно описывается алгеброй типизированного лямбда-исчисления.

Допустим.

Цитата

Ограничения шаблонов на возможность работы только с константными сущностями, будь то значения или типы, накладывают определённые ограничения на сферу их применимости.

Да.

Цитата

Метакод не может менять сущности, но может создавать новые на основе существующих.

Да.

Цитата

Значения-типы в частности.

Ок.

Цитата

Так что спорить с тем, что шаблоны реализуют параметрический полиморфизм

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

Вторая часть марлезонского балета. Из main_ удалена лямбда и теперь она выглядит практически как в хаскельном варианте. Эта дыра закрыта для ваших шаловливых ручонок. Ищите другие дыры:

http://dpaste.dzfl.pl/3b661d65d3238

import std.stdio;
 
class Base {
    int head;
    Base tail;
    this(int head, Base tail) { this.head = head; this.tail = tail; }
}
 
class List(int N) : Base {
    this(ARGS...)(ARGS args) { super(args); }
}
 
class ListN(int N) : List!N {
    this(ARGS...)(ARGS args) { super(args); }
}
 
int scalarProduct(T)(T as, T bs) {
    if(!as) return 0;
    return as.head * bs.head + scalarProduct(as.tail, bs.tail);
}
 
auto cons(int N)(int head, List!N tail) { return new ListN!1(head, tail); }
auto cons(int N)(int head, ListN!N tail) { return new ListN!(N + 1)(head, tail); }
 
List!0 nil;
auto cons(int head) { return cons(head, nil); }
 
int main_(int N)(int n, int i, List!N as, List!N bs) {
    if(n == 0) {
        return scalarProduct(as, 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
    }
}
 
int main_(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
}
 
void main() {
    int n;
    readf("%s", &n);
    main_(n).writeln;
}

Qraizer, applegame

Тут есть параметрический полиморфизм?

class A {
public:
   virtual void foo()
   {
        // default implementation
   }
};
 
void bar(A & a)
{
    a.foo();
}

А если нет, то можете объяснить принципиальную разницу с шаблонами(в контексте нашего разговора, естественно)? Ведь ваш аргумент на счет "не специализируй" работает и тут

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

Цитата D_KEY @ 09.07.15, 08:52

Из определения ПП следует отсутствие зависимости кода(исходного, а не бинарного) от параметров. В C++ эта зависимость существует

В исходном коде???

Цитата D_KEY @ 09.07.15, 08:52

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

Реализация и спецификация не являются взаимоисключающими понятиями. Да, в спецификации C++ жестко указан способ реализации параметрического полиморфизма.

Добавлено 09.07.15, 09:27

Цитата Qraizer @ 08.07.15, 23:10

applegame, задача простая даже для C++03. Подсказать?

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

Сообщение отредактировано: applegame - 09.07.15, 09:28