Разработка программ и игр для ZX Spectrum на языках Оберон-семейства

[Sayman]

я вижу что с языками вы слабо знакомы, особенно с языком си.

так как это не 3ifdef’ное определение

#ifndef __BOOL
typedef unsigned int bool;
#define __BOOL
#endif
соответственно никто вам не мешает и инклуды в линухах подправить аналогичным образом. но только зачем, ведь проще обоSрать, чем понять.
вы даже не понимаете разницу между синонимом и макросом. почитайте внимательно мануал и тогда поймёте.

Плевок тут в том

плевок тут в том, что человек купив книгу и прочитав 10 или 20 страниц понимает, что такое ему не асилить и начинает на одном и другом и т.д. форумах громогласно возмущаться сложностью и навороченностью того или иного языка.
я не противник дельфи, когда то пробовал понять и изучить и паскаля и дельфи. но понял что асилить не смогу. переехал на си. однако то что изучил, помогло в дальнейшем понимать чужие исходники на паскале.
кроме того, есть ещё один момент - если нельзя "ундефить" тип, значит можно использовать тот что уже есть на той платформе, под которую портируете свой проект. в крайнем случае, никто не мешает создать свой, например uboool. это плата за портируемость. если язык не позволяет делать кроссплатформенные программы (пусть даже с какими то переделками),то у такого языка мало шансов на выживание. если, например, у такого типа как int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...

[Advertiser]

[Oleg N. Cher]

#ifndef __BOOL
typedef unsigned int bool;
#define __BOOL
#endif

Я вижу, Вы слабо вникли в высказанную мною проблему. Я ещё раз повторюсь: оба "модуля" – стандартные, править их крайне дурной тон. Я просто хотел бы воспользоваться ими одномоментно, включить их в один свой модуль сразу оба, как библиотечные, но они мешают друг другу, потому что не знают ничего друг о друге. Тут же умники придумали затычку – пространства имён. И тут же возвели её в культ. А другие умники потихоньку к ней привыкли и разучились видеть какие-то другие решения.

никто не мешает создать свой, например uboool.

Эхехе. Меня кажется не слышали. Эгей, товарищ! Оба "модуля" стандартные!!!

Наверное Вы просто больших программ не писали, и привыкли пользоваться затычками. Это очень плохо.

если язык не позволяет делать кросскак int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.

О, представьте себе, в Обероне сделано ещё лучше, в нём при написании одних модулей разрядность платформы можно учитывать, а при написании других – игнорировать.

Всё же мне кажется, на Обероны Вам не хватит терпения.

Ладно, продолжаем ликбез.

В Оберонах уже довольно давно вместо тупого включения куска текста в кусок текста программы, порождающего массу проблем зависимости между разными частями программы, предусмотрена модульность, и даже не только статическая, но и динамическая. Ближайший аналог этой концепции – механизм .SO/DLL в Linux/Windows.

Осмелюсь утверждать, что Оберон-концепт более совершенен, ибо динамические Оберон-модули не зависят от базовой платформы и хост-системы, оставаясь Оберон-модулями, они – возможность языковая, не имеющая аналога на уровне языка ни в Си, ни в Паскале, кроме того, в отличии от .SO/DLL модули могут включать, помимо процедур, ещё и типы, константы и переменные.

Особенности поддержки концепции модуля
в языках Delphi (Object Pascal), Modula-2 и Оберон
http://www.oberon2005.oberoncore.ru/qa261005.html

Динамическая модульность в BlackBox - OberonCore
http://oberoncore.ru/wiki/динамическая_модульность

Модульное программирование: Terra Incognita
http://oberon2005.oberoncore.ru/qa191005.html

могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...

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

[Oleg N. Cher]

я вижу что с языками вы слабо знакомы, особенно с языком си.

Очень весело слышать это, в особенности от Вас, уважаемый.

Хорошо. Ладно. Допустим даже, что Ваш макрос “помог”. Мы влезли в оба заголовочных "модуля", Офронта и винды, и вставили туда наше рулезное дополнение. Ибо одним "модулем" тут правка, видимо, ограничиться не может. Если может, блесните умом.

Но ещё и представим себе довольно вероятную возможность, что тип BOOLEAN внутри SYSTEM.h у нас является типом signed char, а тип BOOLEAN внутри windows.h – типом usnigned int.

Итак. Внутри windows.h мы имеем нечто такое:

#ifndef __BOOL
typedef unsigned int BOOLEAN;
#define __BOOL
#endif

Внутри SYSTEM.h же мы имеем нечто такое:

#ifndef __BOOL
typedef signed char BOOLEAN;
#define __BOOL
#endif

Наш весёлый "модуль" SYSTEM.c, думая, что тип BOOLEAN является однобайтовым, хотя его подленько уже могли подменить инклюдом windows.h перед инклюдом SYSTEM.h (а Си-прога, которая так сделает, может строиться Офронтом автоматически) на четырёхбайтовый, начинает юзать его во всю его однобайтовую душу. И – понесла нелёгкая, перекорёжив разрядность типов.

А наша весёлая программа могла бы конечно учесть, что BOOLEAN в таком разе – штука непростая, и надо выкурить много бамбуку, чтобы получить хоть какую-то осмысленную пользу от его использования, а ещё оно сильно вообще зависит от порядка инклюдирования "модулей" SYSTEM.h и windows.h, что ещё полбеды, а основная беда начнётся когда "модулям", берущим тип из SYSTEМ.h и windows.h, неявно подпихнут другой тип, их это должно здорово взбодрить.

Хорошо если программа сразу вылетит, а если не заметишь, и вылеты с порчей памяти и загадочным залезанием в чужие области и желанием выслать отчёт к какой-то матери регулярно будут у заказчика через месяц после сдачи?

Я как раз – об ощутимой помощи от использования Оберон-технологий в как можно более скорейшем выявлении такого рода узких мест. И чтобы влияние как закрытой реализации, так и открытой интерфейсной части одного модуля на другой сводилось к минимуму.