OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 03 Декабрь, 2021 12:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 272 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14
Автор Сообщение
СообщениеДобавлено: Понедельник, 30 Август, 2021 22:17 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 518
Если я правильно понял диагноз по третьей проблеме, то в ББ есть например, вот такое определение в Properties с вложенной записью:

Код:
      StdProp = POINTER TO RECORD (Property)
         next-: Property;
         known, readOnly, valid: SET;
         color: Dialog.Color;
         typeface: Fonts.Typeface;
         size: INTEGER;
         style: RECORD
            val, mask: SET
         END;
         weight: INTEGER;
      END;


StdProp не EXTENSIBLE, в отличие от примера, вызывающего ошибку. Возможно, тогда дело не во вложенности, а в расширяемости, или в комбинации свойств записей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Август, 2021 23:00 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
adimetrius писал(а):
Возможно, тогда дело не во вложенности, а в расширяемости, или в комбинации свойств записей.
Да, дело точно в расширяемости.

Я так понимаю, что транслятор дублирует два раза запись, которую расширяет (Ex__1). Но в Си структуры, вложенные в другие структуры, не могут иметь одинаковое имя.

Йозеф предложил два решения, но, видимо, делать правку в скором будущем не будет. Я ещё в процессе обдумывания.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Сентябрь, 2021 17:48 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Oleg N. Cher писал(а):
По третьей Так что, я думаю, нам есть смысл подключить Дмитрия Викторовича Дагаева, если у него есть интерес закрыть эту ошибку в МультиОбероне.

Я сейчас в отпуске, посмотрю позже. Навскидку вместо дублирования записей должно быть использование анонимной записи, определённой в базовом модуле Ex1.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Сентябрь, 2021 20:16 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
На первый взгляд мысль кажется очень интересной. Но как тогда обращаться к элементам внутренней анонимной структуры?

Я передал Йозефу Ваше предложение, посмотрим, что ответит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Сентябрь, 2021 17:27 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Oleg N. Cher писал(а):
На первый взгляд мысль кажется очень интересной. Но как тогда обращаться к элементам внутренней анонимной структуры?

Я передал Йозефу Ваше предложение, посмотрим, что ответит.

В примере анонимная структура 'y' не имеет элементов, хотя может иметь. Но это превращается в С коде в элемент 'y' с типом в виде анонимной структуры struct без элементов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Сентябрь, 2021 21:26 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Понятно. Ещё такой вопрос: анонимные структуры являются частью стандарта ANSI C?

Судя по этой ссылке, нет. Глубже не копал.

Думаю, тогда лучше не стоит так делать. Не везде есть C11 и выше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2021 13:15 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1679
Oleg N. Cher писал(а):
Понятно. Ещё такой вопрос: анонимные структуры являются частью стандарта ANSI C?
Судя по этой ссылке, нет. Глубже не копал.
Думаю, тогда лучше не стоит так делать. Не везде есть C11 и выше.
компилятора под руками нет...
Только в виде вложенных и возвращаемых значений, насколько мне память не изменяет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2021 13:28 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1679
Oleg N. Cher писал(а):
.Не везде есть C11 и выше.
нет, я думаю, акценты - несколько иначе надо расставить...
Есть конторы, где обязательно надо самые последние и свежие новшества языка использовать, а есть, где - только "прошедшие сертификацию" версии разрешается работать. Например, во времена, когда уже везде пользовались gcc версии 4.5+, в конторе, где я работал, разрешалось использовать только 2.97.*... И там даже 99 версию не разрешалось включать...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2021 19:21 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Влад, всё верно. Но в данном случае мы гонимся не за последними новшествами из мира Си, а чтобы покрыть побольше Си-компиляторов, в т.ч. и старых.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 05 Сентябрь, 2021 03:14 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1679
Oleg N. Cher писал(а):
Влад, всё верно. Но в данном случае мы гонимся не за последними новшествами из мира Си, а чтобы покрыть побольше Си-компиляторов, в т.ч. и старых.

Могу, конечно же, ошибаться, но - не пустые ли это заморочки получаются?
Потому, что я уже практически не знаю компиляторов си(++), даже для встраиваемых приложений, где бы не было самых последних стандартов реализовано.
Нет, года четыре назад, я столкнулся с уникумом-начальником, который требовал, что бы ПО писалось на K&R варианте стандарта...но это уже, похоже, - исчезающий тип. В основном все уже безоговорочно приняли минимумом 11-тые стандарты. А на си++ уже требуют 17ый стандарт применять.
И - самое главное - уже как бы и повальное увлечение следованию MISRA проходит и восстанавливается здравый смысл. Очень этому статические анализаторы особенно способствуют... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 18 Сентябрь, 2021 21:37 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Тем временем, в Ofront+ появилась долгожданная поддержка двухбайтного символьного типа CHAR. Это открывает перед нами отличные перспективы по пересборке модулей BlackBox при помощи Ofront+, а также можно уже смело присмотреться к большой библиотеке исходников Гельмута Цинна, которые тоже можно пробовать пересобирать Ofront'ом+.

