Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

MyNameIsIgor, ну вот такой код скомпиль:

template<typename... T>
class A
{
public:
    template<typename T1, typename... T2>
    class B{};
private:
B<T...> b;
};
 
int main()
{
    A<int, int, int> a;
}

Цитата MyNameIsIgor @ 24.11.11, 19:17

Chrome - шуршит и не чихает

Konqueror (из KDE) тоже. Думаю это благодаря вебкиту, надо бы на Safari проверить.

Добавлено 25.11.11, 20:08

D_KEY

кстати, по поводу интерфейсов и тайпклассов: интерфейсы являются типами, и реализация интерфейса приводит к созданию субтипа, тайпклассы же типами не являются, и соответственно "реализация" тайпкласса не приводит к созданию субтипа. это весьма важное отличие =)

Сообщение отредактировано: korvin - 25.11.11, 20:13

Цитата korvin @ 25.11.11, 19:28

интерфейсы являются типами, и реализация интерфейса приводит к созданию субтипа

Гммм... А чем являются предлагаемые в C++ концепты и их реализация?

Цитата korvin @ 25.11.11, 19:28

кстати, по поводу интерфейсов и тайпклассов: интерфейсы являются типами, и реализация интерфейса приводит к созданию субтипа, тайпклассы же типами не являются, и соответственно "реализация" тайпкласса не приводит к созданию субтипа. это весьма важное отличие =)

Спасибо. Но я не говорил, что это одно и тоже сейчас.
Я тебе говорю о том, что абстрактные типы могут полностью обеспечить функциональность тайпклассов на концептуальном уровне.
И потом, если "объект" некоторого типа можно рассматривать или как "объект" поддерживающий определенный интерфейс или как соответствующий определенному тайпклассу, то какая будет разница между этими понятиями для программиста и системы типов?

ну вот смотри:

interface I {}
 
class A implements I {}
class B implements I {}
 
I[] xs = new I[] { new A(), new B }; // работает

class I a where ...
 
data A = A
data B = B
 
instance I A where ...
instance I B where ...
 
xs :: I a => [a]
xs = [A, B] -- не работает

Цитата korvin @ 25.11.11, 20:44

ну вот смотри:

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

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

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

Добавлено 25.11.11, 20:53

Цитата MyNameIsIgor @ 25.11.11, 20:50

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

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

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

Сообщение отредактировано: korvin - 25.11.11, 20:55

Цитата korvin @ 25.11.11, 20:44

ну вот смотри:
работает
...
не работает

Логично и связано с тем, на каком уровне мы работаем - уровне ограничений на динамический тип объекта или уровне ограничении на статический тип объекта.
Т.е.

concept I {};
 
List<I> f1(I obj1, I obj2)
{
    //...
}
 
template<typename T : I>
List<T> f2(T obj1, T obj2)
{
    //...
}

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

Цитата D_KEY @ 25.11.11, 20:53

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

эм... в Go нет динамических типов и субтипирования, но есть интерфейссы и они работают как типы, да еще и не требуют явной декларации реализации.

Добавлено 25.11.11, 21:00

Цитата D_KEY @ 25.11.11, 20:53

Но это не значит, что это должны быть разные сущности при объявлении.

в смысле?

Цитата D_KEY @ 25.11.11, 20:53

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

До меня дошло...

Цитата korvin @ 25.11.11, 20:50

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

Всё, теперь вопрос закрыт.

Цитата korvin @ 25.11.11, 20:50

а при чем тут утиная типизация, я не понял =/

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

interface I { void f(); }
 
class A { void f() {} }
class B { void f() {} }
 
I[] xs = new I[] { new A(), new B() }; // работает

то является ли I типом, а A и B - его под типами. Если я правильно понял объяснение D_KEY'я, то да, являются.

Цитата MyNameIsIgor @ 25.11.11, 21:01

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

interface I { void f(); }
 
class A { void f() {} }
class B { void f() {} }
 
I[] xs = new I[] { new A(), new B() }; // работает

то является ли I типом, а A и B - его под типами. Если я правильно понял объяснение D_KEY'я, то да, являются.

мм... но я не про это говорил, ну да ладно. ну вот в Go так и есть.

Цитата korvin @ 25.11.11, 20:59

эм... в Go нет динамических типов и субтипирования, но есть интерфейссы и они работают как типы, да еще и не требуют явной декларации реализации.

И это клево

Цитата

Цитата D_KEY @ 25.11.11, 20:53

Но это не значит, что это должны быть разные сущности при объявлении.

в смысле?

Смотри мой пример на гипотетическом С-подобном языке. Концепт I объявлен один раз, но используется в двух местах. Для f1 это будет "тип"(ограничитель интерфейса объекта) объекта(утиная тут могла бы быть типизация или нет - вопрос отдельный - я за утиность). Для f2 это будет интерфейс, который должен будет предоставлять для своих объектов переданный тип T.

Цитата korvin @ 25.11.11, 21:05

мм... но я не про это говорил

Я понял, что не про то. А про то, что интерфейсы это

Цитата D_KEY @ 25.11.11, 20:53

тип(еще точнее - как ограничитель объекта)

а тайпклассы

Цитата D_KEY @ 25.11.11, 20:53

ограничитель типа

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

Цитата D_KEY @ 25.11.11, 21:09

Смотри мой пример на гипотетическом С-подобном языке. Концепт I объявлен один раз, но используется в двух местах. Для f1 это будет "тип"(ограничитель интерфейса объекта) объекта(утиная тут могла бы быть типизация или нет - вопрос отдельный - я за утиность). Для f2 это будет интерфейс, который должен будет предоставлять для своих объектов переданный тип T.

и что? он в обоих случаях у тебя тип =) т.е. твой второй пример это просто аналог

List<T extends I> f2(T x, T y) {
    ...
}

Добавлено 25.11.11, 21:16

Цитата MyNameIsIgor @ 25.11.11, 21:11

и как ограничение на тип (т.е. тайпкласс или концепт), и на меня снизошло озарение

нет, не использовал =)

Цитата korvin @ 25.11.11, 21:15

и что? он в обоих случаях у тебя тип =) т.е. твой второй пример это просто аналог

List<T extends I> f2(T x, T y) {
    ...
}

Ты так и не прочитал про концепты? Нет, там нет никакого требования наследования.

Добавлено 25.11.11, 21:19

Цитата korvin @ 25.11.11, 21:15

нет, не использовал =)

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