Delphi vs C++ , Часть 1

Цитата LuckLess @ 18.10.07, 15:03

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

Лаки, буду считать, что ты пошутил... Возьми тот же CGAL. При огромных геометрических вычислениях(когда речь не о сложности фигуры, а о количестве фигур) этот оверхэд будет очень и очень ощутим...

Цитата archimed7592 @ 18.10.07, 15:07

Аналогично .

Ну поплачьте дальше А я с вас посмеюсь. Определение полиморфизма не применимо к дельфийским интерфейсам. Т.к. методы интерфейсов не переопределяются на самом деле, а реализуются. Поэтому речь идет об классах с виртуальными методами. Логика ясна?

Цитата archimed7592 @ 18.10.07, 15:07

Мишура - это GUID и reference counting сделаный по образу и подобию COM.

Вообще-то GUID и счетчик ссылок — совершенно необязательные атрибуты для интерфейсов.

Цитата archimed7592 @ 18.10.07, 15:07

Ну хорошо, подводим итог: C++ в compile-time выбросит вызов ф-ции вообще, в Delphi же будет вычислена таблица смещений, потом передана куда-то, потом из неё будет вытянут адрес по конкретному смещению и, наконец сделан вызов dummy ф-ции. Оверхэд очевиден?

Не понял каким это боком вообще? Где ты тут Dummy-функцию увидел? Мы говорили о реализации интерфейсов вообще-то.

Добавлено 18.10.07, 15:16

Цитата LuckLess @ 18.10.07, 15:08

В делфи навернякак такойже обсолютно указатель на таблицу виртуальных функций, иначе неработал бы в делфи COM.

Что-то я запутался. А от какой теории реализации интерфейсов мы изначально отталкивались? Где Alex_Forth?

Сообщение отредактировано: Smike - 19.10.07, 08:07

Цитата Smike @ 18.10.07, 15:13

Не понял каким это боком вообще? Где ты тут Dummy-функцию увидел? Мы говорили о реализации интерфейсов вообще-то.

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

Цитата archimed7592 @ 18.10.07, 15:09

Лаки, буду считать, что ты пошутил... Возьми тот же CGAL. При огромных геометрических вычислениях(когда речь не о сложности фигуры, а о количестве фигур) этот оверхэд будет очень и очень ощутим...

только что проверил. в 10 раз вызов виртуальной функции медленнее.
на таком коде

   int rezult = 0;
   for (int i = 0; i < 1000000000; ++i)
      rezult += in->GetNext ();
...
   int GetNext () //так реализован в обоих случаях.
      {
      return i_++;
      }

Это будет существенно только если программа состоит из постоянных вызовов виртуальных фукнций размеров в строчку или две! Много мелких виртуальных функций. Такого не бывает))).

Цитата Smike @ 18.10.07, 15:13

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

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

Цитата

Что-то я запутался. А от какой теории реализации интерфейсов мы изначально отталкивались? Где Alex_Forth?

Домой добирался. Теперь продлжаем

Во-первых

Цитата Smike @ 18.10.07, 12:29

Цитата archimed7592 @ 18.10.07, 12:25

Смайки, ты что, действительно думаешь, что интерфейс - это конструкция, не использующая полиморфизма(виртуальные ф-ции и иже с ними)?

В Delphi — да

Тут речь идет о том в С++ вместо интерфейса используется абстрактный класс. Т е класс с виртуальными методами.
Архимедом было высказано утверждение, что в Делфи интерфейс является ни чем иным, как аналогом обстрактного класса в С++ и, следовательно, машинный код для вызова метода ч-з интерфейс в Делфи будет подобен вызову виртуального метода в С++. Смайк с этим не согласился.

Во-вторых:

Цитата

Unit2.pas.55: Intf.Foo(100);
004564D1 BA64000000       mov edx,$00000064
004564D6 8B45FC           mov eax,[ebp-$04]
004564D9 8B08             mov ecx,[eax]
004564DB FF510C           call dword ptr [ecx+$0c]

Вычисляется адрес конкретной процедуры по фиксированному смещению.

Smike, вот не поверишь, в С++ так реализован вызов виртуальных функций.
Пример

class IBase
{
public:
virtual void foo1(int)=0;
};
 
class Derive1 : public IBase
{
volatile int x;
 
public:
virtual void foo1(int a)
{
x=a;
}
};
 
void invoke( IBase* i )
{
   i->foo1(1);
};
 
int main (int argc, char** argv)
{
 
 Derive1 impl;
 
 invoke( &impl );
 
 return 0;
}

фрагмент листинга:

 __Z6invokeP5IBase:
    pushl   %ebp
    movl    $1, %ecx
    movl    %esp, %ebp
    subl    $8, %esp
    movl    8(%ebp), %eax
    movl    (%eax), %edx
    movl    %ecx, 4(%esp)
    movl    %eax, (%esp)
    call    *(%edx)
    leave
    ret

Нет, я отлично понимаю, что интерфейс в Дельфи - это нечто такое у чего:
1. есть таблица виртуальных ф-ций(набор смещений в терминологии Смайка).
2. есть указатель(ссылка в терминологии Дельфи) на объект, в котором реализована ф-циональность данного интерфейса.

Я не совсем одупляю, чем это отличается от нижепривидённого кода...

struct IInterface
{
    virtual ~IInterface() = 0;
    virtual bool foo(int i) = 0;
};
 
class Impl
    : public IInterface
{
public:
    bool foo(int i)
    { /* ... */ }
};
 
int main()
{
    Impl *impl = new Impl();
    IInterface *interface = impl;
    impl->foo(1); // здесь мы работаем с объектом как с представителем своего класса
    interface->foo(1); // здесь мы работаем с объектом как с интерфейсом
    delete impl;
}

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

Добавлено 18.10.07, 17:13
Точнее наоборот - помимо объекта нужна ещё спец. таблица .

Цитата Smike @ 18.10.07, 11:28

По-моему все просто, понятно и логично

Это вообще не в тему

Цитата archimed7592 @ 18.10.07, 11:33

Кстати, как в Дельфи с RAII?

Не надо было этого спрашивать! теперь будут обвинять в ограниченности ума и неспособностью аккуратно писать try/catch/finally

Цитата Romkin @ 18.10.07, 11:39

Через имплементацию интерфейса.

Фи, как грубо. Во-первых, потеряется идентичность объектов (в случае множественного наследования получим один объект, а не много). Во-вторых, писать код диспетчеризации ручками — некузяво.

Цитата Romkin @ 18.10.07, 12:03

Это не костыль, просто ты объясняешь компилятору, что тебе нужно именно это.

Мысленная компиляци тоже не костыль, ты просто объясняешь компьютеру, что тебе нужно именно это.

Цитата Smike @ 18.10.07, 12:29

В Delphi — да

Вот до чего людей дельфи доводит… И еще сишников обвиняют в ограниченности…

Цитата Smike @ 18.10.07, 12:29

Integer всегда отражается разрядность архитектуры.

Да неужели? А что такое разрядность архитектуры?

Цитата Smike @ 18.10.07, 13:59

Откуда же тебе известны такие тайны Delphi-компилятора?

Достаточно прослушать курс «Языки программирования и методы трансляции», после чего все станет ясно. Без косвенного вызова в runtime тут не обойтись, потому что на момент компиляции потребителя интерфейса реализаций может и не существовать.

Цитата Smike @ 18.10.07, 15:03

Вычисляется адрес конкретной процедуры по фиксированному смещению.

Это и есть виртуальный вызов

Цитата antigen @ 18.10.07, 15:08

Всего-то 63 стандартных (плюс ещё для сокращённого набора символов всякие and, or, not, ... ) - в этом смысле C++ гораздо проще, проще него только C.

Проще лисп

дельфисты зажигают. "Я не знаю, как это реализовано, поэтому в Delphi это реализовано не так, как в C++, а правильно."