Лично мне очень приятно, что такая серьёзная, не побоюсь этого слова, работа привела к практически полной поддержке в Ofront+ Компонентного Паскаля. У нас нет ещё только поддержки мета-информации для работы BlackBox'овского модуля Meta, но я надеюсь, что нам это ещё долго не понадобится. В GPCP тоже этого нет, но, тем не менее, GPCP имеет право называться компилятором Компонентного Паскаля, согласно описания языка.

В Ofront+ появилась опция командной строки -w, отвечающая за то, как именно интерпретируются символы исходника программы: без -w - как и раньше (т.е. любой символ попадает в строку по его коду, и кодировка может быть абсолютно любая), а с -w транслятор считает, что на вход поступают широкие символы, даже если кодировка исходника UTF-8.

Ещё раз. На вход без режима -w можно подавать что угодно, любую кодировку - хоть 1251, хоть 866, хоть KOI-8R. Она просто ляжет в целевой сишник с теми же кодами, что и входящие символы.

А вот в режиме -w нужно подавать только такие юникодные символы, которые поместятся в два байта. Иначе будет ошибка err 3. Это я предусмотрел специально.

err #3: illegal character in string

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

С опцией -w пока что поддерживается только входной формат .txt в кодировке UTF-8 (в версии для BlackBox - и .odc), но список входящих форматов мы обязательно расширим. В итоге нам должно быть без разницы, как именно закодирован исходник. Я как раз хотел этот момент автоматизировать и не задавать доп. ключами. А вот как именно интерпретировать символы - совсем другое дело, для этого теперь есть опция -w. А когда мы научим Texts понимать формат .odc (я планирую это сделать), оттуда будут идти широкие символы, но нужно оставить возможность, чтобы они интерпретировались как UTF-8 (без ключа -w).

Кстати, в процессе работы над CHAR появилась интересная мысль сделать ключик -w переключателем широкого или узкого CHAR в Обероне-07. Уже даже реализовал. Я подумал, что ведь раз будут идти широкие символы с входного потока, а тип CHAR в O7 только один, то нормально будет их обрабатывать именно как широкие. А если будут идти узкие, в UTF-8, то нормально будет узкие.

Расклад по широкому CHAR'у:

Oberon-1, Oberon2: CHAR, SYSTEM.CHAR16
Oberon-07: варьируемой длины CHAR
КП: SHORTCHAR, CHAR
Oberon-3: CHAR, LONGCHAR

Одна небольшая тонкость, связанная с ключиком -w:

Модуль
Код:
MODULE TestChar16;
VAR ch: CHAR;
BEGIN
  ch := "Ж"
END TestChar16.

С -w поступивший символ "Ж" будет интерпретирован как широкий CHAR и программа нормально скомпилится.

А без -w символ "Ж" это будет юникодовая строка, состоящая из двух байт, и программа уже не скомпилится.

Код:
MODULE TestChar16;
VAR i: INTEGER;
BEGIN
  i := LEN("Ж")
END TestChar16.

Здесь с -w длина будет 1, а без -w длина 2. Но тут, надеюсь, всё понятно)

Также ввёл для Оберона-3 новую операцию LCHR. Связано это с тем, что CHAR тут короткий, и поэтому CHR не может и не должна выдавать длинный символ, значит нужна новая операция.

Для O1, O2 реализован SYSTEM.LCHR.

Также во всех диалектах реализованы типы SYSTEM.CHAR8 и SYSTEM.CHAR16.

Я подверг Ofront+ зверскому испытанию - попробовал оттранслировать модуль Strings из BlackBox:

Изображение

Пришлось включить ключик -w, а то там есть прямое задание широких символьных литералов.

А вот часть ББ, собранная для Linux. Strings и Math должны работать. Из Kernel взято только несколько процедур:

Изображение

Модули bb* не только транслируются, но и компилятся сишкой. Но их работу я не тестировал. Привязки LinLibc и LinLibW сделаны очень сильно с уклоном на 32-битность, надо перепахивать. Пока сделал, что смог. К сожалению, нет возможности для заимствованных привязок тестировать все функции.

Один очень важный момент: перед сборкой любого проекта новым Ofront+ нужно удалить все символьники. Пришлось немного изменить формат символьников. OP2 вообще очень похабно работает с символьниками: если подсунуть символьник неправильного формата, то транслятор закрэшится почти гарантированно. И это касается и Ofront, и Ofront+, и BlackBox.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Октябрь, 2021 12:05 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Для третьей проблемы выкатываю такое решение.

Компилируемость проверил в GCC, Clang, Turbo C v2.01, cc65, SDCC и SCCZ80.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 272 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2021, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB