RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Может я не прав, но..


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : Игорь Козин
Subj : Может я не прав, но..
> Ну я не знаю, я такого не припомню, хоть и смотрел когда-то ассемблерный код в Turbo Pascal и VP. Там, кстати все весьма прозрачно. Может это и очевидные всем тут вещи, но повторюсь. Вызов обычного метода - прямой call с одним доп. параметром. С виртуальными методами чуть сложнее: есть таблица VMT и она статическая. Вызов виртуального метода - просто переход по адресу из этой таблицы. Адрес достается по индексу.

Совершенно верно. А теперь рассмотрим случай, когда есть глубокая иерархия классов и есть объект одного из глубинных классов. Для простоты рассмотрим вызов метода этого объекта, который не перекрыт нигде в иерархии (т.е. на всех уровнях используется метод корневого класса). Каакой код мы имеем в этом случае? Находится адрес таблицы методов класса нашего объекта и из неё по индексу call-ом вызывается соответствующая подпрограмма (реализующая этот метод). А у ней своего кода нет, она толко то и делает, что находит таблицу методов своего родительского класса и точно таким же образом вызывает подпрограмму оттуда. Та подпрограмма, в свою очередь, проделывает в точности всё то же самое для вызова метода своего родителя и т.д. - аж до корня. Там выполняется что-то реальное, после чего начинается возврат ret-ами в то место, откуда всё и началось.
Так и образуется этот безумный проход по таблицам методов всех промежуточных классов.

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

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

> Посему говорить о существенном замедлении я бы не стал. Иное дело C++ со своим множественным наследованием. Там такая простая штука с VMT не проходит.

Специально сейчас нашёл ту программу и посмотрел, на чём она написана. Внутри значится: "Borland Delphi".

> Однако, это все говорит о качестве компилятора, а не структуры языка...

Да, конечно, с языком как с абстракцией это никак не связано. Просто реализовать возможности объектно-ориентированного подхода по-другому невозможно.

> > Это можно исправить практикуемым в некоторых кругах методом: "металлической линейкой по рукам". А вот код, генерируемый компилятором, уже не исправить.
>
> А ты пробовал? И как, помогло? :)

Не пробовал. Образование не позволяло. В том смысле, что никто из тех, с кем мне приходилось работать, так не писал. (Есть подозрение, что таких в те места просто на работу не брали.)

> Кстати, а какой рецепт, если действительно много параметров? Структура? Так это и есть почти использование ОО (только без виртуальных методов)

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

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

>>> НЕТУ в IV явного динамического распределения памяти. Почитайте стандарт. Вот напишите-ка мне древовидную структуру произвольного размера на Фортране IV.
>>
>> Я лично к фортану равнодушен, но знавал людей, писавших на нём компиляторы и не видевших в этом ничего особенного.
>
> Да не, я не против Фортрана, ни боже упоси. Я против тезиса "все козлы, кроме Фортрана".

Но в исходном предложении была просьба написать на фортране работу с деревом. А как написать нормальный компилятор (да хоть с того же фортрана) без использования деревьев - я плохо представляю. Но люди писали - и эта работа их в ужас не повергала.

> Я ведь пытаюсь понять, а что такого людям в Си, скажем не нравится в смысле "идеологии". Почему они считают, что код "непрозрачный", "глюкавый".

Слишком уж легко сделать ошибку и употребить где-то в выражении адрес переменной вместо её значения (или наоборот). А компилятор (в силу особенностей языка) пережуёт это в код и ни слова поперёк не скажет.
Или вот работа с библиотеками (особенно чужими) - это же просто кошмар какой-то. Строго говоря, библиотек и нет вовсе - компилятор после препроцессора имеет дело просто с монолитным потоком текста. В результате то, что в одном файле (подключённом через include) было определено с помощью define, может быть запросто угроблено в каком-то из последующих файлов - и программист об этом подозревать не будет.
Или случай, когда в двух используемых библиотеках имеются одноимённые функции - тоже кровь попортить может.

В общем, заниматься написанием надёжных программ на подобном языке я бы не стал - здоровье дороже.

Sat 14 Jul 2007 14:01 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) Gecko/2005



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.