Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.07.29;
Скачать: [xml.tar.bz2];

Вниз

Class vs Record   Найти похожие ветки 

 
Ega23 ©   (2007-06-28 14:39) [0]

пишу компонент. Каждый item представляет из себя структуру с несколькими свойствами (около 5, но может и расшириться). Свойства не фиксированной длины, типа стринги или вообще bitmap.
Всё-таки, как лучше организовать внутреннее хранилище этих данных - через динамический массив или определить класс TItem и держать экземпляры в TObjectList?


 
DrPass ©   (2007-06-28 14:40) [1]

Как тебе удобнее, так и организуй. "Лучше" - весьма субъективное понятие


 
clickmaker ©   (2007-06-28 14:44) [2]

массив удобен когда по индексу доступ нужен.
Если же объекты будут добавляться/удаляться часто + поиск - тогда удобней список
В списке можно и структуры хранить, не обязательно класс делать


 
Kolan ©   (2007-06-28 14:46) [3]

> определить класс TItem

Предпочтительнее.
Так как потом туда можно поместить методы. Даже если сейчас вообразить такие(методы) трудно.


 
Ega23 ©   (2007-06-28 14:48) [4]

Поиск, пожалуй, чаще будет.


> В списке можно и структуры хранить, не обязательно класс
> делать


Да достаёт меня "домики" ставить...


 
Kolan ©   (2007-06-28 14:50) [5]

> [4] Ega23 ©   (28.06.07 14:48)
> Да достаёт меня «домики» ставить&#133

А ты попробуй не ставить — будет тоже самое :) По идее компилятор их за тебя поставит.

НО! Лучьше класс, класс и еще раз класс :)


 
Сергей М. ©   (2007-06-28 14:58) [6]


> структуру с несколькими свойствами


Термин "свойство" неприменим к термину "структура".


 
StriderMan ©   (2007-06-28 14:59) [7]


> пишу компонент. Каждый item представляет из себя структуру
> с несколькими свойствами

это типа TCollection что ли?


 
Ega23 ©   (2007-06-28 15:02) [8]


> это типа TCollection что ли?


Нет, набор полей и их тип одинаков для всех Items. Просто по длине могут отличаться. Как Bitmap в структуре хранить? Это-ж гемора-то сколько!
Пожалуй на классе остановлюсь.


 
homm ©   (2007-06-28 15:05) [9]

> Это-ж гемора-то сколько!

Сколько?


 
Eraser ©   (2007-06-28 15:10) [10]

imho, надо делать списком и TItem и не заморачиваться, иначе все равно потом переделывать надо будет )


 
Ega23 ©   (2007-06-28 15:12) [11]


> Сколько?


Столько. В структуре хранить указатель на объект, при удалении элемента удалять Bitmap....
Нафиг, всё в класс запихну. Сам всё делать будет.


 
Anatoly Podgoretsky ©   (2007-06-28 15:13) [12]

> Ega23  (28.06.2007 14:39:00)  [0]

Я бы сделал два класса TItem и TItemList
Накладные расходы на классы с успехом перекроются удобностью и надежностью.


 
homm ©   (2007-06-28 15:14) [13]

Не понял.


> В структуре хранить указатель на объект
А в классе?


> при удалении элемента удалять Bitmap
Вместо Class.Destroy писать TBitamp.Destroy; делов то.


 
Ega23 ©   (2007-06-28 15:22) [14]


> Вместо Class.Destroy писать TBitamp.Destroy; делов то.


Вместо Class.Free нужно
1. Bitmap.free
2. Удалить саму структуру

А так всё в деструкторе класса будет.


 
Ega23 ©   (2007-06-28 15:27) [15]


> Я бы сделал два класса TItem и TItemList


TItemList = classs (TList)?

А чем готовый TObjectList хуже? Много мусора лишнего?


 
P   (2007-06-28 15:37) [16]


>
> Ega23 ©   (28.06.07 14:39)
>
> пишу компонент. Каждый item представляет из себя структуру
> с несколькими свойствами (около 5, но может и расшириться).
>  Свойства не фиксированной длины, типа стринги или вообще
> bitmap.
> Всё-таки, как лучше организовать внутреннее хранилище этих
> данных - через динамический массив или определить класс
> TItem и держать экземпляры в TObjectList?


Классы удобнее, хотя и некоторых случаях занимают больше в 4-8 раз больше в памяти.  Но если бы я там(в модуле) использовал структуру, то через некоторое время не только кто-то другой, но и я бы перестал понимать что же там происходит в коде.


 
homm ©   (2007-06-28 15:46) [17]

А на форуме недавно открылся раздел «Основной», слышал? ;)


 
Anatoly Podgoretsky ©   (2007-06-28 15:50) [18]

> Ega23  (28.06.2007 14:48:04)  [4]

Индексное свойство, а сам список может быть и сортированым


 
Anatoly Podgoretsky ©   (2007-06-28 15:53) [19]

> Ega23  (28.06.2007 15:27:15)  [15]

