Forth
http://fforum.winglion.ru/

представление строк
http://fforum.winglion.ru/viewtopic.php?f=36&t=1850		 Страница 4 из 6
Автор:  вопрос [ Ср янв 07, 2009 23:24 ]
Заголовок сообщения: 
mOleg писал(а):
вопрос писал(а):
А откуда мы знаем- в какой системе меняется длина счётчика а в какой нет?

а нам этого знать не надо :)
надо только интерфейс знать

фортер не может успокоиться, пока не узнает всё (тут кто-то рекомендовал мне поизучать исходники, кто это был) :) :lol: :)
Автор:  mrack [ Ср янв 07, 2009 23:29 ]
Заголовок сообщения: 
вопрос писал(а):
...как проверить, если строка "ложится" в память, заполненную нулями, т.е. 0 там в любом случае в конце есть, потому возникает вариант 1а и 1б
[/list]

не вазникает ни каких вариантов ... поскольку строка может лечь как в пустую область так и притирку к следующей комуто выделенной, вероятность канечно в порядки разная, но не принебригаемо малая,
кстате да, нолик на всякий случай, в конце строки имеет смысл внести в обязательность, ибо "копейки затрат", зато пользы немеряно от совместимости с самой распространенной операционной системой :)
Автор:  вопрос [ Чт янв 08, 2009 01:24 ]
Заголовок сообщения: 
mrack писал(а):
вопрос писал(а):
...как проверить, если строка "ложится" в память, заполненную нулями, т.е. 0 там в любом случае в конце есть, потому возникает вариант 1а и 1б
[/list]

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

У меня варианты возникли ...
а насчёт копеек затрат, то да, точно так же копеечные затраты на ещё одно поле - оно ведь ВСЕГДА пустое - его и трогать не нужно, кроме случая, если кто-то пожелает отступить от стандарта, тогда, будь добр, дай знать - заполни ячейку ... и всё
Автор:  VoidVolker [ Чт янв 08, 2009 02:35 ]
Заголовок сообщения: 
Вот лично я по собственному опыту работы со строками считаю, что необходимы и достаточны только:
пара видов слов для создания строк
S" ххх" - a u строка(после последнего символа ноль)
" ххх" - az-строка
т.н. "бэкслеш-выражения" вида:
\xAB \n \crlf и пр.;
и несколько простейших операций со строками:
/STR ( a u n -- a u-n ) - укоротить строку
S+ ( a1 u2 a2 u2 -- a3 u3 ) - сложить строки с выделением памяти
SEARCH - ну это уже обычный поиск
А дополнительные слова типа поиск и замена, подстроки и прочее - как расширение в дополнительной библиотеке. Те же поиск и замена легко пишутся через SEARCH. Все! Больше совершенно ничего не нужно. А если надо работать с юникод-строками:
либо отдельно слова для работы с юникод-строками;
либо один вид строк - или юникод, или обычные;
или вводим контроль типов строк - в позиции -1 от адреса первого символа указываем тип строки-кодировку и радуемся жизни.
IMHO: всякие счетчики переменной длины, указатили и прочие дополнительные поля - полная и безполезная ерунда.
Автор:  вопрос [ Чт янв 08, 2009 02:40 ]
Заголовок сообщения: 
Цитата:
как расширение в дополнительной библиотеке
о которой нужно иметь возможность узнать, и ничего больше
Цитата:
или вводим контроль типов строк - в позиции -1 от адреса первого символа указываем тип строки-кодировку и радуемся жизни.
а мы что предлагаем - разве не это же?
Автор:  in4 [ Чт янв 08, 2009 14:53 ]
Заголовок сообщения: 
А никто не хочет сделать строки таким же элементом, как числа? ;)
Т.е. чтоб строки задавались в виде "Это строка" без всяких пробелов? ;) И обрабатывались на уровне интерпретатора/компилятора.

Описание реализации строк нужно только для реализации эффективных алгоритмов работы с ними и если есть функционально полный набор - можно работать одинаково (на высоком уровне) с любой реализацией.

