Вот, что-то типа того. Вместо трех обычных можно применить один MT_Stack code_1860.txt

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

Да, поторопился я с MultiMem , как всегда прав был Galkov.
Dilma, может стоит не дублировать элементы, а сделать поддержку МТ у обычных. Ведь MT_Memory и Memory весьма схожи по функциональности и первый полностью заменяет собой второй, для MT_Memory сохранение мультипотока, состоящего из одного потока, просто частность. Думаю что можно провести аналогию и с другими элементами.

Chesh, в технологии кодогенерации Дельфи-1 один нет возможности сделать код MT_Memory менее "раздутым" для НЕ использования MT
То же самое можно сказать и про MT_Add: элемент DoData - это частный случай его использования
Вопрос: в чем провинился пользователь, использовавший ранее "классические" элементы, что внезапно они в простейших операциях вдруг начнут работать с динамической памятью, зачем-то...

А вот IndexToChanel и MT_IndexToChanel - еще и работают немного по разному...

собственно это основная проблема... Учитывая, что Memory или DoData это скахем так базовые элементы и применяются очень часто, то общая производитьность схем после введения МТ снизится на порядки.

Galkov, вот посмотри, я вроде сделал MT_Stack, интересно твое мнение об ошибках и неточностях.

-- Удалено с выходом нового релиза в Uploade --

MT_Array, вроде, уже есть. Вот MT_MT_Array еще нет, но и нужен тогда MT_ArrayRW для доступа к каждому элементу массива.

Dilma, согласен, производительность снизиться, но и создание полусотни элементов "копий" - тоже как то не очень красиво. Быть может добавление _prop_MT_enabled в существующие элеметы решит эту дилемму. А то уже MT_MT_Array появляется на горизонте
Или, возможно, прийдеться отдельний пакет делать - Delphi_MT(круто, но медленно)

Chesh, Дельфи-2 - потенциально еще круче, и быстрее, но по-труднее будет
Для пользователя 1-го уровня

Хотя возможен и еще один путь. Ввести в share процедуру isMT(_data: tData): boolean; и, как говориться, решать на месте "каким путем идти".

Смотря для каких целей. Если каждый элемент в схеме заменить, то точно будет медленно.

потруднее Delphi-2 или нет - время покажет.

Любая проверка на МТ это и есть замедление. Грубо говоря просто выберем меньшее из двух зол...

Galkov, я смотрю D2 и понимаю его суть так, что код программы создается другой программой(скриптом). Да, все классно, но если скрипт не знает точно какие данные он получит: обычные или МТ, то соответственно он должен будет сгенерить код на все \"случаи жизни\". \"Потенции\" то много, но труда разработчика элемента может и не хватить. Ладно - D2 это уже из другого раздела

Это зависит от ума разработчика CG, и сей интеллект еще не воплощен.

Получается так, что оптимизационное шаманство должно быть разделено на две независимые части: творчество CG и пользователя первого уровня.

Видимо критерий должен быть таковым: все что касается Глобальных характеристик схемы - этим занимается CG, а внутренними кодами - скрипт элемента.
А глобальные характеристики схемы скрипт должен попросту спрашивать. Скажем, сегодня для выходного события используется linked, но по большому счету надо бы точнее - это должен быть признак генерации пустого кода во ВСЕЙ подключенной ветке. Не одно и то же...
Или скрипт должен спросить (и получить правильный ответ, естественно): а нужны ли в этом потоке будут данные, которые я с трудом формирую ???
Для MT и подробностей будет больше: сколько из цепочки нужных, и к какому типу каждый используемый приводится
А CG - ответить, например: нафиг они никому не нужны, засунь их себе в ....
Умный скрипт и засунет...
А глупый - заставит прогу трудится над никому не нужными данными.

---

В общем, сейчас та ситуация, что надо серьезно и вдумчиво работать над постановочной частью профессионального варианта FTCG...
Работать, это значит и обсуждать

простейшая аналогия многомерного потока в FTCG это вот такое формирование: