Это вынужденная мера из за платности компилятора.
Скоро (надеемся ) будет другой .

и компилятор и hiasm причем.

это в смысле

это всмысле

Про МТ потоки. Почитал я тут дискуссию про название технологии. И вот что думаю. Если MT - это multi thread, что перевели как "Многомерный поток", то что же такое получается -"Многомерный поток поток" ? интересно. Что еще интереснее, познакомившись с самой технологией приходишь к выводу, что многомерность очень такая прямо одномерная, и вообще то, представляет из себя простую одномерную цепочку данных типа (T)PData. А содержит ссылку на Б, Б на С, С на D. А->B->C->D. Таким образом получается, что название технологии ни только не отражает сущности, но и вообще уводит пользователя в другую сторону. Посему, предлагаю просто переименовать в "Цепочки данных" или "Data chains" (DC).

Chesh, почему-то фраза "выдать Streeam в поток" удивления не вызывает. Хотя тоже переводится как выдать поток в поток.


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

Chesh, вообще-то thread переводится по-разному, да и multi -- не всегда "многомерный", скорее -- "много".

У меня например так

nesco, Вячеслав Я не занимаюсь переводами, да и речь вел не о том как перевести, а о понятности некоторых терминов для простого пользователя HiAsm-ом. К слову, выдержка из справки по MT_Add "Действия: doAdd Добавить данные в многомерный поток ".

Dilma, Фраза веселит но отражает сущность если понимать что есть поток Stream в Delphi и поток в HiAsm. А вот с МТ ситуация другая. Поэтому и предлагаю подумать. Почему то мне кажется очень подходящим слово "Цепочка(Chain)", даже сам символ МТ нарисован в виде трех звеньев цепочки. Пусть будет не "Цепочка Данных", а "Цепочка Потоков". А дальше зато получается все очень логично, есть цепочка(Chain) и есть звенья цепочки(Section, Link, Nexus - nesco и Вячеслав на выбор ).
--"Добавить поток в (начало/конец) цепочки потоков", "Читать первое звено цепочки".

Chesh, и как же сия логика может быть представлена в терминах пакетов на базе FTCG?

Редактировалось 3 раз(а), последний 2025-01-20 23:56:33

Chesh, в FTCG физически МТ поток предполагается реализовать ввиде N-ого количества передачи параметров в ф-цию. Т.е. с точки зрения элемента это действительно совершенно разные независимые потоки, причем к цепочкам очевидно не имеющие ни малейшего отношения. Поэтому важно сформировать у пользователя мысль о том, что МТ поток это не тип данных - протсо в рамках классической модели реализовали их именно так.

Не совсем правду ты говоришь.
Есть 2 точки зрения: интерфейс и реализация.
По идее, пользователю (2-го уровня) на второе - по барабану.

А в интерфейсном подходе - это все-таки "цепочка". Как ни крути а добавляем мы их в определенном порядке (элементы у нас такие), и аналогично - снимаем.

Собственно, точно такая же история и с нашим понятием объекта: схема (или мультик изнутри) - это определение класса объекта, а элемент (или мультик снаружи) - это конкретный экземпляр класса.

В Дельфи-1 - и реализация объектная, а в Дельфи-2 или в Fasm - чистый инлайн... Т.е., одно с другим не обязано быть связано непосредственно

Более того, есть устойчивое мнение, что ООП в интерфейсе - это очень хорошо, а в реализации - дурдом на каникулах... И разница между KOL и VCL - тому есть подтверждение.