Здравствуйте, AndrewVK, Вы писали:

MS>>Первый уровень. "Не понимаю, зачем вообще нужно это наследование".
MS>>Второй уровень. "Единственный способ написать правильную программу — это использовать наследование".
MS>>Третий уровень. "Концепция наследования — это атрофизм, не имеющий ничего общего с решаемыми задачами, и чем его меньше — тем лучше".
AVK>Четвертый уровень: "А все таки польза от наследования есть"

Нет. Как я уже сказал, четверый — это люди совсем без башни, изобретающие новые концепции, в то время, когда "все что можно было изобрести — давным давно изобретено"

ПК>>>> В т.ч. для динамического полиморфизма ошибки проявляются во время исполнения.
MS>>Именно так оно и есть. Лично для меня нет никакой разницы, падает ли приложение по GPF или по .Net exception.

AVK>А для меня есть. Видимо потому что написание серверов накладывает свой отпечаток на мировоззрение

Это я конечно же перегнул. Разница есть. В случае GPF — сразу кирдык, а при System.IndexOutOfRangeException можно хотя бы состроить хорошую мину при плохой игре.

Пристегните ремни! А то после последней катастрофы всех непристёгнутых по стенкам размазало, а все, кто был пристёгнут — сидели как живые...

Здравствуйте, McSeem2, Вы писали:

MS>Нет. Как я уже сказал, четверый — это люди совсем без башни, изобретающие новые концепции, в то время, когда "все что можно было изобрести — давным давно изобретено"

Тем не менее на практике не все так примитивно, как ты расписал.

AVK>>А для меня есть. Видимо потому что написание серверов накладывает свой отпечаток на мировоззрение

MS>Это я конечно же перегнул. Разница есть. В случае GPF — сразу кирдык, а при System.IndexOutOfRangeException можно хотя бы состроить хорошую мину при плохой игре.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Тем не менее на практике не все так примитивно, как ты расписал.

Ну я же сделал оговорку "очень-очень утрированно".

AVK>Дело не в мине. Опять ты думаешь категориями десктопов. А для сервера, если запрос завершится ошибкой, это как правило не страшно. А вот если будет GPF то все, суши весла. Если был проход по памяти дальше сервер жить не будет.

Это я просто ёрничаю (не ёрничай и ёрнут не будешь). На самом деле, конечно же, всякие там бизнес-шмизнес-логики, формочки-кнопочки — милое дело программировать. Тепло, сыро и безопасно. Все мыслимые исключения можно отловить. Включаешь круиз-контроль и отключаешь мозги (как сказал один американец о стиле вождения своих соотечественников по трассе).

Но как только дело доходит до хоть сколько-нибудь серьезных high-performance задач, как то, растеризовать карту по типу http://maps.yahoo.com (на сервере!) — вот тут уже либо безопасно но тормозно, либо же быстро, но непременно в unsafe (и уже не важно, что там — Java, C#, PHP или что еще). А разница производительности вдвое на таких задачах означает и разницу в максимальной нагрузке тоже вдвое! А железо, которое держит вдвое большую вычислительную нагрузку стоит не вдвое, а впятеро дороже. А вот здесь-то и появляюсь я на белом коне

Здравствуйте, McSeem2, Вы писали:

MS>Но как только дело доходит до хоть сколько-нибудь серьезных high-performance задач

Задача задаче рознь. Отнюдь не все high-performance задачи это числомолотилки. И отключать мозги тоже не получится. Поверь — существует масса очень сложных задач, для которых быстрое перелопачивание памяти не главное.
И вобще — не нравится мне твой снобизм. То одни товарищи тут убеждали что прикладники заведомо глупее писателей драйверов, теперь вот ты про отключение мозгов заговорил. Не стоит делать картину черно-белой. Попробуй вон к примеру решить любую задачку для януса из тех что на повестке дня, а потом мы посмотрим как ты без мозгов напрограммируешь.

Здравствуйте, AndrewVK, Вы писали:

AVK>Задача задаче рознь. Отнюдь не все high-performance задачи это числомолотилки. И отключать мозги тоже не получится. Поверь — существует масса очень сложных задач, для которых быстрое перелопачивание памяти не главное.

Верю. Я говорю об "отключении мозгов" лишь в плане опасности/безопасности при написании кода, не более того. Но мощная сермяга в моих словах присутствует, поскольку опасность/безопасность в корне меняет мировоззрение. Ну и конечно же, это вопрос личных предпочтений. Я всегда любил и люблю именно числодробительные задачи. Отсюда и только отсюда — и недоверие к C# как к универсальному языку, в том числе и для решения наукоемких задач.

AVK>И вобще — не нравится мне твой снобизм. Не стоит делать картину черно-белой. Попробуй вон к примеру решить любую задачку для януса из тех что на повестке дня, а потом мы посмотрим как ты без мозгов напрограммируешь.

Извини, Андрей — я не хотел тебя обидеть. Наверное, я просто заразился этим вирусом от некоторых собеседников в этом форуме.

AVK>То одни товарищи тут убеждали что прикладники заведомо глупее писателей драйверов, теперь вот ты про отключение мозгов заговорил.

Такие "войны" — это совершенно нормальное явление. Без него было бы скучно.
Навеяло: <b>История одного байта</b>
Вот я — примерно из этой категории. Это не хорошо и не плохо. Это просто есть.

Здравствуйте, McSeem2, Вы писали:

MS>Верю. Я говорю об "отключении мозгов" лишь в плане опасности/безопасности при написании кода, не более того.

И что тогда в этом плохого? И почему ты считаешь что это всегда будет препятствием для высокопроизводительного кода?

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

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

MS> Отсюда и только отсюда — и недоверие к C# как к универсальному языку, в том числе и для решения наукоемких задач.

Любой универсальный язык имеет границы применения. Для дотнета эти границы достаточно очевидны.

AVK>>И вобще — не нравится мне твой снобизм. Не стоит делать картину черно-белой. Попробуй вон к примеру решить любую задачку для януса из тех что на повестке дня, а потом мы посмотрим как ты без мозгов напрограммируешь.

MS>Извини, Андрей — я не хотел тебя обидеть. Наверное, я просто заразился этим вирусом от некоторых собеседников в этом форуме.

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

MS>Такие "войны" — это совершенно нормальное явление. Без него было бы скучно.

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

MS>Навеяло: <b>История одного байта</b>
MS>Вот я — примерно из этой категории. Это не хорошо и не плохо. Это просто есть.

Всего лишь свидетельство узости мышления. Ничего интересного.

Здравствуйте, AndrewVK, Вы писали:

AVK>И что тогда в этом плохого?

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

AVK>И почему ты считаешь что это всегда будет препятствием для высокопроизводительного кода?

Наверное, это перестанет быть препятствием только тогда, когда вся эта безопасность будет обеспечиваться на уровне железа. Что там говорил Gaperton про аппаратные Java-машины на майнфреймах IBM?

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

Ну, с этой точки зрения мой путь весьма крив. Я быстро проскочил стадию 1, просто перешагнул через стадию 2, надолго завис на стадии 3, побывал на стадии 5, потом — стадия 4, потом — снова 5 и в конце концов вернулся на стадию 3. Деградирую, понимашь. Но не теряю надежды, минуя стадии 4 и 5, сразу стать 6

А самый крутой консультант — знаешь какой?
Его нанимают за большие деньги, после чего подробно рассказывают что и как, кормят-поят, пляшут канкан. В конце концов, робко спрашивают — "Ну как по-вашему — есть надежда, что будет работать?" Консультант со сталью в голосе говорит "Нет!". На этом работа консультанта закончена.

MS>>Навеяло: <b>История одного байта</b>
MS>>Вот я — примерно из этой категории. Это не хорошо и не плохо. Это просто есть.

AVK>Всего лишь свидетельство узости мышления. Ничего интересного.

Точно так же я мог бы объявить и тебя в "узости мышления" и нежелании видеть красоту в чем-то другом, кроме дот-нет. Но это будет неправильно. Это не узость мышления, ты — просто иной.

Здравствуйте, McSeem2, Вы писали:

AVK>>И что тогда в этом плохого?

MS>Именно то, что позволяет халтурить.

А я называю это больше времени уделять основной задаче.

