OberonCore

Привет всем! Давно с интересом слежу за обсуждениями в данном сообществе. Приверженцем швейцарской школы программирования я стал задолго до того, как познакомился с ней . Это мой первый пост на данном форуме.

С точки зрения языка обявления констант s1 и s2 равнозначны. Но компилятор в BB, к сожалению, считает иначе . В обоих случаях цепочка длины 1 размещается в статической памяти (для глобальных констант). Но в первом случае выделяется один байт для хранения цепочки, а во втором случае - два байта, так как операция конкатенации неявно добавляет нуль-литеру.
В случае объявления литерной цепочки длины 0, 2 или более, указанная "особенность" не проявляется.

В BlackBox 1.6 это уже исправлено.

Добро пожаловать!

Спасибо! Всегда приятно поговорить с умными людьми

Здравствуйте, Игорь!

Предлагаю познакомиться при личной встрече. Например, на ф-те информатики ТГУ в четверг или в субботу (у меня 3-я пара "Практикум на ЭВМ" 12:25-14:00, ауд.103-б). Я думаю, общие интересы в области прог-я на КП/ББ у нас есть.

Привет! Рад видеть ещё одного томича : ) Поддерживаю предложение А.П. о встрече, чаю попить никогда не помешает.Я так понимаю, что в первом случае константа имеет тип CHAR, а во втором случае ARRAY OF CHAR. Значение LEN(CHAR) не определено в описании языка, так что по-хорошему компилятор должен выдавать ошибку.

Предложение принимается. Вокруг так много людей, а поговорить о наболевшем практически не с кем . Подробности в личных сообщениях и немного позже, сначала надо уладить кое-какие дела.
Oberon-community имеет широкую географию. Приятно было увидеть сразу несколько томичей. Ещё приятнее пополнить эти ряды.


Вы правы, Александр, в первом случае константа имеет тип CHAR. Но от себя добавлю, что должна была бы иметь тип ARRAY OF CHAR, точнее тип цепочек литер. Строки в КП - хороший пример того, как тип переменной может не совпадть с типом значения, хранящегося в этой переменной. И насчёт переменных, здесь я не оговорился, потому что строковые константы в КП всегда реализованы как "переменные только для чтения" и никогда не размещаются компилятором непосредственно в коде (immediate data), в отличие от констант других типов.
В пользу того, что это всё-таки ошибка говорит тот факт, что в v1.6 она исправлена, как справедливо заметил PGR.
Я кажется понял механизм того, как возникла эта ошибка. Разработчики, помятуя о том, что

привели цепочки длины один в соответствие с литерной константой. А нужно было наоборот: привести литерные константы в соответствие с литерными цепочками длины 1. А это, как мы видим, не одно и то же.

Продолжаем искать баги в компиляторе

Аттрибуты ABSTRACT, LIMITED, EMPTY и EXTENSIBLE помечены в сообщении как ключевые слова, но реализованы в Блэкбокс как предопределённые идентификаторы (см. DevCPT, секция инициализации).

Это фича.
Так просто быстрее компилятор расширить видимо было.

Кстати, где это проявляется? в сообщениях компилятора? и как Вы обнаружили -- простым рассматриванием?

Но знать об этой фичи никому не помешает . Собственно, поэтому и написал.

Обнаружил случайно, просматривая исходники компилятора.
Проявляется, например, так. Следующий код компилятор проглатывает не поморщившись: А должен выдавать ошибку!

Ага!

Я спросил для статистики: все настоящие открытия деляются случайно в процессе пристального рассматривания.

Помнится, студент зачем-то использовал какие-то из all-cap слов в качестве идентификаторов, и там лезли странные ошибки. Но пристально рассмотреть никто не догадался.

Эффект Вавилова-Черенкова тоже видели две (кажется) группы в мире до Черенкова, но отмахнулись типа мало ли, мусор.
И только Черенков оказался занудой и стал проверять.
И получил Нобеля

Ну, на Нобеля я не претендую
Кстати, помнится я читал статью Никлауса Вирта, в которой он сетовал, что поздно понял, что FALSE и TRUE следовало бы сделать ключевыми словами. Даже пример приводил, приводящий к абсурду. Вот ссылочку сейчас дать затрудняюсь, но думаю, что все её читали.

Тут дело не в претензии, а в хороших привычках. А дальше уж как повезет