Вопрос разработчикам! Нужно создать матричный компонент для работы с разными типами данных одновременно. Есть компонент Matrix, но там "либо - либо". При этом необходимо, чтобы он совмещал возможности поиска по матрице и выборки в виде одной ячейки, либо целиком строки или столбца. Знаю, что похожую задачу можно выполнить при помощи, например SQL или с помощью компонента StringTableMT или его расширенного варианта. Но, дело в том, что мне нужно обращаться в этот массив на столько часто, что вариант с SQL сразу отпадает (т.к. скорость обращения должна быть очень высокой), а со StringTableMT и его подобием, мешает их интерфейсная часть, т.к. все обращения и изменения должны проходит внутри основного процесса молниеносно.

[flood]Я знаю про ярлык "Проект заморожен", но считаю его неуместным только потому, что проект живёт, у него есть пользователи, а значит эволюционирует и требует совершенства. Иначе быть не может. [/flood]

А плохо не станет В куплю/продам пиши, может кто и подпишется. На халяву -- увольте такое делать, да еще и с разными типами данных

ser_davkin, Внимательно читайте форум, особенно - сильно похожие на Ваши задачи, которые ставил Login, наши ответы и чем это в итоге кончилось (подсказываю: IC и самодельный FTCG). Про разнородные данные с поиском в одном массиве, конечно, лихо загнули. В общем, не Вы первый с такими идеями, и не случайно они до сих пор никем официально не реализованы.

Кстати, а чем не устраивают MT-потоки, неужели на них нельзя решить твою задачу, и все сводится к созданию компонента
------------ Дoбавленo в 10.54:

Только MT, и больше ничего
------------ Дoбавленo в 10.56:

А это вообще -- охринеть и не встать, При 100000 элементов уже молниеносно не получится, если только элемент не в начале. Если тебя не устраивает база, индексированная и заточенная на работу с большим количеством данных, то тебя ничего не спасет, даже IC

ser_davkin,А чем Вам список строк с записью всех значений через разделитель не устраивает
И еще есть вариант разбить все колонки в отдельный массив своего типа и обращаться к каждому по индексу

miver, ты внимательно прочитал

В слове "молниеносно" и есть весь цимус вопроса. Быстродействие списка с разделителями оставляет желать лучшего, даже без учета преобразования типов

ser_davkin, почему именно матрицы?
А чем не устраивают многомерные-массивы вида MyArray(10,25,68,56,458)?

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

"Паровозики" из мульти-массивов я недавно тут описывал, это по сути и есть матрицы, и данные у меня разнородные, просто я заранее разбил все данные на группы по типам, и для каждого типа свой массив, но адрес для поиска в массиве одинаковый для всего паровозика.

Есть еще в делфи структуры http://www.delphisources.ru/pages/faq/faq_delphi_basics/Record.php.html но я еще до их использования не дошел, не знаю насколько они быстрые.

Сделать это в стандартном пакете и трудно и пока некому.

---

Вот, я даже тему нашел http://forum.hiasm.com/forum.html?q=3&p=221244#p221244

Самое интересное другое -- топик стартер не озвучил главного -- какая размерность матрицы

ser_davkin, GlobalVar и свойство Name и немного фантазии = многомерный массив = матрица на все типы поддерживаемые в HiAsm

И, кстати, как я уже писал, самый лучший многомерный массив разнородных данных у нас -- это MT-поток

nesco, ну, а если забыть про быстродействие и взять к примеру тот же StringTableMT за образец, удалить в нём всё, что связано с визуализацией и графикой, оставить, то что, необходимо в работе с матрицей, тот же поиск по ней, ещё раз оптимизировать и вуаля. Или это невозможно?

ser_davkin, возможно всё, только кто возьмётся за это просто так?

Если бы это было нужно только мне. Универсальный матричный массив найдёт кучу применений.

У нас и так есть элемент Matrix. К тому же, это действительно из разряда невозможного

А мне он и нафиг не нужен, я возьму для этих целей MT-массивы и сделаю все, что мне нужно, с любыми доступными данными. К тому же, MT-массивы адаптированы под таблицу последнего типа

Ну, хорошо, а как мне в этом Matrix организовать поиск значения, снова перебором стандартными компонентами, но это снизит производительность? Отдельным компонентом было бы практичнее и быстрее.