MS> Ты — высокоорганизованный и высокоморальный экземпляр. А сколько халтурщиков слетается на эту профанацию?

Халтурщики, они видишь ли, просто есть. И на чем халтурить — на С++ или C# им совершенно без разницы, уж поверь.

MS>Наверное, это перестанет быть препятствием только тогда, когда вся эта безопасность будет обеспечиваться на уровне железа. Что там говорил Gaperton про аппаратные Java-машины на майнфреймах IBM?

А у нас вот к примеру на текущем проекте все упирается совсем не в нетовский код. Или в янусе — за все тормоза тоже исключительно неуправляемый код ответственнен, тормозов из-за джита или GC еще ни разу не было.

MS>А самый крутой консультант — знаешь какой?

Знаю. Такой как я

MS>>>Навеяло: <b>История одного байта</b>
MS>>>Вот я — примерно из этой категории. Это не хорошо и не плохо. Это просто есть.

AVK>>Всего лишь свидетельство узости мышления. Ничего интересного.

MS>Точно так же я мог бы объявить и тебя в "узости мышления" и нежелании видеть красоту в чем-то другом, кроме дот-нет.

Почему? Я ведь не утверждаю что С++ годится только для дурацких программ, а настоящая элита юзает дотнет.

Здравствуйте, McSeem2, Вы писали:

MS>Нет. Как я уже сказал, четверый — это люди совсем без башни, изобретающие новые концепции, в то время, когда "все что можно было изобрести — давным давно изобретено"

О! Мудрые слова! Мне всегда импонировали люди с творчиским мироваозрением. И мне искренне жалко всех "рожденных ползать".

Здравствуйте, McSeem2, Вы писали:

MS>Просто Павел уже достиг следующей стадии просветления, пока что недоступной тебе

Ну, с твоего орлиного полета виднее.

MS> Если говорить очень-очень утрированно, то это звучит так:

MS>Первый уровень. "Не понимаю, зачем вообще нужно это наследование".
MS>Второй уровень. "Единственный способ написать правильную программу — это использовать наследование".
MS>Третий уровень. "Концепция наследования — это атрофизм, не имеющий ничего общего с решаемыми задачами, и чем его меньше — тем лучше".

Ну, жалаю благополучно добраться до первого уровня.

Здравствуйте, AndrewVK, Вы писали:

AVK>3) Отсюда для интерфейсов нужна двойная виртуальность. Разруливается это на практике обычно так:
AVK> а) Ресолвим имена методов в рантайме. Так собственно работает IDispatch. Очень гибко, но весьма медленно.
AVK> б) Для класса строится таблица соответствия индексов в vmt класса и vmt интерфейса. Собственно именно этот способ используется в дотнете. Самый быстрый способ, не требует приведения типов, но довольно проблематична реализация в компайл-тайме.
AVK> в) Для класса создается несколько VMT, по одной на каждый интерфейс. Этот способ применяется в C++ и Дельфи. Довольно быстрый, но требует определенной химии в рантайме для определения нужной VMT.

Как-то все сложно получается.
В действительности достаточно тривиальная вариация Polymorphic Inline Cache способна реализовать это наиболее простым и эффективным способом. Несколько проверок и один статический вызов, что может быть лучше.
Для случая Megamorphic call-site можно делать откат на одну из статических схем, в которой стоимость вызова постоянна для любых случаев.

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

Представим, что есть объект класса A и интерфейс IB, причем они не имеют методов с совпадающими типами и именами. Даже лучше так — пусть класс А является просто структурой данных. Чтобы оснастить экземпляр этой структуры интерфейсом IB, должна быть возможность создавать реализацию интерфейса из набора любых (свободных) функций с подходящим типом, перечисляя их явным образом. Пример:

// структура и ее экземпляр, никак не связанa с IB
struct A
{
  int data;
};

A a = { 25 };

// интерфейс, никак не связан с A
interface IB
{
  int foo() const;
  void bar(int);
};

// оснащение объекта интерфейсом - придется определить реализации функций интерфейса
int foo_impl(A const& a) { return a.data; }
void bar_impl(A& a, int i) { a.data = i; }

