Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  01:31[Войти] | [Зарегистрироваться]
Обсуждение темы:
Мысли об Обероне

На базарной площади довольно часто можно слышать высказывания об Обероне. Мне кажется, что на базарной площади пора появиться ветке об этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы этой системы, что полезного можно извлечь из него для программирования на Дельфи (например) и др.

Ivan

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 4531 сообщение


Ссылки по теме "Оберон" и "Компонентный паскаль"



Отслеживать это обсуждение


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Разработка препроцессора gpre для delphi\freepascal.
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • <<<... | 3831—3822 | 3821—3812 | 3811—3802 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 72


    № 3821   15-12-2005 09:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Попутно возник еще один вопрос.

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

    Пример 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;



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


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


    № 3819   15-12-2005 09:42 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3818« (AVC)
    ___________________________

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


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


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

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

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

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

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


    № 3818   15-12-2005 09:32 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3816« ()
    ___________________________

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

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

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


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


    № 3817   15-12-2005 09:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3815« (Руслан Богатырев)
    ___________________________


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


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


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


    Пока нет. :(
     AVC


    № 3816   15-12-2005 09:20 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3813« (AVC)

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

    Ну почему же.

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


    или

    VAR a*:T;



    № 3815   15-12-2005 09:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3813« (AVC)
    ___________________________

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


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

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

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

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

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




    № 3814   15-12-2005 09:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3813« (AVC)
    ___________________________

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


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


    № 3813   15-12-2005 09:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3811« (Руслан Богатырев)
    ___________________________


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

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

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

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


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


    № 3812   15-12-2005 08:52 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3810« (Сергей Перовский)
    ___________________________

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


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


    <<<... | 3831—3822 | 3821—3812 | 3811—3802 | ...>>>
    Всего сообщений в теме: 4531; страниц: 454; текущая страница: 72




    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования