Попутно возник еще один вопрос.

Для унификации (раз договорились об Обероне, а не о КП) использовать признак экспорта на чтение (минус) не буду.

Пример 1.

TYPE T = RECORD a*, b*, с*: INTEGER END;
T1* = RECORD (T) d: INTEGER END;

Пример 2.

TYPE T = RECORD a, b, с: INTEGER END;
T1* = RECORD (T) d: INTEGER END;

Есть ли разница?

Ответ на »сообщение 3812« (AVC)
___________________________
>>>2) Допустим, мы обнаружили в каком-то библиотечном модуле ошибку. Исправили и перезагрузили -- и все дела. А в случае статической линковки надо будет перелинковать заново все включающие этот модуль программы.
Допустим Вы обнаружили в каком-то библиотечном модуле ошибку. Исправили и перезагрузили -- и все дела. И часть программ стала работать не правильно. Потому, что с их точки зрения это была "не ошибка, а особенность". Вот отсюда и возникает ад dll.
Сколько раз отлаженные программы не желали работать при переносе на другую машину, где была установлена другая версия (ИСПРАВЛЕННАЯ :o)) какой нибудь dll. Пожалуйста, дайте мне компоновщик, только тогда я буду уверен, что никто в мою программу не внесет "исправления".
Мне хватает проблем с теми dll, которые входят в стандарт Windows, мимо них работать практически невозможно. С ними работают миллионы программ и ошибки в большинстве выявлены и пофиксены. И все равно проблемы возникают. Если же эти принципы внедрить повсеместно, страшно подумать, какая наченется неразбериха.
Конечно, с точки зрения ресурсов, помодульная загрузка экономичнее. Но что будет с надежностью? 

Ответ на »сообщение 3818« (AVC)
___________________________

TYPE T1* = RECORD(T) ...  END;
или
VAR a*:T;

Да, действительно, так можно (T1 можно объявить, если T -- EXTENSIBLE).
Надо над этим подумать...

Ну в плане языка Оберон EXTENSIBLE как раз не нужно.

Вот что тогда получается:

1. Экспортируется тип, который является расширением другого (неэкспортируемого) типа, имеющего при этом экспортируемые поля.

2. Осуществляется экспорт переменной, чей тип не экспортируется. Т.е. тип был для внутреннего употребления, но стоило проэкспортировать переменную этого типа, и он (его имя) стал виден в интерфейсе.

Интересно, однако...

Ответ на »сообщение 3816« ()
___________________________

Ответ на »сообщение 3813« (AVC)

>>> Первый же вариант, похоже, смысла вообще не имеет.

Ну почему же.
TYPE T1* = RECORD(T) ...  END;
или
VAR a*:T;

Да, действительно, так можно (T1 можно объявить, если T -- EXTENSIBLE).
Надо над этим подумать...

Ответ на »сообщение 3815« (Руслан Богатырев)
___________________________


С моей точки зрения оба варианта должны были трактоваться одинаково и соответственно при снятии/установки звездочки около имени типа интерфейс бы не поменялся!


Такое решение не кажется очевидно правильным.
Поля a, b и c не имеют "корня" в символьном файле, 
поэтому не включаются в экспорт.
Намерения программиста не вполне ясны.
Возможно, лучше заставить компилятор выдавать в такой ситуации предупреждения.


Понятно теперь, к чему я вел?


Пока нет. :(

Ответ на »сообщение 3813« (AVC)

>>> Первый же вариант, похоже, смысла вообще не имеет.

Ну почему же.

TYPE T1* = RECORD(T) ...  END;

или

VAR a*:T;

Ответ на »сообщение 3813« (AVC)
___________________________

Интерфейс поменялся: тип T во втором варианте включен в интерфейс модуля.
Первый же вариант, похоже, смысла вообще не имеет.

Вот-вот. Если поля типа экспортируются, а он сам нет, что это означает? Кстати, компилятор в BlackBox (раз уж о нем стали говорить) спокойно это откомпилирует (и вариант 1, и вариант 2).

А означает (как становится понятно при использовании компилятора), что если у типа нет признака экспорта, а у его полей есть, он все равно не экспортируется (зачем тогда у полей они?).

Это всем сразу интуитивно понятно или где-то есть в описании языка? Может, я невнимательно смотрел?

С моей точки зрения оба варианта должны были трактоваться одинаково и соответственно при снятии/установки звездочки около имени типа интерфейс бы не поменялся!

Понятно теперь, к чему я вел?

Ответ на »сообщение 3813« (AVC)
___________________________

Первый же вариант, похоже, смысла вообще не имеет.

Хотя, в принципе, смысл можмно найти во всем.
Допустим, мы решили временно исключить тип T из экспорта модуля и не хотим при этом удалять экспортные метки полей (чтобы потом не забыть :)).

Ответ на »сообщение 3811« (Руслан Богатырев)
___________________________


Теперь простой пример из Оберон-2/КП:

Вариант 1.
TYPE T = RECORD a*, b*, с-: INTEGER END;

Вариант 2.
TYPE T* = RECORD a*, b*, с-: INTEGER END;

Интерфейс поменялся или нет? А если поменялся, какой смысл имеет запись варианта 1?


Интерфейс поменялся: тип T во втором варианте включен в интерфейс модуля.
Первый же вариант, похоже, смысла вообще не имеет.

Ответ на »сообщение 3810« (Сергей Перовский)
___________________________

Ответ на »сообщение 3805« (Сергей Губанов)
___________________________
Придется различать два понятия модуля: единица компиляции и единица загрузки.
В win32 среде это существенно разные вещи. Хотя никто не мешает в том же ОП вместо unit, всегда писать library и осуществлять динамическое связывание. Вот только никто так не делает. Почему? Зачем нужен компоновщик?
Компоновщик может проверить целостность проекта. Там, где кончается его поле деятельности начинается многократно описанный "ад dll".
Мне лично удобнее самому делить проект на единицы загрузки, а их в свою очередь на единицы компиляции.
Автоматизация поиска нестыковок в раздельно загружаемых модулях, это замечательно, но очень хочется иметь компоновщик.

Это на уровне отдельного EXE-шника.
А на системном уровне?
1) Дублирование кода. В каждой программе, как правило, содержатся элементы, реализующие одну и ту же функциональность. (Строковые операции, математические функции и т.д.)
2) Допустим, мы обнаружили в каком-то библиотечном модуле ошибку. Исправили и перезагрузили -- и все дела. А в случае статической линковки надо будет перелинковать заново все включающие этот модуль программы.
3) Гибкость и расширяемость программной системы отличаются на порядок. В Обероне -- добавил новый модуль (или заменил старый) и радуйся. И никакого "ада DLL", никаких мучений с OLE/COM.
4) И т.д.!! :)