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