В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Delphi & Lazarus

407 membersпожаловаться на группу
2020 February 19

ГМ

Геннадий Малинин in Delphi & Lazarus
Sergey Bodrov
Я этот этап уже проходил. Потом были таблицы больше размера оперативки и извращения с mapped file, потом вернулся к обработчикам OnData.
Так как бы) Ты чего. Я ж собственно с "OnData" и работаю. Сам сделал таблицу на основе TCustomGrid, с живой отрисовкой данных.
источник
10:42пожаловаться#1

ГМ

Геннадий Малинин in Delphi & Lazarus
Либо через DrawCell, если не просто текст
источник
10:43пожаловаться#2

ГМ

Геннадий Малинин in Delphi & Lazarus
источник
10:44пожаловаться#3

SB

Sergey Bodrov in Delphi & Lazarus
Геннадий Малинин
Так как бы) Ты чего. Я ж собственно с "OnData" и работаю. Сам сделал таблицу на основе TCustomGrid, с живой отрисовкой данных.
Ты же TList под это дело заточил. =) А он тупо хранилище указателей, а не генератор данных.
источник
10:44пожаловаться#4

ГМ

Геннадий Малинин in Delphi & Lazarus
Sergey Bodrov
Ты же TList под это дело заточил. =) А он тупо хранилище указателей, а не генератор данных.
Ну тут разные способы. В таких структурах-дженериках я храню сырые данные. Напрямую пишущиеся в таблицу
источник
10:45пожаловаться#5

ГМ

Геннадий Малинин in Delphi & Lazarus
Если конечно их не десятки тысяч. Если Их дохрена, таблица и из бд может напрямую рисовать
источник
10:46пожаловаться#6

SB

Sergey Bodrov in Delphi & Lazarus
Стандартный дельфевый TDataset хорош тем, что он не хранит данные, а является интерфейсом для работы с данными. И он не ограничен определенным количеством, через  First()/Next() он работает как итератор и может выдавать больше данных, чем влезает в память. И еще многое другое. Да, он избыточно сложный. Но и возможностей у него намного больше, чем у TList
источник
10:51пожаловаться#7

ГМ

Геннадий Малинин in Delphi & Lazarus
Sergey Bodrov
Стандартный дельфевый TDataset хорош тем, что он не хранит данные, а является интерфейсом для работы с данными. И он не ограничен определенным количеством, через  First()/Next() он работает как итератор и может выдавать больше данных, чем влезает в память. И еще многое другое. Да, он избыточно сложный. Но и возможностей у него намного больше, чем у TList
Так их сравнивать вообще нестоит)
источник
10:51пожаловаться#8

SB

Sergey Bodrov in Delphi & Lazarus
Геннадий Малинин
Так их сравнивать вообще нестоит)
Почему? Датасет ведь специально создан для работы с талицами. А TList это просто массив указателей. Даже не связный список, а непрерывный массив. Объяснить разницу?
источник
10:55пожаловаться#9

ГМ

Геннадий Малинин in Delphi & Lazarus
Эм, разницу в чем? Между связным списком и массивом? Да как бы можешь, но не мне. Я как бы понимаю. Указатель на элемент, который имеет указатель на следующий элемент, бла бла бла
источник
11:01пожаловаться#10

ГМ

Геннадий Малинин in Delphi & Lazarus
В отличии, от массива, где элементы в памяти строго по порядку
источник
11:02пожаловаться#11

SB

Sergey Bodrov in Delphi & Lazarus
Совершенно верно. Прикол в том, что добавление-удаление элементов в непрерывном массиве выполняется гораздо дольше, особенно если в массиве много элементов. И после некоторого времени возникают проблемы с фрагментацией памяти, когда суммарно памяти много, а свободного куска нужного размера нет.
источник
11:32пожаловаться#12

ГМ

Геннадий Малинин in Delphi & Lazarus
Sergey Bodrov
Совершенно верно. Прикол в том, что добавление-удаление элементов в непрерывном массиве выполняется гораздо дольше, особенно если в массиве много элементов. И после некоторого времени возникают проблемы с фрагментацией памяти, когда суммарно памяти много, а свободного куска нужного размера нет.
Ну так я и говорю, что не стоит использовать списки и выобще хранить в памяти много данных
источник
11:33пожаловаться#13

ГМ

Геннадий Малинин in Delphi & Lazarus
Будь то связные списки или массивы
источник
11:33пожаловаться#14

SB

Sergey Bodrov in Delphi & Lazarus
Менеджер памяти хорошо работает с множеством малых элементов в куче (нормальные строки, экземпляры классов, мелкие record). Но для больших кусков памяти используется отдельный аллокатор, со своими причудами.
источник
11:35пожаловаться#15

AS

Alexey Shumkin in Delphi & Lazarus
Sergey Bodrov
Читаемость - да. А размер кода под вопросом. Специализация женерика порождает новый класс под капотом. Не наследника, а копию класса.
Ну, как бы, всегда нужен баланс ...
Но, замечено (мной), те, кто пишет код в одиночку, мало уделяют внимания читаемости и поддерживаемости кода
источник
13:20пожаловаться#16

AS

Alexey Shumkin in Delphi & Lazarus
Sergey Bodrov
Я этот этап уже проходил. Потом были таблицы больше размера оперативки и извращения с mapped file, потом вернулся к обработчикам OnData.
Всякой задаче - свой инструмент
источник
13:20пожаловаться#17

ГМ

Геннадий Малинин in Delphi & Lazarus
Alexey Shumkin
Всякой задаче - свой инструмент
Ну я тоже очень давно ушёл от, например, использования TListView как юзают его обычно. Заполняя данными из списка, дублируя данные.
источник
13:22пожаловаться#18

ГМ

Геннадий Малинин in Delphi & Lazarus
Гараздо практичнее использовать виртуальные списки и тянуть данные когда нужно из единственного источника
источник
13:23пожаловаться#19

ГМ

Геннадий Малинин in Delphi & Lazarus
Плюс ко всему, можно модифицировать отображаемые данные находу
источник
13:23пожаловаться#20