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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> >   Ну я не знаю, я такого не припомню, хоть и смотрел когда-то ассемблерный код в Turbo Pascal и VP. Там, кстати все весьма прозрачно. Может это и очевидные всем тут вещи, но повторюсь. Вызов обычного метода - прямой call с одним доп. параметром. С виртуальными методами чуть сложнее: есть таблица VMT и она статическая. Вызов виртуального метода - просто переход по адресу из этой таблицы. Адрес достается по индексу.
> 
> Совершенно верно. А теперь рассмотрим случай, когда есть глубокая иерархия классов и есть объект одного из глубинных классов. Для простоты рассмотрим вызов метода этого объекта, который не перекрыт нигде в иерархии (т.е. на всех уровнях используется метод корневого класса). Каакой код мы имеем в этом случае? Находится адрес таблицы методов класса нашего объекта и из неё по индексу call-ом вызывается соответствующая подпрограмма (реализующая этот метод). А у ней своего кода нет, она толко то и делает, что находит таблицу методов своего родительского класса и точно таким же образом вызывает подпрограмму оттуда. Та подпрограмма, в свою очередь, проделывает в точности всё то же самое для вызова метода своего родителя и т.д. - аж до корня. Там выполняется что-то реальное, после чего начинается возврат ret-ами в то место, откуда всё и началось.
> Так и образуется этот безумный проход по таблицам методов всех промежуточных классов.
> 
> > Но ведь и в программе без ОО какое-то ветвление в этом месте должно быть, что бы выполнение от условий зависело.
> 
> Но там это всецело контролируется программистом и происходит только по необходимости. А тут определяется исключительно компилятором и превращается в совершенно бессмысленный и дико неэффективный код.
> 
> > Посему говорить о существенном замедлении я бы не стал. Иное дело C++ со своим множественным наследованием. Там такая простая штука с VMT не проходит.
> 
> Специально сейчас нашёл ту программу и посмотрел, на чём она написана. Внутри значится: "Borland Delphi".
> 
> > Однако, это все говорит о качестве компилятора, а не структуры языка...
> 
> Да, конечно, с языком как с абстракцией это никак не связано. Просто реализовать возможности объектно-ориентированного подхода по-другому невозможно.
> 
> > > Это можно исправить практикуемым в некоторых кругах методом: "металлической линейкой по рукам". А вот код, генерируемый компилятором, уже не исправить.
> > 
> >   А ты пробовал? И как, помогло? :)
> 
> Не пробовал. Образование не позволяло. В том смысле, что никто из тех, с кем мне приходилось работать, так не писал. (Есть подозрение, что таких в те места просто на работу не брали.)
> 
> > Кстати, а какой рецепт, если действительно много параметров? Структура? Так это и есть почти использование ОО (только без виртуальных методов)
> 
> Если это что-то сугубо вычислительное, то там большое число параметров вполне нормально и никаких отрицательных эмоций не вызывает (я сам в университете специализировался именно на численных методах решения сложных систем интегро-дифференциальных уравнений). Но в остальных случаях это, как правило, говорит о том, что программа плохо спроектирована. Значит, больше этому человеку программу делать не доверят - будет трудиться простым кодировщиком.
> 
> Проводить же такие параллели между структурами и ОО-программированием я бы не стал. Да, конечно, объект - это точно такая же структура, что и переменная-структура, только к ней ещё одна (невидимая) структурка пристёгнута - с адресами функций. Существенная же разница именно в том, кем  и когда определяется, какая именно функция будет обрабатывать данные из основной структуры. В ОО-случае это вообще зачастую возможно только во время исполнения, причём методом, описанным выше.
> 
> >>>  НЕТУ в IV явного динамического распределения памяти. Почитайте стандарт. Вот напишите-ка мне древовидную структуру произвольного размера на Фортране IV.
> >> 
> >> Я лично к фортану равнодушен, но знавал людей, писавших на нём компиляторы и не видевших в этом ничего особенного.
> > 
> >   Да не, я не против Фортрана, ни боже упоси. Я против тезиса "все козлы, кроме Фортрана".
> 
> Но в исходном предложении была просьба написать на фортране работу с деревом. А как написать нормальный компилятор (да хоть с того же фортрана) без использования деревьев - я плохо представляю. Но люди писали - и эта работа их в ужас не повергала.
> 
> > Я ведь пытаюсь понять, а что такого людям в Си, скажем не нравится в смысле "идеологии". Почему они считают, что код "непрозрачный", "глюкавый".
> 
> Слишком уж легко сделать ошибку и употребить где-то в выражении адрес переменной вместо её значения (или наоборот). А компилятор (в силу особенностей языка) пережуёт это в код и ни слова поперёк не скажет.
> Или вот работа с библиотеками (особенно чужими) - это же просто кошмар какой-то. Строго говоря, библиотек и нет вовсе - компилятор после препроцессора имеет дело просто с монолитным потоком текста. В результате то, что в одном  файле (подключённом через include) было определено с помощью define, может быть запросто угроблено в каком-то из последующих файлов - и программист об этом подозревать не будет.
> Или случай, когда в двух используемых библиотеках имеются одноимённые функции - тоже кровь попортить может.
> 
> В общем, заниматься написанием надёжных программ на подобном языке я бы не стал - здоровье дороже.

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~