Вверх ↑
Этот топик читают: Гость
Разработчик
Ответов: 26113
Рейтинг: 2126
#16: 2009-11-28 01:10:06 ЛС | профиль | цитата
Dilma писал(а):
Так что тип добавляемого поля тут является главным критерием снижения производительности

В принципе, я и имел в виду типы, под которые выделяется память. Тот же string -- это же массив символов переменной длины, под него, просто необходимо выделить участок памяти; под любую переменну, определяющую структуру, как тип record, тоже нужно выделить память и тп
карма: 22

0
Разработчик
Ответов: 4698
Рейтинг: 426
#17: 2009-11-28 21:06:00 ЛС | профиль | цитата
Dilma писал(а):
Однако за счет наличия имен можно придумать и более интересные решения.

Да, например таблица, как в sqlite code_15834.txt


Да, так я понял добавление Type возможно только в пакет FTCG, а на пакет Windows рассчитывать нельзя?
карма: 10
0
файлы: 1code_15834.txt [2.4KB] [368]
Ответов: 211
Рейтинг: 52
#18: 2009-11-29 15:38:12 ЛС | профиль | цитата
Assasin, ошибка компиляции модуля ShareMyType.pas
под D6:
"ShareMyType.pas(72) Error: Declaration of 'Data_Get' differs from previous declaration"
карма: 1
слтв
0
Разработчик
Ответов: 4698
Рейтинг: 426
#19: 2009-11-30 14:46:33 ЛС | профиль | цитата
Перезалито, а так же исправлено несколько недочетов в некоторых компонентах, Minkovsky, сейчас попробуй, должно заработать
карма: 10
1
Голосовали:Minkovsky
Администрация
Ответов: 15295
Рейтинг: 1519
#20: 2009-11-30 16:17:19 ЛС | профиль | цитата
Assasin писал(а):
Да, так я понял добавление Type возможно только в пакет FTCG, а на пакет Windows рассчитывать нельзя?

добавление возможно везде - вечь шла только о целесообразности таких элементов в рамках существующих технологий.
карма: 27
0
Разработчик
Ответов: 4698
Рейтинг: 426
#21: 2009-11-30 16:23:13 ЛС | профиль | цитата
Под "возможно" я имел ввиду целесообразно, просто из постов выше я до сих пор не пойму куда целесообразно добавить Type
карма: 10
0
Разработчик
Ответов: 4698
Рейтинг: 426
#22: 2009-12-01 20:32:52 ЛС | профиль | цитата
Теперь компоненты доступны по SVN
карма: 10
0
Ответов: 1328
Рейтинг: 69
#23: 2009-12-01 23:21:05 ЛС | профиль | цитата
в wiki адрес svn нужно поменять
карма: 2

0
Разработчик
Ответов: 4698
Рейтинг: 426
#24: 2009-12-03 20:25:55 ЛС | профиль | цитата
Добавил на svn новый компонент Type_MultiData(похож с MT_MultiData)
Добавил информацию в отладку, теперь схемы с Type можно отладывать и в окне Debug(2) будет показана информация о нем в следующей структуре Name: "<имя>" Items: {"<переменная>": <значение>}{...}{...}...
Компоненты проверены и полностью рабочие.
Так же добавлена информация о компонентах в WIKI, ее можно найти по адресу HiAsmПакетыWindowsКомпонентыРабота с типами<здесь>
рабочие примеры имеются
------------ Дoбавленo в 20.26:
Под FPC теперь тоже работает
------------ Дoбавленo в 20.35:
Я еще хелп подрисовал вот он code_15868.sha
карма: 10
4
файлы: 1type_help.sha [10.7KB] [295]
Голосовали:Poputchik, Genius, filyaxxxcom, Konst
Ответов: 211
Рейтинг: 52
#25: 2009-12-04 23:05:53 ЛС | профиль | цитата
Assasin, А почему отказались и перешли от TObj в качестве парента для TType на наследование от ТObject. Только из-за совместимости со "старым" FPC?
карма: 1
слтв
0
Разработчик
Ответов: 4698
Рейтинг: 426
#26: 2009-12-05 11:58:54 ЛС | профиль | цитата
А в чем будет преимущество? К тому же class более универсален и для FPC, как вы заметили выше, и для Delphi не надо вводить лишних {$ifdef F_P} для работы под FPC
карма: 10
0
Ответов: 211
Рейтинг: 52
#27: 2009-12-05 13:37:49 ЛС | профиль | цитата
Пойду-ка я "Книгу о КОЛ" перечту, может и к строгой иерархии наследования классов в Дельфи потянет, а там недалеко и до VCL.
Assasin писал(а):
не надо вводить лишних {$ifdef F_P}
это не надолго, в свете перехода на "новую" версию FPC
необходимость в большинстве подобных решений отпадет.
карма: 1
слтв
0
Администрация
Ответов: 15295
Рейтинг: 1519
#28: 2009-12-05 16:00:21 ЛС | профиль | цитата
Minkovsky, если говорить о кол, то вообще-то идеология этой библиотеки прямо противоположна строгой иерархии классов VCL. Поэтому ваше замечание в высшей степени странное.
Если же говорить о наследовании в стандартном пакете HiAsm, то тут у простых(не GUI) классов завязки на KOL быть не должно - это обеспечивает некоторую степень переносимости кода ввиду не зависимости от конкретных библиотек. Поясните какие плюсы дает наследование от TObj, кроме потери свободы интеграции исходников в другие среды.
карма: 27
0
Ответов: 211
Рейтинг: 52
#29: 2009-12-05 19:40:43 ЛС | профиль | цитата
Прошу прощение за странное замечание
Minkovsky писал(а):
я "Книгу о КОЛ" перечту, может и к строгой иерархии наследования классов в Дельфи потянет

здесь не более чем антитеза, с просьбой ознакомится с принципами построения библиотеки, особенно в части отказа от классов, и наследования именно от TObj, и как следствие владение одним экземпляром vmt .
В своей реализации попрежнему придерживаюсь идеи наследования от TObj для всех кроме GUI, а последние от TControl (включающий только публичные методы и свойства).
Поля и приватные методы находятся в соподчиненном(CustomObj) TObj.
карма: 1
слтв
0
Разработчик
Ответов: 4698
Рейтинг: 426
#30: 2009-12-20 18:58:30 ЛС | профиль | цитата
Добавил новые компоненты на svn:
Type_TypeMemory - копирует тип к себе в память, при очищении оригинала(источника) копия не очищается
Type_TypeCombine - комбинирует несколько типов в один, имя полученного типа будет взято с первого корректного типа, так же самостоятелен, как и Type_TypeMemory
Так же оптимизировал коды уже существующих компонентов и исправил несколько багов
карма: 10
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)