Сообщение от
Eltaron
А указатели на функции в Обероне есть?
Конечно есть:
Код:
PROCEDURE Fn(): INTEGER; BEGIN RETURN 0 END Fn;
...
VAR fn: PROCEDURE (): INTEGER;
BEGIN
fn := Fn; ...
...
END ...
Сообщение от
Eltaron
В любом случае, когда код записан строкой - он не типобезопасен. Он вообще не безопасен, там и опечатки могут быть, и что угодно ещё. В C# и C++11 очень круто то, что все эти конструкции проверяются ещё на этапе компиляции.
Ну собсно обработку ошибок я опустил для упрощения. А так - почему бы не проверить вывод компилятора и не отреагировать соответствующим образом.
Я опасаюсь, что ново-программисты будут использовать такое средство как лямбды, для которого конечно можно придумать хорошее применение, втуне. Т.е. не понимая чётко всего механизма. А оно как - компилируется? А потом? Куда-то загружается и запускается? Т.е. вся эта тянучка из компилятора и рантайма присутствует в конечном продукте. И накладные расходы соответствующие. Для сортировки списка или поиска элемента - это уже слишком.
Сообщение от
AlexG
Как обстоят дела с INTEGER 64bit в языке ОБЕРОН ?
В зависимости от реализации. В стандарте Оберона/Оберона-2 размеры типов не зафиксированы. Традиционно (ETH Oberon, A2/AOS, XDS) INTEGER = 16 бит; LONGINT = 32 бита. Для 64 битов в некоторых реализациях есть тип HUGEINT.
В Component Pascal, XDev/WinDev INTEGER = 32 бита; LONGINT = 64 бита. Есть ли возможность использовать именно 64-битный INTEGER? В XDev/WinDev - да. Размер всех типов задаётся в специальном файле-конфигураторе Ofront.par, выглядящем примерно так:
Код:
CHAR 1 1
BOOLEAN 1 1
SHORTINT 2 2
INTEGER 4 4
LONGINT 8 8
SET 4 4
REAL 4 4
LONGREAL 8 8
PTR 4 4
PROC 4 4
RECORD 1 1
ENDIAN 1 0
Сообщение от
AlexG
Коим образом можно "перенести" работу с битовыми полями с С на Оберон ?
Для работы с битовыми полями предлагается тип SET, что во многом снижает потребность в логических операциях AND, OR, XOR. Несмотря на некоторую громоздкость записи, логические операции для целых в Обероне всё-таки можно использовать.
Вирт Н. SET: Недооцениваемый тип данных и его компиляция для ARM
Сообщение от
AlexG
Как обстоят дела с объединениями ?
union {
u16_t var1;
struct {
u8_t aaa;
u8_t bbb;
}
}
var1 = 0x1122;
tmp = aaa + bbb;
Объединения в Оберон-парадигме считаются опасным низкоуровневым средством. В некоторых реализациях есть возможность использовать объединения в биндингах (например, в BlackBox).
Какая альтернатива предлагается для замены объединений? Расширяемые записи.
Код:
TYPE
Father = (*EXTENSIBLE*) RECORD
a, b, c: INTEGER; (* Это общие для всех потомков поля *)
END;
Son = RECORD (Father)
d, e: CHAR; (* Это только данные сына *)
END;
Daughter = RECORD (Father)
d, e: SET; (* Это только данные дочери *)
END;
Оберон строг в проверке типов и на этапе компиляции, и в рантайме. Он спроектирован так чтобы по максимуму обезопасить работу с указателями. Соответственно нет смысла кастить объект типа Son в объект типа Daughter и пытаться работать с полями сына как с полями дочки. Вместо этого применяется охрана типа:
Код:
obj: POINTER TO Father; (* Это указатель на отца и др.членов семьи *)
BEGIN
IF obj IS Son THEN ... END; (* Проверка того, что это сын *)
WITH obj: Daughter DO (* Гарант того, что объект - дочь *)
(* Если объект не дочь - ловится ошибка исполнения или исключение *)
END
Я думаю, понятно по аналогии как именно предлагается безопасно работать с расширяемыми записями вместо объединений.
В принципе, мне объединения ещё ни разу не понадобились, кроме как в биндингах к SDL 1.3 (там есть их два штуки).
Хочу подчеркнуть, что Оберон - маленький язык. Если хочется увидеть в нём прямые аналоги всех сишных возможностей, то этого нет. Но зато, например, компилятор ARM Oberon-07 занимает ~ 3 000 строк исходника. OP2 (Oberon Portable Compiler) ~ 10 000 строк.
Так что присуща некоторая аскетичность. Но, в принципе, возможностей хватает, просто нужно слегка перестроить мышление.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
