Oberon space
General Category => Общий раздел => Тема начата: ilovb от Декабрь 18, 2012, 04:02:25 pm
-
Наверно глупый вопрос, но я не врубаюсь.
-
а что это )))
-
Ну как в Оберонах например. (да, да - ARRAY OF CHAR :) ) Могу изменить один символ и это не приведет к созданию копии строки. В Lua так сделать нельзя. Строки там неизменяемые и любые изменения приводят к копированию. И так сейчас вроде делают во всех современных языках. Почему?
-
Ну как в Оберонах например. (да, да - ARRAY OF CHAR :) )Почему?
Потому что в Обероне нет строк )
array of char он и есть array of char
а чтобы реализовать в виртовском компиляторе такие строки полчаса не хватит, поэтому они и плохи )
-
Ну как в Оберонах например. (да, да - ARRAY OF CHAR :) )Почему?
Потому что в Обероне нет строк )
array of char он и есть array of char
а чтобы реализовать в виртовском компиляторе такие строки полчаса не хватит, поэтому они и плохи )
А кстати, нафига в язык вшивать строки? Никогда не понимал этого действа.
-
А кстати, нафига в язык вшивать строки? Никогда не понимал этого действа.
Чтобы сделать их неизменяемыми. См. сабж :)
-
А кстати, нафига в язык вшивать строки? Никогда не понимал этого действа.
"вшитые" строки обладают определенным поведением и наделены неким набором определенных операций, известных на этапе компиляции и контролируемых. А так прижется вводить механизм операторов, опять в полчаса не уложиться
-
Ну как в Оберонах например. (да, да - ARRAY OF CHAR :) )Почему?
Потому что в Обероне нет строк )
array of char он и есть array of char
а чтобы реализовать в виртовском компиляторе такие строки полчаса не хватит, поэтому они и плохи )
Array... да не совсем, т.к. есть дополнительный синтаксис для строк (присваивания, конкатенация...)
Но речь не об этом.
Вопрос: Почему в современных языках отдают предпочтение неизменяемым строкам?
-
А кстати, нафига в язык вшивать строки? Никогда не понимал этого действа.
Чтобы сделать их неизменяемыми. См. сабж :)
Ну, ничто же не мешает их сделать неизменяемыми библиотечные строки. Ну, если язык конечно достаточно высокоуровневый ;-)
-
Наверно глупый вопрос, но я не врубаюсь.
Чтобы в твоей программе кнопка "Да" не могла поменяться на "Нет" только потому, что ты строчку "Да" отдал в чужую компоненту (а может и в свою, но забыл, что она модифицирует эту строчку).
-
Вопрос: Почему в современных языках отдают предпочтение неизменяемым строкам?
Скорость работы - копируется только указатель, ну или небольшой дескриптор, а реальное копирование происходит только при необходимости - при изменении
-
Наверно глупый вопрос, но я не врубаюсь.
Чтобы в твоей программе кнопка "Да" не могла поменяться на "Нет" только потому, что ты строчку "Да" отдал в чужую компоненту (а может и в свою, но забыл, что она модифицирует эту строчку).
По моему, очевидно что если кто-то хочет менять переменную, то на входе у него будет VAR-параметр (или не const, если у нас плюсцы), а если не хочет, то будет VAL. Не вижу проблем тащемто :-)
Не понятно почему именно для строк сделано это исключение, почему его нет например для чисел. Или там для сокетов :-)
-
ОК. Тогда более конкретно:
Я люблю писать всякие алгоритмы над строками в следующем стиле:
1. завожу переменную buffer
2. перебираю исходную строку символ за символом и собираю нужные символы в буфер
3. при достижении опред. условий скидываю буфер в массив например.
В CP это делается максимально просто, удобно и эффективно.
В 1С мне похер, т.к. там эффективность меня обычно мало волнует.
В Lua я не знаю как такое провернуть (эффективно).
Начальный размер буферу я задать не могу. При добавлении символа буфер будет копироваться....
-
По моему, очевидно что если кто-то хочет менять переменную, то на входе у него будет VAR-параметр (или не const, если у нас плюсцы), а если не хочет, то будет VAL. Не вижу проблем тащемто :-)
Это не всегда очевидно. Сегодня у компоненты нет VAR, а завтра появился... и хорошо, если компиялтор про это скажет. Кроме того, VAR очень захочется поставить, если его отсутствие подразумевает копирование строки (массива) - типа оптимизация. А в случае изменяемых строк именно копирование и будет подразумеваться ;)
В плюсах тоже самое - сегодня там const ссылка, завтра - не-const. Компилятор поймает, но не во всех ситуациях. И даже если там всегда const - это все равно ничего не гарантирует. Строка может придти по const ссылке, но это вовсе не означает константности самой строки - ее может поменять кто-то другой для кого она не-const. Я уже не говорю про const_cast<>...
Короче, изменяемые строки - однозначное зло.
-
ОК. Тогда более конкретно:
Я люблю писать всякие алгоритмы над строками в следующем стиле:
1. завожу переменную buffer
2. перебираю исходную строку символ за символом и собираю нужные символы в буфер
3. при достижении опред. условий скидываю буфер в массив например.
В CP это делается максимально просто, удобно и эффективно.
В 1С мне похер, т.к. там эффективность меня обычно мало волнует.
В Lua я не знаю как такое провернуть (эффективно).
Начальный размер буферу я задать не могу. При добавлении символа буфер будет копироваться....
Ну, не знаю как в луа, а во ВСЕХ современных языках несмотря на строки, никто массивы из char'ов не отменял. И их то как раз модифицировать можно как угодно.
-
ОК. Тогда более конкретно:
Я люблю писать всякие алгоритмы над строками в следующем стиле:
1. завожу переменную buffer
[...]
В Lua я не знаю как такое провернуть (эффективно).
Начальный размер буферу я задать не могу. При добавлении символа буфер будет копироваться....
Просто buffer - должен быть не строкой, а массивом или еще чем (в жабе/шарпе есть специальные классы). В конце алгоритма buffer превращается в строку (эффективно).
-
ОК. Тогда более конкретно:
Я люблю писать всякие алгоритмы над строками в следующем стиле:
1. завожу переменную buffer
[...]
В Lua я не знаю как такое провернуть (эффективно).
Начальный размер буферу я задать не могу. При добавлении символа буфер будет копироваться....
Просто buffer - должен быть не строкой, а массивом или еще чем (в жабе/шарпе есть специальные классы). В конце алгоритма buffer превращается в строку (эффективно).
Да нифига он там не эффективно превращается :-) У них же нет там семантики перемещения (в отличае от плюсов), так что там идет радостное копировние, насколько я помню.
-
Array... да не совсем, т.к. есть дополнительный синтаксис для строк (присваивания, конкатенация...)
массив для которого перегружены операторы. Сейчас в Активном Обероне и для обычных массивов можно задать свою реализацию операторов, как ранее для пользовательских типов.
-
2 valexey
Массив символов это да. Собсна в Обероне так и есть, и даже без преобразований.
Но тогда возвращаемся к вопросу о нужности строк вообще :)
-
Да нифига он там не эффективно превращается :-) У них же нет там семантики перемещения (в отличае от плюсов), так что там идет радостное копировние, насколько я помню.
Копирование - это и есть эффективно (по сравнению с пересозданием строки на изменение каждого элемента ;) Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).
-
Array... да не совсем, т.к. есть дополнительный синтаксис для строк (присваивания, конкатенация...)
массив для которого перегружены операторы. Сейчас в Активном Обероне и для обычных массивов можно задать свою реализацию операторов, как ранее для пользовательских типов.
А как перегрузка операторов мне поможет если я хочу так:
s: ARRAY 255 OF CHAR;
s := "ваполрваоплрваопл";
или так:
s:= s + "sdfds";
?
-
Да нифига он там не эффективно превращается :-) У них же нет там семантики перемещения (в отличае от плюсов), так что там идет радостное копировние, насколько я помню.
Копирование - это и есть эффективно (по сравнению с пересозданием строки на изменение каждого элемента ;) Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).
Не может :-) Ибо как ты себе это представляешь?
-
Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).
Не может :-) Ибо как ты себе это представляешь?
Ну в смысле - если буфер реализован через массив и строка реализована через массив, то рантайм конструирует строку на основе массива из буфера. При этом буфер, естественно, теряет ссылку на свой массив.
-
Ну в смысле - если буфер реализован через массив и строка реализована через массив, то рантайм конструирует строку на основе массива из буфера. При этом буфер, естественно, теряет ссылку на свой массив.
Хотя это все микрооптимизации. Банальное копирование скорее всего будет дешево по сравнению с алгоритмом заполнения буфера.
-
Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).
Не может :-) Ибо как ты себе это представляешь?
Ну в смысле - если буфер реализован через массив и строка реализована через массив, то рантайм конструирует строку на основе массива из буфера. При этом буфер, естественно, теряет ссылку на свой массив.
В результате получаем ошибку времени исполнения при попытке обратиться к этому буферу после того как? Нафиг-нафиг.
-
...Либо размещение буфера в памяти заново ;)
-
В результате получаем ошибку времени исполнения при попытке обратиться к этому буферу после того как? Нафиг-нафиг.
Во-первых язык/компилятор может контролировать "необращение" к буферу. Во-вторых, буфер может пересоздать себе массив. И в-третьих, да, таки можно ругаться в рантайме. Ибо нефиг. Не вижу в этом чего-то совершено страшного - разовый отлов бага, чтобы больше так не делать (трудно представить, что такой буфер буду сознательно шарить и доставть строку больше одного раза).
P.S. Лично я в языке "общего назначения" - копировал бы и не парился.
-
Тык вот нахрена спрашивается вся эта свистопляска? Если достаточно чутку подкрутить синтаксис для ARRAY OF CHAR?
Прикол в том, что в CP у меня не возникает вопросов по поводу компиляции моего кода (работающего со строками).
А вот в других языках видимо нужно долго курить документацию, чтобы хоть примерно представлять как твой код будет выглядеть в машинных кодах.
-
P.S. Лично я в языке "общего назначения" - копировал бы и не парился.
Учитывая http://oberspace.dyndns.org/index.php/topic,196.msg3996.html#msg3996
возможно что и нет ничего страшного в копировании :)
Осталось победить свой перфекционизм :D
-
Несколько неожиданно, что после создания string-объекта символы, входящие в строку, нельзя изменять. Сначала это кажется серьезным ограничением. Однако это не так. Над этим объектом можно выполнять все типы строковых операций. Для того чтобы изменить версию существующей строки, нужно создать новый объект типа string, который содержит необходимую модификацию. Исходная строка остается неизменной. Этот подход используется, потому что фиксированные, неизменяемые строки можно реализовать более эффективно, чем изменяемые. Для тех случаев, когда желательна изменяемая строка, существует компаньон класса string с именем stringBuffer, чьи объекты содержат строки, которые могут изменяться после их создания.
:o
http://www.ppgrefinish.ru/?page_id=16
-
Несколько неожиданно, что после создания string-объекта символы, входящие в строку, нельзя изменять. Сначала это кажется серьезным ограничением. Однако это не так. Над этим объектом можно выполнять все типы строковых операций. Для того чтобы изменить версию существующей строки, нужно создать новый объект типа string, который содержит необходимую модификацию. Исходная строка остается неизменной. Этот подход используется, потому что фиксированные, неизменяемые строки можно реализовать более эффективно, чем изменяемые. Для тех случаев, когда желательна изменяемая строка, существует компаньон класса string с именем stringBuffer, чьи объекты содержат строки, которые могут изменяться после их создания.
:o
http://www.ppgrefinish.ru/?page_id=16
В топике запахло жабой :-)
-
Чем плохи изменяемые строки?
Неправильная постановка вопроса.
Правильно: Чем плохи изменяемые объекты?
-
Правильно: Чем плохи изменяемые объекты?
Теперь в топике запахло хаскелем :-)
-
В x86 есть машинные инструкции для работы с последовательностями, в частности со строками. Чтобы компилятор их использовал на самодельной строке он должен быть слишком умным. Гораздо легче зашить строки в язык, чтобы компилятор о них знал изначально. Это одна из причин почему операции со строками зашивают в язык.
Заманчивая идея реализации строк на буфере фиксированного размера (256?) разрушается при столкновении с реальностью. Если буфер взять слишком маленьким, то некоторые строки в него не уберутся, а если большим, то будет слишком большой перерасход памяти когда придётся иметь десятки миллионов строк одновременно.
То есть, в общем случае, строки должны быть доступны по указателю (или по индексу в массиве). Но длину таких строк нельзя менять. Какой смысл разрешать модификацию букв таких строк если длину нельзя менять? Даже если разрешить менять буквы не меняя длины, то в многопоточной программе это будет тормознее чем создать новую строку ибо лочить придётся при изменении каждой буквы. Опять же вопрос лочить что? Одно дело лочить только лишь одну эту строку, другое дело лочить весь строковый менеджер памяти, который используется для её аллокации. Наивно думать, что быстрее лочить одну лишь строку, так как внутри менеджера памяти при удалении строки придётся лочить и его самого и строку (два лока вместо одного). Так что нафиг-нафиг эта мутабельность.
Когда я писал свою UnmanagedString то специально сделал её неизменяемой по этим соображениям (жёсткая экономия памяти, свой аллокатор памяти, быстрая потокобезопасность).
-
(два лока вместо одного)
Акцент на то, что второй лок надо делать не выходя из первого лока.
Просто два последовательных независимых лока не страшно.
-
В x86 есть машинные инструкции для работы с последовательностями, в частности со строками. Чтобы компилятор их использовал на самодельной строке он должен быть слишком умным. Гораздо легче зашить строки в язык, чтобы компилятор о них знал изначально. Это одна из причин почему операции со строками зашивают в язык.
Какие именно?
То есть, в общем случае, строки должны быть доступны по указателю (или по индексу в массиве). Но длину таких строк нельзя менять. Какой смысл разрешать модификацию букв таких строк если длину нельзя менять? Даже если разрешить менять буквы не меняя длины, то в многопоточной программе это будет тормознее чем создать новую строку ибо лочить придётся при изменении каждой буквы. Опять же вопрос лочить что? Одно дело лочить только лишь одну эту строку, другое дело лочить весь строковый менеджер памяти, который используется для её аллокации. Наивно думать, что быстрее лочить одну лишь строку, так как внутри менеджера памяти при удалении строки придётся лочить и его самого и строку (два лока вместо одного). Так что нафиг-нафиг эта мутабельность.
Когда я писал свою UnmanagedString то специально сделал её неизменяемой по этим соображениям (жёсткая экономия памяти, свой аллокатор памяти, быстрая потокобезопасность).
Наивно думать, что все вышеперечисленное специфично для строк.
-
В x86 есть машинные инструкции для работы с последовательностями, в частности со строками.
Какие именно?
Очевидно, что имеются в виду цепочечные (String) команды: MOVS, INS и др.
-
В x86 есть машинные инструкции для работы с последовательностями, в частности со строками.
Какие именно?
Очевидно, что имеются в виду цепочечные (String) команды: MOVS, INS и др.
Это вот это? http://www.club155.ru/x86cmd/MOVS
Не вижу с этой инструкции особого профита (ну разве что машкодов получается чуть меньше) - один фиг копирование идет побайтово/пословесно. Тем более что там не указано сколько тактов процессора эта инструкция занимает.
Смысла в этой инструкции нет вовсе относительно скажем векторизации (AltVec, Ion инструкции и так далее. Всякий разный SIMD).
-
Это вот это? http://www.club155.ru/x86cmd/MOVS
Не вижу с этой инструкции особого профита (ну разве что машкодов получается чуть меньше) - один фиг копирование идет побайтово/пословесно. Тем более что там не указано сколько тактов процессора эта инструкция занимает.
Да, это оно. Не берусь защищать эти команды. Я вообще-то сторонник RISC. :)
-
Строки, неизменяемость и персистентность (http://blogs.msdn.com/b/ruericlippert/archive/2011/08/08/strings-immutability-and-persistence.aspx)