Делаем строку на O7

[vlad]

Таки это попытки использовать язык для встроенки на прикладном уровне, имхо.
Вирт порезал его для того, чтобы это всюду влезало, а не чтобы так строки на нём реализовывать

Да, если бы Вирт объяснил для чего он порезал язык, то разборок было бы сильно меньше... А по поводу применимости в контроллерах я согласен с valexey_u. Добавлю только, что в астробовской версии динамические массивы есть, но только на стеке (неплохой компромисс, по-моему).

[vlad]

(типа, писали на КП библиотеку - внутри понаюзали дин. массивов, потом микроконтроллерщики, допустим, на том же КП захотели использовать эту библиотеку - а оп-па, этот компонент требует кучи не слабого размера и т.п. А запретим дин. массивы - так все будут осмотрительнее по использованию памяти). Возможна такая логика.

Ну вот даже на примере из топика видно, что это не так - получившаяся у меня строка неэффективна по памяти и в любой микроконтроллер не засунется...

[vlad]

А запретим дин. массивы - так все будут осмотрительнее по использованию памяти).

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

Это я все к идее о том, что простота языка в какой-то момент начинает бить по простоте решений на этом языке. Вплоть до брэйнфака. И есть какой-то оптимум, который может двигаться в одну и другую сторону в зависимости от характера задач. Так вот, по моим текущим ощущениям в случае O7 есть сильное смещение от оптимума (для заявленного general purpose language) в сторону простоты языка. Т.е., решения general purpose задач оказываются неоправданно сложными или неэффективными.

[Jordan]

vlad

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

Я бы реализовал так. STRING: ARRAY 1024 OF CHAR;
Если вдруг станет мало, увеличу. Уверен для большинства задач, со строками подойдёт.

И останется обычное обращение к массиву

Код: [Выделить]

s[i].

Или сделать через запись.

Код: [Выделить]

STRING = RECORD
  DATA: ARRAY 1024 OF CHAR;
  SIZE: INTEGER; длина строки символов, что бы не проходить весь массив.
END
Но в таком варианте обращение через функцию. Вроде StrIdx(S, 5); Или S.Data[5]

Это я все к идее о том, что простота языка в какой-то момент начинает бить по простоте решений на этом языке. Вплоть до брэйнфака. И есть какой-то оптимум, который может двигаться в одну и другую сторону в зависимости от характера задач. Так вот, по моим текущим ощущениям в случае O7 есть сильное смещение от оптимума (для заявленного general purpose language) в сторону простоты языка. Т.е., решения general purpose задач оказываются неоправданно сложными или неэффективными.

07 переступил эту черту, и гордо шагает.

[Jordan]

В такой реализации перерасход памяти. В исходниках А2, используются строки разных размеров
STRING16
STRING32

Нужно посмотреть реализацию.

[Илья Ермаков]

И такой вопрос, имеет ли смысл запрет дин массивов для программирования микроконтроллёров?

Вообще, для любых приложений 24*365 лучше использовать выделение только фиксированных размеров блоков. Дабы не нарваться на полную фрагментацию памяти. В целом, когда у вас нет кусков непредсказуемого размера, дин. память эффективнее используется.

[Илья Ермаков]

Это я все к идее о том, что простота языка в какой-то момент начинает бить по простоте решений на этом языке. Вплоть до брэйнфака. И есть какой-то оптимум, который может двигаться в одну и другую сторону в зависимости от характера задач. Так вот, по моим текущим ощущениям в случае O7 есть сильное смещение от оптимума (для заявленного general purpose language) в сторону простоты языка. Т.е., решения general purpose задач оказываются неоправданно сложными или неэффективными.

Согласен.
О7 - это культурный, строго типизированный аналог С.

[valexey_u]

Это я все к идее о том, что простота языка в какой-то момент начинает бить по простоте решений на этом языке. Вплоть до брэйнфака. И есть какой-то оптимум, который может двигаться в одну и другую сторону в зависимости от характера задач. Так вот, по моим текущим ощущениям в случае O7 есть сильное смещение от оптимума (для заявленного general purpose language) в сторону простоты языка. Т.е., решения general purpose задач оказываются неоправданно сложными или неэффективными.

Согласен.
О7 - это культурный, строго типизированный аналог С.

Не выйдет сделать аналог Си строго типизированным. Отсюда, собственно, все беды Оберона-07. Банально malloc не сделать. Си вот отлично обходится без массивов переменной длины.

[Jordan]

Можно сделать так.