Добавлено 19.10.07, 05:33
На самом деле отсутствие множественного наследования в ObjectPascal - тяжкое наследие Turbo Pascal. И отдельное понятие interface было внедрено только для того, чтобы не отстать от паровоза - технологии COM вообще и OLE в частности.

Добавлено 19.10.07, 05:38
Другое тяжелое наследие - динамическое наследование методов с колоссальным оверхедом по времени исполнения.

Цитата Орион @ 18.10.07, 14:32

Нужно решать от какого наследоваться, какие писать руками, какие в интерфейсы заворачивать и все это лдя того чтобы смоделировать множественное наследование? оО это считается удобно?

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

Цитата Romkin @ 19.10.07, 05:48

Мсье не проектирует интерфейсы заранее?

Мсье слышал про проектирование концепций? Ах да, всё забываю, что в Дельфи нет шаблонов...

archimed7592, твое представление о реализации интерфейсов в Delphi немного не соответствует
Они реализованы практически так же эффективно, как и объекты, это внутреннее свойство языка, они исходно кроссплатформны.

Цитата trainer @ 19.10.07, 05:28

И отдельное понятие interface было внедрено только для того, чтобы не отстать от паровоза - технологии COM вообще и OLE в частности.
Другое тяжелое наследие - динамическое наследование методов с колоссальным оверхедом по времени исполнени

От так от. Вот только не надо говорить о "тяжелом наследии", когда в С++ strongly typed enums десять лет вводили. Добрались, млин. А можно еще вспомнить о name mangling!

Добавлено 19.10.07, 06:16

Цитата archimed7592 @ 19.10.07, 05:58

Мсье слышал про проектирование концепций? Ах да, всё забываю, что в Дельфи нет шаблонов...

Слышал. Наличие или отсутствие шаблонов не есть необходимое условие
И начинается все с того, что строится модель, а как ее реализовывать - это дело каждого языка в отдельности. Самое важное - знать возможности языка, и правильно их применять. В Delphi знать - проще

Цитата Romkin @ 19.10.07, 06:05

archimed7592, твое представление о реализации интерфейсов в Delphi немного не соответствует

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

Цитата Romkin @ 19.10.07, 06:05

Они реализованы практически так же эффективно, как и объекты

А кто сказал что ваши объекты реализованы эффективно? Их что, можно создавать на стеке(к примеру объект типа TForm)?

Добавлено 19.10.07, 06:20

Цитата Romkin @ 19.10.07, 06:05

Наличие или отсутствие шаблонов не есть необходимое условие

Раз ты так говоришь, то, видимо не слышал .
А какой толк в концепции, когда нет возможности создавать конкретные модели?
Ну вот есть концепция рационального числа и что? Всё равно от неё толку не будет ибо в Дельфи нет шаблонов...

Вообще, дискуссия все больше напоминает разговор слепого с глухим: слышал звон...
Как я уже говорил, любой сишник изначально уверен, что все языки и в подметки не годятся С++. Исходя из этого, он делает следующий шаг: нет других средств решить задачу, кроме имеющихся в С++. Третья итерация: если в языке X нет средства Y, следует полная уверенность, что в этом языке невозможно сделать то, что в С++ делается с помощью этого средства!
Из этого делается вывод...
Почему я не люблю сишников? Потому что большая часть из них - ламеры в любом языке, кроме своего!
Впрочем, С++ еще и располагает к юзверьству: если в Delphi, какой бы идиот ни написал исходник, его легко понять, читая с листа, в С++ этого идиота убивают сразу, а исходник выбрасывается, поскольку понять его может только компилятор, и то с трудом.
Такой процесс естественного отбора приводит к тому, что общий уровень программистов на С++ довольно высок. Но поскольку С++ достаточно объемный язык, у них просто не остается времени на изучение чего-либо другого! Впрочем, желания тоже не остается. В результате и получается некая странность: программист хороший, но намертво привязан к одному языку!

Цитата Romkin @ 19.10.07, 06:05

когда в С++ strongly typed enums десять лет вводили.

Цитата Romkin @ 19.10.07, 06:05

А можно еще вспомнить о name mangling!

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