C++ vs Delphi-Pascal. Тут в пятницу очень много наездов было, так спешу (в воскресенье:) обрадовать: строки не 256-символьные, Define/Ifdef/ifndef есть, множественное наследование есть, перегрузка операторов есть, есть и еще чего. Подробнее (+)
(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

миниатюрный аудио-видеорекордер mAVR

Отправлено Boris Barbaris 21 сентября 2003 г. 08:00

Итак,наиболее используемый в Delphi тип строки string представляет собой (физически) указатель на произвольное (до 4 ГБ) количество символов (в том числе и с кодом 0), оканчивающихся дополнительным нулем. Непосредственно перед строкой находятся: (по смещению -4) 32-битный счетчик длины и (по смещению -8) 32-битный счетчик ссылок на эту строку. Пустая строка представлена нулевым указателем. Все детали реализации скрыты от прикладного программиста и осуществляются системой в прозрачном режиме. Т.е., он просто пишет:
Button1.Caption := 'My Cool Button is ' + Edit1.Text + ' !!';
и не занимается никаким гемороем с выделением памяти под массивы символов, контролем границ, вспоминанием имени функции StrCat (или как бишь ее зовут) либо повторения заклинания " *dst++=*scr++ " в наикрутейшем цикле. То есть, вся последняя Сишная конструкция вкупе с примкнувшим к ней Шепиловым (пардон, while'ом) эквивалентна простому знаку "+" Паскаля. При этом, паскалевские строки копируются только тогда, когда действительно нужно сформировать новую строку (при присваивании происходит простое увеличение числа ссылок, в отличие от физического копирования на С), вычисление длины - элементарная операция (в отличие от пробежки по всему массиву на С), возможны символы 0 в строке (в отличие от С), нет проблем с вызовом функций, возвращающих в качестве результата строку неизвестной заранее длины (фундаментальная проблема в C-шном Windows API. Иллюстрация - попробуйте переместить рабочие файлы во вложенные каталоги с длиной пути больше 260 и покувыркайтесь - чуть ли не все программы загнутся от этого (единственный обходной маневр - по шагам вглубь делать такой каталог текущим)).
[Прежде чем писать в ответ о надъязыковых C++-костылях cout <<, перечитайте еще раз и подумайте об отличиях в реализации]
Рассмотрите, например, С-шный эквивалент паскалевского
if ((Name='Boris Barbaris') and (Time='Five''o''clock')) or (Boss='смотался') then Result:='Пора пить чай';

Эквивалентом #define/#ifdef/#ifndef/#include/#pragma являются аналогичные конструкции вида {$define ...}, причем используются только в целях условной трансляции, для констант примяняются нормальные цивилизованные конструкции (которые в C++ также появились по примеру Паскаля).

Множественное наследование легко делается через множественное наследование интерфейсов.

Перегрузка операторов тоже делается (только нахрен никому не нужна) - читайте help по типу Variant.

В С/С++/С#/С.. нет типов-диапазонов, поэтому применение switch/case практически лишено всякого смысла (никто, например, не станет перечислять все буквы от A до Z поименно, вместо компактного Паскалевского 'A'..'Z')

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

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

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

Inline в Delphi-Паскале действительно нет (что интересно - был, даже слово зарезервированное, кажется, осталось), и это, в общем, правильно. Неоднократно доказывалось, что преждевременная оптимизация программы (до запуска профайлера, без "цифр в руках") только наносит вред и 5-10% никакой роли не играют. Если есть проблемы с быстродействием, надо либо менять алгоритм (наиболее эффективное решение), либо переписывать критичный кусок на ассемблере. И то, и другое поддерживается.

Арифметический SHR. Ну, нету. А если бы понадобился ROL/ROR? Или еще какая экзотика для крутой оптимизации критичного куска? Правильно, решать проблему средствами для решения этой именно проблемы. Что СМ с успехом и сделал на встроенном асемблере.

С другой стороны, у Паскаля тоже полно недостатков. Главный (ИМХО) из них - излишняя болтливость, особенно достают эти begin - end по сравнению с компактными С-шными скобками, неудобство циклов (особенно необходимость описывать i) и неудобство порядка выполнения операций (которым Вирт занимался не иначе как с бодуна). Но, тем не менее, строгая типизация и жесткость проверок перевешивают, с моей точки зрения, эти недостатки.

Составить ответ  |||  Конференция  |||  Архив

Ответы



Перейти к списку ответов  |||  Конференция  |||  Архив  |||  Главная страница  |||  Содержание  |||  Без кадра

E-mail: info@telesys.ru