Работа со строками происходит, только в статике. Для этого можно сделать массивы разных размеров.

Пример.
TinyString = 16 символов
SmallString = 64 символа
SizeString = 256 символов
HugeString = 1024 символа

В модуле объявляем string := HugeString; И понеслась.

Удобства, одни и те же процедуры для всех типов, плюс умеренный расход памяти.

Дополнительно реализовать тип Text для работы с многомегобайтными строками. Здесь уже идёт деления на чанки, как предлагал Влад.

Разделяем обязанности. Если нужны простые строки выбираем один из стрингов, если, что побольше уже работа с текстом.

[Jordan]

А вообще если отвлечься. Становится даже грустно. То, что на с++, питоны, джавы, руби делается двумя строками, да те самые контейнеры. На оберон языках нужно, рвать и метать...

[Jordan]

С каждым новым оберон языком под рапортом Вирта, лопата становится меньше, а яму копать глубже. ИМХО.

[vlad]

TinyString = 16 символов
SmallString = 64 символа
SizeString = 256 символов
HugeString = 1024 символа

Не, это тупиковый путь. Вот смотри - я пишу компилятор на обероне И у меня естественным образом возникает некая сруктурка, в которой я буду держать, например, распарсенный идентификатор переменной. Вот мне какую строку под это дело взять? 16? Не, маловато. 32? Должно хватить. А вдруг тексты на обероне начнут генерить и компилить моим компилятором - фиг знает чего там нагенерят и упрутся в эти 32. Ладно, возьму 1024 - хватит всем (гхм, ну с вероятностью близкой к 1). Но с другой стороны для большинства случаев получаем оверхед в расходе памяти на 2 порядка. Плюс еще пишем в документации (вроде у arkon'а как раз было) - "нельзя использовать идентификаторы больше 1024". Пользователь читает такую доку и недоумевает - а почему, собственно? Че за херня? А! Это потому что в обероне (на котором писался компилятор) нет нормальных строк.

P.S. Кстати реальный случай. В 6-й студии (вроде) было ограничение 255 на длину идентификатора в отладочной информации. Хорошо еще, что это был warning, а не error. Соответственно линковщик мусорил этими варнингами. Ну и понятно, что у них там тоже не было строк, а был где-то char buffer[256];.

P.S.S. Конечно Вирт в своей книжке про компиляторы не гнушается использовать ARRAY 16 OF CHAR для этих самых идентификаторов. Ну так то в учебной книжке - почему бы и нет. Но в промышленном коде - это уже попахивает...

[Илья Ермаков]

Ну, можно ещё задавать размер массива константой.
И для системного уровня не привыкать вводить такие ограничения, типа максимальной длины имени...
Даже твой пример несколько надуманный - если кто-то упрётся в эти 32, переделает генерацию имён. Зачем имена длиннее 64, допустим? "Шоб была возможность"?

Вообще, строки - штука хитрая... Очень от задачи зависит.
Можно и вообще делать спец. кучу для строк, где хранить их по ID. Кстати, Губанов, кажется, на такое переходил, когда избавлялся от managed memory в своём софте...

[Илья Ермаков]

А вообще если отвлечься. Становится даже грустно. То, что на с++, питоны, джавы, руби делается двумя строками, да те самые контейнеры. На оберон языках нужно, рвать и метать...

В плане того, что О7 - пониженного уровня язык, я говорил, поэтому я не доказываю, что с ним в типовых задачах всё замечательно.
Но хочу заметить, что часто проблемы надумываются, пока не решается конкретная задача. Если сидеть и думать "А как же я буду делать вот это, если оно мне понадобится", то голову сломаешь. А когда есть конкретный контекст, конкретные требования - то и вырабатываются решения. Которые потом иногда обобщаются.

[vlad]

Ну, можно ещё задавать размер массива константой.
И для системного уровня не привыкать вводить такие ограничения, типа максимальной длины имени...

Никто не говорит, что константный размер не нужен. Особенно в плане оптимизаций. Пусть будет. Просто действительно много случаев, когда и диапазон большой и оптимизировать нечего.
Посмотри на те же классические БД. Уж насколько тщательно там высчитывают размер колонки CHAR - и все равно расширяют потом. В то же время всегда есть тип TEXT - не такой эффективный как CHAR, но не менее востребованный.

Кстати, Губанов, кажется, на такое переходил, когда избавлялся от managed memory в своём софте...

Да, он боролся с GC. И согласись, у него довольно специфический случай, когда от универсальных строк действительно имеет смысл отказаться.