Какая кодировка у BB документов?

[vlad]

Т.е. тут получается не альтернативная кодировка, а просто бесполезная трата процессорного времени.

Экономия на байтах? Собственно как и сам по себе двоичных формат документов.

[ilovb]

Типа того. Только непонятно зачем они эти два байта кодируют/декодируют.

[valexey_u]

Вообще прикольная логика:
1. Берем юникодный текст
2. Символы < 256 кидаем в Piece. По байту на символ.
3. Символы >= 256 перекодируем. Те же 2 байта... но другие.... И кидаем в LPiece.

Стоп. Я как они тут разрешают неоднозначность которая возникает? Ведь тогда последовательность двух писов может быть неотличима от одного LPiece. Или Piece это таки не один байт, а больше и имеет какой-то заголовок?

[ilovb]

Ну там вроде пишется отдельно инфа о том где какой пис начинается/кончается.
Там же еще атрибуты текста пишутся и прочая хрень. Заголовок конечно есть.

[valexey_u]

Ну там вроде пишется отдельно инфа о том где какой пис начинается/кончается.
Там же еще атрибуты текста пишутся и прочая хрень. Заголовок конечно есть.

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

[ilovb]

Ну вьюшки конечно можно. Это ж составные документы.

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

ViewRef = POINTER TO RECORD (Run)    (* u IS ViewRef => View run *)
    w, h: INTEGER;
    view: Views.View    (* embedded view *)
END;

[Kemet]

ну можно покурить доки на подсистему TEXT оригинального оберона, про кодировки там нема, а вот структура должна подробно описана

[ilovb]

Или Piece это таки не один байт, а больше и имеет какой-то заголовок?

Это цепочка байт произвольной длины.

[ilovb]

ну можно покурить доки на подсистему TEXT оригинального оберона, про кодировки там нема, а вот структура должна подробно описана

С пониманием структуры проблем нет. Есть проблема с пониманием того, что насвистоперделили разработчики BB. Т.е. та часть текстовой подсистемы которой нет в оригинальном Обероне.

У самого Вирта то все просто и элегантно. И с документацией проблем нет... 

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

Как это устроено я понимаю. Но что такое LPiece и зачем оно нужно не врубаюсь. И меня дико бесит волшебный префикс "L". Что он значит?
Представьте себе что у Piece и ViewRef тоже нет комментов. Чуйствуете сколько полезной информации сразу пропадет?

Ну а если бы модуль был в три раза меньше, поделён на несколько модулей - и интерфейс каждого был бы специфицирован? Реализацию уже было бы совсем легко обозреть и загрузить в свой котёл.
Плюс некоторый небольшой текст мог бы быть - пояснение к реализации. Что выбрана такая-то кодировка. Какие структуры данных и роль каждого типа.

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

Но осмелюсь дать несколько рекомендаций которые по крайней мере не сделают код хуже:

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

А вот это в корне не правильный подход.

А я выше написал, что его не оправдываю.
Но в свете "мечт" об исключительно бинарной компонентности, при разработке с закрытыми исходниками - ну и при сжатых сроках - такой подход БЫЛ понятен. Малой команде он не вредит, ну а после открытия исходников - кто ж обещал, что они будут ориентированы на массовые изменения

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

Смысл -128 не разъясню с лёту.

А что тут разъяснять?    Чем так мучаться, лучше уж ввести полноценный BYTE с областью значений от 0 до 255. Страхи, что после этого язык станет платформозависимым, считаю не оправданными. Понятие "байт" давно уже мигрировало во многие прикладные предметные области.

Это не связано с беззнаковым байтом.
DIV/MOD-ам похрену на знаковость, битово одно и то же за счёт дополнительного кодирования получается.

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

Я не оправдываю стиль написания кода ББ-шных разработчиков. Они, видимо, попали в частый соблазн - когда хорошо спроектируешь интерфейсы, то думаешь, что "а похрен, что там и как внутри у этого кирпича будет". Не говоря про то, что идеи, бродившие в начале 90-х, были полностью "зациклены" на двоичной компонентности, при сокрытии исходного кода.

Что есть в корне не верно. Открытый компонент можно сделать на порядок проще, просто за счет того, что гибкость его обеспечивается не наворачиванием фич на все случаи жизни, а самой открытостью исходника. Кроме того, я пока не видел компонента, интерфейсы/абстракции которого не протекали бы. Ибо создатель никогда не знает в каких именно условиях это дело будут применять.

Понять что именно и как именно работает в компоненте, отладить его, намного проще когда есть исходники. Помню как сильно, в свое время, мне помогло то, что VCL поставлялся в исходниках. Компонентина поставляемая в бинарниках с любой документацией всегда проигрывает компоненте с открытыми исходниками (при прочих равных).

Согласен.
Работать надо так, как будто исходники read-only, но само их наличие очень полезно.

[DIzer]

А я выше написал, что его не оправдываю.
Но в свете "мечт" об исключительно бинарной компонентности, при разработке с закрытыми исходниками - ну и при сжатых сроках - такой подход БЫЛ понятен. Малой команде он не вредит, ну а после открытия исходников - кто ж обещал, что они будут ориентированы на массовые изменения

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

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

Так не бывает. Ну, то есть ты и пришел к единому стилю в коде (то есть твой код пишется в том же стиле что и твой код), ну, в крайнем случае я могу себе представить небольшой коллектив (ну максимум человек 5) у которых стиль единый стал из за долгой совместной работы.
Но вот чтобы стиль выражения мысли в коде стал единым для все пишущих на данном языке... Не бывает. См. хотя бы сколько нагенерили способов получить беззнаковое значение байта :-)

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

P.S. Вообще, я придерживаюсь принципа, что открытые исходники -это хорошо, но всё равно, кроме авторов, другим особо нехрен менять компонент. За конкретный модуль - конкретная персональная ответственность. Проекты, где стадо кодеров правит груду исходников - нах, нах...