В своем классе можешь делать любые специазированные свойства и методы, ориентированые на твой TItem
Можно еще и так

TItemList = classs (TObjectList )?


 
Anatoly Podgoretsky ©   (2007-06-28 15:54) [20]

> homm  (28.06.2007 15:46:17)  [17]

Тут больше подходит "Для начинающих"


 
Ega23 ©   (2007-06-28 15:55) [21]


> В своем классе можешь делать любые специазированные свойства
> и методы, ориентированые на твой TItem
> Можно еще и так
>
> TItemList = classs (TObjectList )?


а-а-а... В этом смысле...
Всё, понял. Спасибо.


 
Ega23 ©   (2007-06-28 15:55) [22]


> Тут больше подходит "Для начинающих"


Тут нет конкретного вопроса, поэтому сюда и закинул.


 
Kolan ©   (2007-06-28 16:36) [23]

> TItemList = class (TObjectList)?
>
> А чем готовый TObjectList хуже? Много мусора лишнего?

Я бы тоже так сдела и делаю&#133

А чем готовый TObjectList хуже?

Собсно посмотри на TObjectList и спроси себя — Чем TList хуже?

Термин «свойство» неприменим к термину «структура».
Гхм,  применимо собссно :)

TMyRecord = record
 private
   FMyParam: Integer;
 public
   property MyParam: Integer read FMyParam write FMyParam;
 end;


 
Ega23 ©   (2007-06-28 16:39) [24]


> Собсно посмотри на TObjectList и спроси себя — Чем TList
> хуже?


Тем, что в TList всё-таки Pointer хранится, а в TObjectList - TObject.
Ну и Clear лениво переписывать...  :)


 
Kolan ©   (2007-06-28 16:46) [25]

Тем, что в TList всё-таки Pointer хранится, а в TObjectList — TObject.
Ну тогда мой ответ на:
> А чем готовый TObjectList хуже?


Тем, что в TList всё-таки TObject хранится, а в TItemList — TItem.

ЗЫ
 Так имхо удобнее :) Да и в простейшем случае переписать надо только св-во Items и два метода доступа. И Add. Остальное обычно не нужно.


 
Kolan ©   (2007-06-28 16:47) [26]

Тем, что в TObjectList всё-таки TObject хранится, а в TItemList  — TItem.

Описочка&#133


 
Ega23 ©   (2007-06-28 16:49) [27]


> ЗЫ
>  Так имхо удобнее :) Да и в простейшем случае переписать
> надо только св-во Items и два метода доступа. И Add. Остальное
> обычно не нужно.


Да я уже так и сделал. Там add сразу с сортировкой получется...


 
Kolan ©   (2007-06-28 16:52) [28]

> Там add сразу с сортировкой получется&#133

разве, хм&#133

inherited Add(Item); — уже соритрованное? Имхо не должно оно быть сразу сортированным.


 
Anatoly Podgoretsky ©   (2007-06-28 16:55) [29]

> Ega23  (28.06.2007 16:39:24)  [24]

Так если у тебя TItem класс, то полный порядок
Clear не надо переписывать, переписывать надо Destroy у TItem


 
Anatoly Podgoretsky ©   (2007-06-28 16:56) [30]

> Kolan  (28.06.2007 16:46:25)  [25]

В TList вообще то нетипизированые указатели хранятся


 
Anatoly Podgoretsky ©   (2007-06-28 16:57) [31]

> Ega23  (28.06.2007 16:49:27)  [27]

А возможность создать индексированые, ассоциативные свойства много стоит


 
Ega23 ©   (2007-06-28 16:59) [32]


> разве, хм…
>
> inherited Add(Item); — уже соритрованное? Имхо не должно
> оно быть сразу сортированным.
>


Это у TObjectList. Я же его в своём списке переопределил.


 
Суслик ©   (2007-06-29 01:41) [33]

пофигу, главное, чтобы было понятно о чем речь.
я использую разное - что захочеца в текущий момент.

но отдаю предпочтение все же классам.


 
Германн ©   (2007-06-29 02:59) [34]


> Ega23 ©   (28.06.07 15:55) [22]
>
>
> > Тут больше подходит "Для начинающих"
>
>
> Тут нет конкретного вопроса, поэтому сюда и закинул.
>

Тут нет трёпа, поэтому закинул не сюда. Но вроде не помешало :)



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

Форум: "Прочее";
Текущий архив: 2007.07.29;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.53 MB
Время: 0.055 c
15-1183142815
homm
2007-06-29 22:46
2007.07.29
Вопрос по обновлениям Windows


2-1183353933
Vasyl
2007-07-02 09:25
2007.07.29
Вставка


2-1183488789
Strate
2007-07-03 22:53
2007.07.29
Получение размера файла по его хэндлу


15-1183370524
Alkid
2007-07-02 14:02
2007.07.29
XSL eBooks - посоветуйте.


10-1134827475
TStas
2005-12-17 16:51
2007.07.29
Левое выравнивание в ячейке экселя





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский