OberonCore

На groups.google.com нашел такой вопрос:
How do people use Strings in Oberon?

Do you set a predefined limit like in Pascal, where one was limited to
255?

Isn't it about time that the string problem be solved? Do you use a
pointer to an array of characters?

How to do simple string operations? Very important in desktop and
internet programming! Maybe not so important for certain tasks such as
embedded programming for helicopter control.. but..

Please inform? Can an easy to use garbage collected string be made in
a library module or must it be built into the language at some point?

It's really a simple question that cannot be easily answered anywhere
in the documentation or on oberon enthusiast websites, and I think it
is a serous problem. The question is: how in the world does one begin
to use strings in oberon 2, or oberon 07 or oberon 1? Is Blackbox
Component Pascal the only one that tried to address this problem and
did work there if so?

I don't think that knowing the string is 200 or 1000 characters long
really helps in programming for many tasks. It is equivalent to
defining your integer length each time - why is integer just integer
and not integer[Max:200].

Меня интересует аналогичный вопрос. Есть ли какие-нибудь модули для работы со строками произвольного размера? Насколько удобно работать с этим модулем?

Подсистема Text (TextModels.Model). Достаточно удобно.

Если не нужны вставки в произвольное место, и т.п., а нужно что-то на системном уровне, то Files.File.

Например, всякие серверные вещи с HTTP и т.п.

Как мне кажется, TextModels.Model и Files.File предназначены несколько для других вещей. И использование их для хранения строк будет как "стрельба из пушки по воробьям", так как в этих записях есть много разных полей, которые для работы со строками просто не нужны.

Если Вы знакомы с Delphi, то там есть тип string, размер которых ограничен 2 гигабайтами. И можно достаточно просто сделать конкатенацию строк, поиск в строке, можно обратиться к произвольному символу строки и т.д. Нужен модуль, который может выполнять аналогичные функции на обероне или компонетном паскале.

Да не получится сделать "строки вообще".

Надо понимать, какие операции необходимы.

Например, операции с 0-terminated строками требуют перевычисления длины, что дорого.
И т.д.

Для полноценных манипуляций со строками, действительно, можно отталкиваться от TextModels.

Если же нужен просто большой буфер - то Files.File.
(вообще уверенно рекомендую воспринимать Files.File как абстракцию растущего массива, под любые нужды).

Честно говоря не понимаю, как Files.File может быть растущим массивом. Если открыть System\Docu\Files.odc
Type = ARRAY 16 OF CHAR;

File = POINTER TO ABSTRACT RECORD
type-: Type;
(f: File) Length (): INTEGER, NEW, ABSTRACT;
(f: File) NewReader (old: Reader): Reader, NEW, ABSTRACT;
(f: File) NewWriter (old: Writer): Writer, NEW, ABSTRACT;
(f: File) Flush, NEW, ABSTRACT;
(f: File) Register (name: Name; type: Type; ask: BOOLEAN; OUT res: INTEGER), NEW, ABSTRACT;
(f: File) Close, NEW, ABSTRACT;
(f: File) InitType (type: Type), NEW
END;

Если судить по этому описанию, то эта запись содержит поле type с типом Type.
Где здесь массив, который может расти?

Делаете WriteBytes - оно растёт.

Естественно, подразумевается, что у Вас есть реализация Files.File над памятью (или Вы её попросили у кого-нибудь ).

PROCEDURE (w: Writer) WriteBytes* (IN x: ARRAY OF BYTE; beg, len: INTEGER), NEW, ABSTRACT;

Позволяет записать массив байтов. А если мне например надо сконкатенировать 2 строки, размеры которых я не знаю, то это уже не получиться сделать или же надо сначала узнать длину одной из "Files.File строк", выделить память под массив байт, скопировать туда содержимое Files.File, затем передать это в WriteBytes. Что не очень удобно.

Согласен, что, возможно, Files.File и TextModels.Model можно использовать с некоторыми ограничениями в качестве строк, но это получается не универсально. Например, также просто как в Delphi не получется.


Насчет обертки над байтами для Files.File: у меня такой нет и считаю, что это не очень хорошая идея использовать Files.File для работы со строками, даже если бы была такая обертка. Одно то, что надо будет вводить дополнительные сущности Reader, Writer уже усложняет работу.