Вот только для разных задач полный набор слов может быть разный... :(
И работать разные реализации будут с разной скоростью... :(

В принципе есть предлагавшееся решение из простых - внутри системы (для ПК) хранить все строки с 32-битовым счетчиком (память не экономить, вернее - экономить на программах обработки, а не на строках ;) ), а при обращении к ОС - копировать нужные строки в буфер или в кучу и давать ссылку туда. При соотношении скорости работы процессоров и вызовов ОС может получиться приемлемо! :)

Хотя по-правильному надо бы проанализировать все разные задачи, в которых используются строки. М. будут решения и получше... ;)
Автор:  WingLion [ Чт янв 08, 2009 15:37 ]
Заголовок сообщения: 
in4 писал(а):
если есть функционально полный набор - можно работать одинаково (на высоком уровне) с любой реализацией.

Вот его-то (функционально полный набор) и надо в стандарт вписать. А скорость работы - это параметр реализации, ограничивать который (методом забивания старых ржавых гвоздей в стандарт) в современной ситуации с быстро-развивающейся компьютерной индустрией - смысла нет. Оно и раньше небыло, но набили гвоздей, вот оно и волочится позади, цепляясь за каждую кочку и царапаясь при попытке приподнять и пронести вперед на руках.
Автор:  вопрос [ Чт янв 08, 2009 20:10 ]
Заголовок сообщения: 
WingLion, только функциональность - я был бы за, если бы это было!
У меня ушла уйма времени, чтобы понять, как устроены строки в разных ситуациях в СПФ, теперь, попытавшись перенести в форк - снова обнаружил несовместимость, хотя функциональность присутствует.
Автор:  mOleg [ Чт янв 08, 2009 20:35 ]
Заголовок сообщения: 
вопрос писал(а):
У меня ушла уйма времени, чтобы понять, как устроены строки в разных ситуациях в СПФ, теперь, попытавшись перенести в форк - снова обнаружил несовместимость, хотя функциональность присутствует.

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

К тому же даже в форке не возникает проблем, если вы работаете со строками с помощью стандартных COUNT TYPE s" SLITERAL и пр.
Автор:  mrack [ Чт янв 08, 2009 23:42 ]
Заголовок сообщения: 
может если дать определение понятию "строка" половина теорий автоматически самокалапсируются ?
или например обсудить недостатки на примере конкретной библиотеки "devel\~ac\lib\str5.f " ?
так дискус размазыватся будет меньше, наверное
Автор:  WingLion [ Чт янв 08, 2009 23:54 ]
Заголовок сообщения: 
Цитата:
строка - это последовательность символов.

Что-нибудь изменилось?
Автор:  mrack [ Чт янв 08, 2009 23:59 ]
Заголовок сообщения: 
да вот таки казалось бы так просто ан нет ... символ это что ? - байт? ворд? переменой длины?
допустимые размеры строки ?
а длина строки это количество байт или символов ?
и прочие технические ограничения
Автор:  WingLion [ Пт янв 09, 2009 00:03 ]
Заголовок сообщения: 
и почему все эти вопросы не самокаллапсировались?
Автор:  вопрос [ Пт янв 09, 2009 00:52 ]
Заголовок сообщения: 
Цитата:
и почему все эти вопросы не самокаллапсировались?

Потому. что могут быть разные форматы строк ( WingLion ещё столкнётся)
Автор:  Kamikaze [ Сб янв 10, 2009 03:16 ]
Заголовок сообщения: 
in4 писал(а):
А никто не хочет сделать строки таким же элементом, как числа? ;)
Т.е. чтоб строки задавались в виде "Это строка" без всяких пробелов? ;) И обрабатывались на уровне интерпретатора/компилятора.

Хм... В конце концов мы имеем только "программы" и "данные". "Данные" в свою очередь - это либо "числа", либо "строки". Тогда почему бы сразу жестко не зарезервировать всего несколько форматов для разных типов представления числа (бинарное, целое..), а все остальное автоматом засчитывать как строки? При этом количество различных форматов строк вообще не ограничивать, а воспринимать это их разнообразие по аналогии с множеством типов кодировок символов. (Как - не знаю...) Скажем, к примеру, через некое "поле кодировки": кодировка №001 - строка со счетчиком, кодировка №002 - ...

(Сорри за сумбур)
Страница 4 из 6 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/