Скачать: CL | DM;

Использование типа object   Найти похожие ветки 

← →
goobit   (2003-05-22 18:04) [0]

Собственно интересно ваше мнение по поводу использования в проектах "устаревшего" типа object. Хотя в документации к любой версии Delphi информация по ним практически отсутствует, они обладают рядом существенных приемуществ:
- могут не содержать VMT, что позволяет делать оболочки для обычных record"ов (например для TRect)
- Если нет VMT, то объект можно создать как переменную в стеке и не заботиться о конструкторе и деструкторе, что может существенно повысить скорость.

Собственно почему ребята из Borland так активно не советуют его использовать при некоторых явных приемуществах в определенных задачах?

---

← →
DiamondShark ©   (2003-05-22 19:29) [1]

> - могут не содержать VMT, что позволяет делать оболочки
> для обычных record"ов (например для TRect)

Не понял, "оболочка" -- это как? Рекорд со статическими методами? Чем это лучше рекорда и набора глобальных процедур?


> - Если нет VMT, то объект можно создать как переменную в
> стеке и не заботиться о конструкторе и деструкторе, что
> может существенно повысить скорость.

Повысить по отношению к чему?


> Собственно почему ребята из Borland так активно не советуют
> его использовать при некоторых явных приемуществах в определенных
> задачах?

Собственно, преимуществ (опять же, перед чем?) не наблюдается. Зато наблюдается явная иизбыточность. Так что ребята из Борланд не достаточно активны, могли бы ещё в 1-2 версии это хозяйство выбросить.

---

← →
y-soft ©   (2003-05-22 20:23) [2]

Насчет выбросить это наверное рановато. Зачем отбирать у языка гибкость. Посмотрите, например, как портирована на Delphi работа с GDI+

---

← →
goobit   (2003-05-23 15:26) [3]

Для меня, например, более удобной является запись Rect1.Intersect(Rect2), а не Rect1 := IntersectRect(Rect1, Rect2). Это касается и простых обработчиков пакетов, когда данные пакета содержатся в объекте и их можно просто прочитать из потока (не заботясь о VMT).

На счет стека: нормальным путем экземпляр в стеке создать нельзя (в отличии от C++), а выделение памяти в стеке ВСЕГДА будет быстрее выделенея памяти в куче. Если создание/удаление происходит довольно часто, то даже десятки микросекуд становятся важными. Конечно, такие объекты не могут поддерживать полиморфизм (так как нельзя создать виртуальных методов), но для простых классов это не обязательно.

На мой взгляд именно выигрыш в читабельности кода не в ущерб быстродействию.

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.46 MB
Время: 0.014 c