Что касается Files, то я подчеркнул, что это не для случая интенсивных разрезок-склеек и т.п.
А вот TextModels однозначно сильнее, в общем случае, чем string, потому что за разрезка и оперирование фрагментами строк и проч. в Дельфи дороги, + есть всякие тонкие скрытые проблемы за этим string (много обсуждались в эпоху расцвета Дельфы). В частности, система оптимизирует - shares куски этих строк по чтению; реально копирует только при записи и т.п. На любой скрытой оптимизации рано или поздно вылезает какая-то гадость (и она там вылезала).


Смотря где. Если речь о системном программировании - то как раз очень хорошая. Например, в HTTP-сервере.
А понятие "работа со строками" вообще страшно размытое. Надо определиться, что требуется.

В принципе те строки, которые есть в Компонентном паскале, меня практически устраивают, за исключением того, что надо указывать сколько символов выделить под строку (VAR str: ARRAY X OF CHAR; ). То есть требуется, чтобы с новым типом, можно было делать все тоже самое, что можно делать с обычными строками, только не надо было определять X, а он определялся бы автоматически.

А вообще изначально вопрос, который стоял в первом посте, и который меня интересовал.
How do people use Strings in Oberon?
Из ваших ответов я понял, что
Александр Ильин использует TextModels.Model, а
Вы (Илья Ермаков) используете Files.File
Еще мне интересно, как другие используют строки?

Нет, если Вы понимаете под строками "просто строки" (т.е. всякую мелочь на каждом шагу в программе), то конечно же, для этого я использую просто ARRAY OF CHAR.

Files.File идёт в дело, если нужно, например, Web-формы генерировать, с UTF-8 работать, ну и т.п.

Я в последнее время для работы с SQL-запросами на верхнем уровне стал использовать TextModels. Проблем не ощущаю

P.S. Всякая мелочёвка - да, по-прежнему используется ARRAY OF CHAR.

Вообще-то довольно развитая библиотека для работы со строками есть в составе ПО web сервера http://www.o3-software.de/en/Products.xhtml. В частности там есть процедуры перевода TextModel в string и наоборот.

Я в XDS использую динамические строки, т.е. указатели на ARRAY OF CHAR. По сути, это аналог дельфийских строк. Проблем не вижу. Кстати, а что за проблемы со строками в дельфях?

Я уже указал на проблему Дельфы - оптимизацию строк. Когда Вы присваиваете s1 := s2, реального копирования не происходит. И даже, по-моему, при строковых операциях куски общими могут оставаться...
А реально разделение будет выполнено при записи. А иногда (если не того уровня средство применили, которое про оптимизацию не знает) можно такую петрушку получить, если изменяете строку s1, и вдруг побочные эффекты на совершенно посторонние строки идут.

Прошу прощения, я не понял, что вы имеете в виду.
Да, при присваивании копирования не происходит. Разве это недостаток?Что вы имеете в виду?
Это, вероятно, с использованием явного преобразования типов, что-то вроде PChar(s)?
Ну так это уже не дельфийские строки...

Вот Вы начнёте применять к s2 операцию типа Replace и т.п. - тут рантайм должен будет понять, что строку менять собрались - и перед этим создать реальную копию (иначе поменяется и "ничего не подозревающая" s1, которую когда-то присвоили в s2).
Механизм работает; но в каких-то тонких ситуациях промахивается.




Люди, глядя на определение языка, имеют право думать, что string - это просто динамический массив символов. И в каком-то месте они налетают на такие оптимизации реализации.

Вообще, я для себя выработал железное правило: любые внизу лежащие механизмы с неявным поведением - зло. Потенциальный источник проблем. Помеха к нормальному проектированию... и т.д. Внизу лежащие компоненты должны делать конкретную работу; если же туда пытаются засунуть принятие решений ("умность"), то это выходит боком.

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

В обероне точно такая же идея строк работает железобетонно.

Может, у вас есть крнкретная информация о недостатках динамических строк,
не связанных с низкоуровневыми средствами?

В Обероне я явно использую POINTER TO ARRAY. И я уже отвечаю за то, как с ним работаю.
Если я присваиваю ptr1 := ptr2, то я, естественно, получаю одну строку и два указателя на неё. А если мне надо копировать, я должен сам за это отвечать (NEW, s2^ := s1$).
В Delphi же это сделано неявно. Т.е. после s2 := s1 это формально разные объекты (я могу их изменять независимо), в силу же оптимизации s2 и s1 сначала указывают на один объект. И только по необходимости когда-то рантайм разведёт их.

Угу, наступали.
Применяешь к строке winAPI типа CharLower, и получаешь сурпризы в самых неожиданных местах...
И как "правильно" обойти эти грабли, тоже фиг поймешь.