IB pa = ref<IB, &foo_impl, &bar_impl>(&a);

// работа через интерфейс
pa.bar(10);
int i = pa.foo();

Если вместо явного определения foo_impl/bar_impl можно было бы использовать лямбда-функции, то было бы совсем душевно. А автоматичекое создание реализации интерфейса из методов класса с подходящими типом/именем как это сделано в Хероне, является просто сокращенной записью всего этого, синтаксическим сахаром.

Таким образом, между классом и интерфейсами вклинивается еще одна независимая сущность — vtbl — реализатор (адаптер?) интерфейса. И для одного класса в принципе возможно несколько реализаций одного и того же интерфейса (несколько vtbl), хотя мне пока неясно, зачем это может понадобиться.

Здравствуйте, AndrewVK, Вы писали:

AVK>Это проходит Это тоже стадии
AVK>Стадия первая: нравится вобще что то писать
AVK>Стадия вторая: просто писать не интересно, надо писать то что не могут другие. Например хитрые драйвера, вирусы.
AVK>Стадия третья: писать всякую фигню уже не интересно, начинаешь писать то что нужно реально, но при этом так, чтобы круче чего нибудь общепринятого. Например по скорости.
AVK>Стадия четвертая: заниматься оптимизацией надоедает. Начинаешь писать фреймворки.
AVK>Стадия пятая: наконец то главным критерием становится решение задачи за минимальные сроки с максимальным качеством
AVK>Стадия шестая: становишься консультантом
А еще левелы есть? А то я уже на пятом

Здравствуйте, Костя Ещенко, Вы писали:

КЕ>

КЕ>// структура и ее экземпляр, никак не связанa с IB
КЕ>struct A
КЕ>{
КЕ>  int data;
КЕ>};

КЕ>A a = { 25 };

КЕ>// интерфейс, никак не связан с A
КЕ>interface IB
КЕ>{
КЕ>  int foo() const;
КЕ>  void bar(int);
КЕ>};
КЕ>

А чем это в принципе отличается от

struct A
{
  int data;
};

struct IB: A
{
  int foo() const;
  void bar(int);
};

? (если я все правильно понял)

Здравствуйте, c-smile, Вы писали:

КЕ>>

КЕ>>// структура и ее экземпляр, никак не связанa с IB
КЕ>>struct A
КЕ>>{
КЕ>>  int data;
КЕ>>};

КЕ>>A a = { 25 };

КЕ>>// интерфейс, никак не связан с A
КЕ>>interface IB
КЕ>>{
КЕ>>  int foo() const;
КЕ>>  void bar(int);
КЕ>>};
КЕ>>

CS>А чем это в принципе отличается от

CS>

CS>struct A
CS>{
CS>  int data;
CS>};

CS>struct IB: A
CS>{
CS>  int foo() const;
CS>  void bar(int);
CS>};
CS>

CS>? (если я все правильно понял)

Тем что у меня IB не является потомком A. IB — просто интерфейс, который можно прикрутить к любому типу без его изменения.

Здравствуйте, WolfHound, Вы писали:

WH>А еще левелы есть? А то я уже на пятом

Ага. Выход на пенсию.

Здравствуйте, VladD2, Вы писали:

VD>Ага. Выход на пенсию.
Ну вот скоро качаться будет некуда

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:

VD>>Ага. Выход на пенсию.
WH>Ну вот скоро качаться будет некуда

Не дрейфь. До 99 ещё далеко. Это только некоторые наивные люди думают, что игра кончается в первой локации первого эпизода. А на самом деле за бабой с луком огромный и опасный мир.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, c-smile, Вы писали:

CS>У автора кстати есть попытка имплементировать это в стиле boost на С++
CS>http://www.codeproject.com/cpp/retrofitpolymorphism2.asp

Также см. Boost.Interfaces.

Здравствуйте, c-smile, Вы писали:

Простите за назойливость, но такая модель давно реализована в OCaml.

class a1 = object
  method m1 y = y + 1
end;;

class a2 = object
  method m1 z = z^" tail"
  method xxx w = w/3
end;;

let f obj elem = obj#m1 elem in
  (f (new a1) 1, f (new a2) "test");; -- yields (2,"test tail")