во всех языках есть строки. строка - это упорядоченный набор символов. символ - это 1, а лучше 2 байта. utf16 вполне достаточно для поддержки всех символов юникода без особых потерь в производительности. говоря математическим языком, строка - это вектор символов. использование строк позволяет здорово экономить память. нам не надо хранить техническую информацию о каждом символе - достаточно хранить её для строки, а все символы будут её "наследовать". при этом доступ к конкретному символу невозможен, но возможно получить строку содержащую только нужный символ. так, к чему это я? а к тому, что тот же приём можно использовать и для других типов. например, чисел. например: Код (Text): var1: 0 # var1 - вектор содержащий одно единственное число var2:( 1, 2, 3 ) # var2 - вектор содержащий три числа $var1 append $var2 # 0 1 2 3 $var1 prepend $var2 # 1 2 3 0 1 2 3 $var slice ( 1 .. -1 ) # 2 3 0 1 2 замечу, что тут я использовал знак доллара для указания, что используется значение на которое указывает имя. посылка объекту сообщения: append $var2 ,означает, передачу ему двух параметров - строки "append" и значения переменной с именем var2
да че мелочиться, давайте 4 байта, один фиг на х86/х64 будет выравнивание по 4 байтам, зато скока всяких супер-пупер бит-флагов будет, а? %) кстати, при наличии доп-байтов, можно будет технически сделать двусвязный список. Это если строки - односвязный массив, как сейчас. Тогда всякие перемещения символов в пределах массива и удаление элементов будут куда быстрее. про всякие "$вар1 аппенд $вар2" промолчу, ибо фигня какяа то если более понятные конструкции - $вар1.=$вар2, $вар1=$вар1+$вар2
> да че мелочиться, давайте 4 байта 1 байт откровенно мало, 4 - откровенно много. 2 - необходимо и достаточно. > Тогда всякие перемещения символов в пределах массива и удаление элементов будут куда быстрее. зато при подсчёте длинны и копировании (а это основные операции над строками) получим дичайшие тормоза. > если более понятные конструкции не надо путать понятие "понятные" и "привычные". например, пхпэшная точечка у меня до сих пор вызывает отвращение ибо из-за того, что она забиндена на конкатенацию, к полям объекта приходится обращаться через стрелочку, что весьма неудобно.
> $вар1.=$вар2, $вар1=$вар1+$вар2 anyObject1->anyObject2->AnyItem = "пусть препендом пользуются ламеры, а мы будем протирать дырки в кнопках CTRL, C и V" + anyObject1->anyObject2->AnyItem
продолжая идею с векторами... каждая переменная является вектором, содержащим упорядоченое множество однотипных объектов. поскольку ни один из элементов нельзя получить без обёртки (обёртка - вектор), то все сообщения обрабатываются исключительно вектором. следовательно вектора тоже должны иметь тип (поведение определяемое его членами)... мда... что-то страшное... думаю стоит ввести на уровне языка разделение на примитивные объекты и комплексные... или даже нет, пусть каждый объект реализует два интерфейса - комплексный и примитивный. и чтобы пространства имён у этих интерфейсов не могли пересекаться...
dark-demon с чего бы это?? не то чтобы "дичайших", даже "тормозов" не будет. откровенно много для чего? процессор при вычислении все равно выравнивает по 4м байтам, соотвственно 2ух байтовые сначала приводятся к 4м байтовым. Оперативки сейчас хватит на все. А еще когда то Билли говорил всем, что 640кб оперативки хватит всем... мне и самому точечка не нравится, через плюсег и наглядней и привычней. Чем всякие append и тп... обсуждаемый предмет - велосипед? %)
> с чего бы это?? не то чтобы "дичайших", даже "тормозов" не будет. будет, с чего бы им не быть, если за каждым следующим символом нужно лезть в другой участок памяти? > процессор при вычислении все равно выравнивает по 4м байтам вот пусть и засунет туда два символа. > Оперативки сейчас хватит на все. не хватит. память не бесконечная, а твоя программа - не единственная. > обсуждаемый предмет - велосипед? %) да, обсуждаемый предмет - велосипед на котором можно ездить, а не который ездит на тебе
А с чего это Лисп - велосипед и ископаемое? Вы еще фортран ископаемым обзовите. И хаскеля в ту же яму.
ещё "форт" в ту же топку. говорят хорошо греет... это так называемые "птичьи языки". чтобы на них серьёзно программировать нужно свернуть себе голову на 180 градусов. труъ же язык должен быть в первую очередь удобен для человека. в нём должно быть как можно меньше условностей, а те, что есть должны укладываться в простую и ясную идеологию. в идеале, конечно, ТЯП (труъ язык программирования) должен быть максимально близок к естественной речи.
<оффтоп> (вспомнилось) Речи Йоды тайна магистра раскрыта, старый программист на форте оказывается он</оффтоп>
dark-demon а в односвязном типа не нужно? а если все равно засунет туда два символа, почему бы их сразу не использовать и не применить их в кач-ве полей каких нибудь? ни разу не видел строки в 2Гб. даже в 1Гб. даже в 512Мб. Адресации хватит на все, способность ОС работать со свапом решит все. "говорят - кур доят" %) о да, именно поэтому в нем вместо "$var1=$var1+$var2" предлагается "$var1 append $var2" )))
> а в односвязном типа не нужно? нужно, но строки хранятся одним массивом, а не связным списком. > Адресации хватит на все, проблема не в адресации, а в занимаемом объёме памяти. > способность ОС работать со свапом решит все. убей себя > именно поэтому в нем вместо "$var1=$var1+$var2" предлагается "$var1 append $var2" не "вместо", а "независимо от". оставим плюсик для арифметических операций.
двусвязный список - тот же массив, но каждый элемент имеет указатель не только на следующий элемент, но и на предыдущий. и что, много занимает? говорим про мега-труе-высокоуровневый язык и тут на-те - занимаемая память ))) разрешите бегом? а может мега-труе-высокоуровневый язык все таки сможет сам понять, что строки не нужно складывать арифметически, и дадим плюсегу возможность соединять строки?
Dagdamor, плюсег всегда можно сделать алиасом аппенда для строк. append - это абстрактное сообщение, не привязанное конкретно к строкам. его можно применять как ко строкам, так и к числовым векторам и к обычным массивам.
dark-demon я наверное сейчас открою страшную тайну, но все массивы есть **связные списки, в не зависимости от того, ведется ли адресация на элементы из заголовка (индексы) или непосредственно в самих элементах ("теоретические" связные списки). Ибо это есть оптимизация ОС. К плюсам "связных" списков - фрагментация в памяти, когда не нужно высвобождать цельный кусок памяти для "теоретических" массивов. Для юзера это прозрачно.
> все массивы есть **связные списки, в не зависимости от того, ведется ли адресация на элементы из заголовка (индексы) или непосредственно в самих элементах ("теоретические" связные списки). ты путаешь понятия "связный список" и "упорядоченное множество". > Ибо это есть оптимизация ОС. ОС тут вообще никаким боком > К плюсам "связных" списков - фрагментация в памяти цитата достойна башорга ^_^ чего ещё интересного скажешь?
а есть смысл? судя по последним фразам, толку не будет. когда последний раз дебаггер открывал и смотрел на реальную (в пределах процесса) адресацию на объекты?
тише девочки, не ссорьтесь... выложите скриншотики с дебаггера... я посомотрю, люблю карасивые техногенные картинки....