Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Зачем USES разбиты на два блока? [D6]

Страницы: 1 2 >
Darlock © (2002-10-09 18:10:00)
Не подскажет ли кто зачем USES разнесены на два блока interface и implementation

Darlock (2002-10-11 15:54:00) [1]
Так вроде бы я и не ставил задачей узнать почему сделано так, а не иначе. Я хотел узнать зачем так сделанно чтобы понять
>"..как это действует."
и правильно этим пользоваться..
:))

Elbor (2002-10-11 03:22:00) [2]
"- Это детерминизм, - сказал я. Название пришло экспромтом. - Совсем просто, хотя и для избранных. Прежде всего: форма вытекает из содержания. Поэтому ... Далее: наука неизменна, следовательно, все изменяемое - ненаучно. И, наконец, все вытекает из законов природы. Вы не можете знать заранее, каковы эти законы, но, будьте уверены, они есть. Так что никто не должен спрашивать: "Почему так, а не иначе?". Вместо этого каждый обязан изучать, как это действует."
Роберт Шекли. "Координаты чудес". :)))

Digitman (2002-10-10 17:41:00) [3]
>still

как это не смешно, но - это так)))

still (2002-10-10 17:23:00) [4]

> Digitman © (10.10.02 15:59)

короче, "другое достоинство этого недостатка состоит в том, что ..." :)

Дремучий (2002-10-10 17:17:00) [5]
я так понимаю, это еще и связано с без/условнымы переходами -
компилятор компилит блоки кода которые описаны в импл. ближе друг к дружке, т.е. вызываться они будут более быстрее, а те которые в интерф. (общее) дальше - ибо на всех всеравно не угодишь. Это чисто субъктивное мнение, аргументировать не буду.
:)

Digitman (2002-10-10 15:59:00) [6]
>Darlock

Не для удобств)

Такое ограничение (или особенность - как угодно) дает однопроходному pas-компилятору преимущество перед многими 2-хпроходными компиляторами (скажем, теми же C-компиляторами) в производительности (как минимум ! и это ощутимо !)

Darlock (2002-10-10 15:13:00) [7]
Т.е. единственное что я понял что это сделано ТОЛЬКО для удобств компилятора в первую очередь и для реализации цикличности во вторую.. Я прав!?

Digitman (2002-10-10 15:10:00) [8]
>still

А причем здесь нравится / не нравится ?
Речь идет об особенностях/ограничениях конкретного компилятора работающего "в один проход".

still (2002-10-10 14:50:00) [9]
2Darlock
ну и uses в частности

Darlock (2002-10-10 14:45:00) [10]
2still

Если я правильно понял Best Before 2024, то надпись касалась секций вообще, а не ЮЗЕС в этих секциях....

still (2002-10-10 14:35:00) [11]

> Digitman © (10.10.02 14:27)

мне лично больше нравится концепция с h-файлами в C

Digitman (2002-10-10 14:27:00) [12]
>Darlock

Паскаль-компилятор в отличие от некоторых иных компиляторов (например, C) построен по однопроходной схеме. При такой схеме разрешение циклических модульных ссылок становится невозможным, если ссылки находятся в одних и тех же разделах взаимоссылающихся модулей, и связано это с порядком обработки компилятором разделов модуля : сначала идентификатор д.б. определен в разделе interface, и только после этого на него можно сослаться из другого, зависимого модуля. Иными словами - сначала компилятор обрабатывает интерфейсные разделы (и в первую очередь - секцию USES) всех модулей проекта (фиксируя определенные там идентификаторы и их типы, на которые далее возможны потенциальные ссылки), и уж затем - разделы реализаций модулей.
Встретив в разделе implementation секцию uses, компилятор ищет среди уже обработанных интерфейсных разделов нужный модуль и, в случае необнаружения, пытается произвести обработку. Когда та же самая ситуация возникает при обработке uses в interface, может возникнуть бесконечный цикл. Компилятор отслеживает такие ситуации и выдает отказ с соответствующей диагностикой.

Darlock (2002-10-10 14:12:00) [13]
Дык вот и я подумал, может чего не улавливаю...
:)

still (2002-10-10 13:34:00) [14]

> KSergey © (10.10.02 13:25)

да вот и плохо, что не #include

to Darlock
я так понял из
> Best Before 2024 (09.10.02 18:34)

это чтобы юниты лишний раз не перекомпилировать

KSergey (2002-10-10 13:25:00) [15]
Darlock (09.10.02 18:55)

По-моему, ни для чего дрегого это и не надобно. Но возможно я не улавливаю какие-то тонкости.

> still © (09.10.02 18:48)

uses - совсем не #include в Си.
Если все обойти по дереву - тогда одни и теже модули будут подключаться по кругу много раз... Этак и зацикловка случиться может ;)

Darlock (2002-10-10 11:49:00) [16]
Неуж-то никто не скажет?
Обидно..
:)

Darlock (2002-10-09 18:55:00) [17]
Best Before 2024

Судя по твоему здоровому ответу, который меня не на копейку не приблизил к ответу, я непонятно спросил...

Меня интересовал вопрос:
"Зачем (кроме возможности реализации цикличности) нужен USES в секции implementation? Ведь вместо того что бы USES модуль в implementation я могу USES модуль в interface и ничего ИМХО не изменится"

Best Before 2024 (2002-10-09 18:52:00) [18]
А что бы было в обратном случае?! Доступно все!!! По всему дереву
этих uses!
Мне кажется, правильно - сто нужно - то и юзаешь

still (2002-10-09 18:48:00) [19]
да это понятно все, что
> Because Unit1 does not appear in Prog’s uses clause, identifiers
> declared in Unit1 are not available to Prog

вопрос, почему так сделано-то криво?

Darlock (2002-10-09 18:46:00) [20]
"From Help:
Object Pascal Language Guide
Multiple and indirect unit references

...To compile a client module, the compiler needs to locate all units that the client depends on, directly or indirectly. Unless the source code for these units has changed, however, the compiler needs only their .dcu (Windows) or .dcu/.dpu (Linux) files, not their source (.pas) files.

When changes are made in the interface section of a unit, other units that depend on it must be recompiled. But when changes are made only in the implementation or other sections of a unit, dependent units don’t have to be recompiled. The compiler tracks these dependencies automatically and recompiles units only when necessary."

Помоему это немного не то про что я спрашивал. Я спрашивал про секции USES, а не про различие между interface и implimentation.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »