Здравствуйте, Erop, Вы писали:
E>Тем не менее в С++ именно так и делают...
Пример в студию.

E>Единственная проблема -- это разделяемая между нитями константная строка, которую иногда таки меняют...
Да, совершенно верно. Что такое "константная строка"???
Вот я отдал в другой тред указатель на строку. Ну, то есть понятно, что выполнять полное копирование — слишком дорого. Если у этого указателя семантика реф-типа, то необходимо обеспечить механизмы блокировки. Чтобы два треда не поменяли содержимое строки. В иммутабл строках никаких блокировок не нужно — если указатель указывал на Hello World, то он всегда будет указывать на Hello World.

E>Но такие же проблемы вызывают любые другие данные. Например, разделяемое между нитями число...
Нет, не такие же. Обычный способ передачи чисел "по значению" — это копирование. Для строк его точная эмуляция приведет к просаду производительности.
Передача "по ссылке" бывает значительно реже. И с ней, естественно, будут ассоциированы аналогичные проблемы.
E>Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..
Тем, что числа не нужно модифицировать. Они настолько дёшевы, что можно просто выбросить предыдущее значение и заменить его новым.

Здравствуйте, Erop, Вы писали:
E>Ну и как будет, например 0x8790?
U+2252?

Здравствуйте, gandjustas, Вы писали:

Чтобы не дробить обсуждение, я сразу на оба отвечу...

E>>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.
E>>Тем более, что никаких принципиальных трудностей на этом пути нет...
G>Есть, причем офигеть какие.
G>1)Совместимость. Даже если сделать immutable-строки, все равно во многих местах понадобится передавать char*. Если этот char* отдавать из внутреннего буфера, то попа ибо от иммутабельности ничего не останется. Если копировать, то перфоманс просядет заничтельно.
Зачем куда-то передавать сhar*, и как C# этого удаётся избежать? Если речь идёт об API, то там обычно входные строки именно const char*... Просто иногда С-шные хедеры декларируют функции без const, но это не является содержательной проблемой. Можно, например, написать к нужному API обёртки...

G>2)Управление памятью. Если выполнить a = b + c для строк, то кто будет освобождать b и с? Повесить все это на shared_ptr — тормоза начнутся похлеще .net_овсих
Почему? Можно же не в shared_ptr всё засунуть, а в аналог imtrusive_ptr...

G>Где такую траву берешь? Какие у чисел возожности по модификации себя? Ты разыве можешь написать 1.setBit(4)?
1 -- это литерал. Литералы иммутабельны по своей семантике. Строковые литералы тоже иммутабельны. Скажем "мама".clear() ты тоже написать не можешь. А если число не литерал, а неконстантная переменная, то ты можешь написать так:

int i = 1;
i |= ( 1 << 4 );

G>В том то и дело что в большинстве программ строкам нужна семантика значений, как у чисел. Только в малом проценте нужна семантика массива.
В STL std:vector требует семантику значения (это как у чисел) от своих элементов, и сам, в свою очередь, имеет такую семантику. Так, например, возможен вектор векторов.

E>>...Если да, то почему это не так в большинстве языков, во всяком случае?
G>Не недо показвать свою безграмотность. В некоторых языках...
Ну если под безграмотностью ты понимаешь неумение читать, то да, не надо.
Кста, в С++ нет проблем задавать строку в виде списка. Мало того, stl::basic_string не обязана хранить строку в массиве... Просто таких реализаций stl нет, я думаю потому, что они не нужны...

G>...строки ассоциируются не с массивами, а с immutable списками. Ты же смотришь на строки только как на массивы байт.
Да нет, я вообще не вижу разницы между списком и массивом. Если тебе список букв милее, пусть будет список. Любой контейнер для хранения ПОСЛЕДОВАТЕЛЬНОСТИ элементов годится. Мы же о семантике говорим вроде, а не о чём-то ещё? Какая тогда разница, как именно это реализовано?

Итак, нужно ли требовать иммутабельности от любой последовательности букв? Если да, то почему не требуют? Если нет, то чем строка так отличается от последовательности букв?

S>Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.
Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ... А что, смогли что ли?
Кста, по поводу того, что про сценарии со строками мы знаем намного больше чем про сценариями с последовательностями букв -- хотелось бы поконкретнее этот тезис чтобы был развёрнут! А то как-то не понятно что мы такое знаем про строки, чего про последовательности букв не знаем... ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?

E>>Если нет, то в чём принципиальная разница между массивом букв и строкой?
G>Огромная разница.
S>от этого есть реальная польза. И во фреймворках, разработанных после С++, такое разделение уже существует пятнадцать лет.

Как-то вы ребята исключительно неконкретны...
Если gandjustas хотя бы попробовал привести пару доводов от чего иммутабельную строку якобы нельзя создать на С++, то второй собеседник ограничивается исключительно декларациями и отсылками к весьма бессмысленным, IMHO, документам.
Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?

Вы можете таки ответить конкретно:
Преимущества такие: раз, два, три.
Отличие по семантике от последовательности букв (списка, массива, верёвки, очереди и т. д.) состоит в том-то и том-то, из чего следует нужда в иммутабельности.
Отличие по сеантике значения от чисел такие: раз, два, три...

Здравствуйте, Sinclair, Вы писали:

E>>Тем не менее в С++ именно так и делают...
S>Пример в студию.
Пример чего? Какого-нибудь алгоритма принимающего на вход константную строку? Ну поиск подстроки в строке, например...

S>Да, совершенно верно. Что такое "константная строка"???
Ну строка константная, константная строка... В С++ данные можно объявлять константными. Я думаю, что ты в курсе этого факта...

S>Вот я отдал в другой тред указатель на строку. Ну, то есть понятно, что выполнять полное копирование — слишком дорого. Если у этого указателя семантика реф-типа, то необходимо обеспечить механизмы блокировки. Чтобы два треда не поменяли содержимое строки. В иммутабл строках никаких блокировок не нужно — если указатель указывал на Hello World, то он всегда будет указывать на Hello World.

Что мешает публиковать уже константный указатель?..

E>>Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..
S>Тем, что числа не нужно модифицировать. Они настолько дёшевы, что можно просто выбросить предыдущее значение и заменить его новым.

Ну то есть выражения вида a |= 16 не нужны, и даже вредны?

Кста, ты тут много раз заметил, что авторы шарпа не смогли родить мутабельную строку, которая могла бы быть эффективным значением... IMHO, разделение на два класса происходит именно оттуда...

Здравствуйте, Sinclair, Вы писали:

S>U+2252?
а разве такой есть? Это вроде как самодеятельность MS?

Здравствуйте, Erop, Вы писали:
E>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать?
В C# char* запрещён.
E>Если речь идёт об API, то там обычно входные строки именно const char*... Просто иногда С-шные хедеры декларируют функции без const, но это не является содержательной проблемой. Можно, например, написать к нужному API обёртки...
Речь идет о реальных библиотеках и реальном API. Эти гигабайты кода никто не будет оборачивать и переписывать.

E>1 -- это литерал. Литералы иммутабельны по своей семантике. Строковые литералы тоже иммутабельны. Скажем "мама".clear() ты тоже написать не можешь.
Правильно. А почему можно сделать std::string("мама").clear()?
E>А если число не литерал, а неконстантная переменная, то ты можешь написать так:

int i = 1;
E>i |= ( 1 << 4 );

Прекрасно. Вопрос: куда делась "1"? Ты не изменил число. Ты заменил его другим. У тебя есть заранее созданные четыре миллиарда целых чисел; то, чем ты пользуешься — это номера этих заранее созданных объектов.
операция 1 << 4 ничего не делает ни с четвёркой, ни с единицей. Она возвращает номер того числа, которое является результатом операции <<.
И в конце, когда ты производишь присваивание в i, ты просто заменяешь номер числа 1 на номер числа 17.
Давай посмотрим на такой же пример со строками:

var i = "hello";
i += " world";

Здесь фигурируют три строки. Сначала i указывала на строку "hello", потом была создана новая строка (путем конкатенации двух строк), и i стала указывать на эту новую строку. Сама строка "hello" (байты, на которые указывала i вначале) никак не поменялась. Это и есть семантика value-типа: значение измениться никак не может.

E>В STL std:vector требует семантику значения (это как у чисел) от своих элементов, и сам, в свою очередь, имеет такую семантику. Так, например, возможен вектор векторов.
Ты, по-видимому, не понимаешь, что такое "семантика значения".

E>Кста, в С++ нет проблем задавать строку в виде списка. Мало того, stl::basic_string не обязана хранить строку в массиве... Просто таких реализаций stl нет, я думаю потому, что они не нужны...
Это замечательный подход. Он гарантирует тебе, что ничего полезного ты никогда не изучишь. Ты только послушай себя: "раз в С++ нет, значит не надо". Ок, хорошо. Зачем тогда весь этот ритуальный танец вокруг нового стандарта? Ведь если лямбд не было в stl, то они гарантированно не нужны.

E>Да нет, я вообще не вижу разницы между списком и массивом. Если тебе список букв милее, пусть будет список. Любой контейнер для хранения ПОСЛЕДОВАТЕЛЬНОСТИ элементов годится. Мы же о семантике говорим вроде, а не о чём-то ещё? Какая тогда разница, как именно это реализовано?
E>Итак, нужно ли требовать иммутабельности от любой последовательности букв? Если да, то почему не требуют? Если нет, то чем строка так отличается от последовательности букв?
Не от любой. Есть последовательность букв, которая ведет себя как value — от неё можно и нужно требовать иммутабельности. Если я поместил Иванова на букву И в телефонной книге, пусть он будет любезен оставаться Ивановым.
Контракт такой строки вполне известен: от нее можно вычислить хеш, который гарантированно будет совпадать для одинаковых строк (и всегда будет соответствовать содержимому строки); строки можно конкатенировать; можно порождать подстроку.
Но главное в контракте этой строки — гарантия иммутабельности. То что результат произвольной F(s) будет оставаться ровно таким же, до тех пор, пока мы не переприсвоим в s что-то еще.

E>Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ...
Ок. Это примерно как я бы наезжал на C++ "не смогли эффективно реализовать работу с данными, не разделяя их на строки и числа". Мутабельная и иммутабельная строка — разные контракты.

E>Кста, по поводу того, что про сценарии со строками мы знаем намного больше чем про сценариями с последовательностями букв -- хотелось бы поконкретнее этот тезис чтобы был развёрнут! А то как-то не понятно что мы такое знаем про строки, чего про последовательности букв не знаем...
Мы знаем, что строкам не нужно изменение по месту. Что если я сконструировал объект WebRequest(string url), то он может и будет полагаться на неизменность переданного адреса вплоть до вызова GetResponse().

E>ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?
Что такое "иммутабельная последовательность букв"?

E>Как-то вы ребята исключительно неконкретны...
E>Если gandjustas хотя бы попробовал привести пару доводов от чего иммутабельную строку якобы нельзя создать на С++, то второй собеседник ограничивается исключительно декларациями и отсылками к весьма бессмысленным, IMHO, документам.
Ок. Эти документы окажутся осмысленными, когда у читателя вырастет нужный опыт — я думаю, что это связано не с количеством извилин, а исключительно с кругозором.

E>Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?
Юноша, stl — это часть стандарта С++. До него вообще никаких строк в С++ не было. В MFC строки — вообще кошмар проектировщика. Я уже писал в этом форуме другим упёртым фанатам — например, на тему втискивания внутрь строки всех сервисных методов, которые должны быть снаружи. В QT тут, как вроде только что писали, строки иммутабельны. Врут?
Да, мутабельных чисел нет нигде. Учите матчасть — это value типы. И думайте головой.
Собственно, основной подвиг дотнета по отношению к строкам — то, что разработчики сделали так, чтобы строки вели себя как числа.

Здравствуйте, Erop, Вы писали:

E>Пример чего? Какого-нибудь алгоритма принимающего на вход константную строку? Ну поиск подстроки в строке, например...
Ну, покажи мне этот алгоритм, его декларацию, и способ, которым он сделан потокобезопасным.

E>Ну строка константная, константная строка... В С++ данные можно объявлять константными. Я думаю, что ты в курсе этого факта...
Я понимаю. Я не понимаю, каким образом кто-то собрался менять константную строку.

E>Что мешает публиковать уже константный указатель?..
Публиковать я могу всё, что угодно. Как потребовать, чтобы мне отдавали константу?

E>Кста, ты тут много раз заметил, что авторы шарпа не смогли родить мутабельную строку, которая могла бы быть эффективным значением...
Значение иммутабельно по определению.

E>IMHO, разделение на два класса происходит именно оттуда...
Разделение на два класса происходит из глубокого понимания окружающей действительности. Равно как и, к примеру, отделение кодировки от строки.

Здравствуйте, Erop, Вы писали:

E>а разве такой есть? Это вроде как самодеятельность MS?
http://www.fileformat.info/info/unicode/char/2252/index.htm

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, gandjustas, Вы писали:

E>Чтобы не дробить обсуждение, я сразу на оба отвечу...

E>>>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.
E>>>Тем более, что никаких принципиальных трудностей на этом пути нет...
G>>Есть, причем офигеть какие.
G>>1)Совместимость. Даже если сделать immutable-строки, все равно во многих местах понадобится передавать char*. Если этот char* отдавать из внутреннего буфера, то попа ибо от иммутабельности ничего не останется. Если копировать, то перфоманс просядет заничтельно.
E>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать? Если речь идёт об API, то там обычно входные строки именно const char*... Просто иногда С-шные хедеры декларируют функции без const, но это не является содержательной проблемой.
.NET это обходит на уровне рантайма и передачай StringBiilder в том случае когда переданная строка меняется.

E>Можно, например, написать к нужному API обёртки...
Ну можно и .NET написать, только дорого это выйдет.

G>>2)Управление памятью. Если выполнить a = b + c для строк, то кто будет освобождать b и с? Повесить все это на shared_ptr — тормоза начнутся похлеще .net_овсих
E>Почему? Можно же не в shared_ptr всё засунуть, а в аналог imtrusive_ptr...
А разница небольшая. В любом случае надо как-то обеспечивать автоматическое освобождение, которое в C++ стоит дороже, чем в .NET. А если учесть что и выделение памяти под строки будет дороже, чем в .NET, то смысла в создании такого нету.

G>>Где такую траву берешь? Какие у чисел возожности по модификации себя? Ты разыве можешь написать 1.setBit(4)?
E>1 -- это литерал. Литералы иммутабельны по своей семантике. Строковые литералы тоже иммутабельны. Скажем "мама".clear() ты тоже написать не можешь. А если число не литерал, а неконстантная переменная, то ты можешь написать так:

int i = 1;
E>i |= ( 1 << 4 );

Ты сам понял что присваивание написал?
Ни одной операции, меняющей переменную i на месте написать ты не сможешь.

G>>В том то и дело что в большинстве программ строкам нужна семантика значений, как у чисел. Только в малом проценте нужна семантика массива.
E>В STL std:vector требует семантику значения (это как у чисел) от своих элементов, и сам, в свою очередь, имеет такую семантику. Так, например, возможен вектор векторов.
То что он требует это его личное дело.
Ведь мало кто передает векторы по значению, обычно передают по ссылке.

E>>>...Если да, то почему это не так в большинстве языков, во всяком случае?
G>>Не недо показвать свою безграмотность. В некоторых языках...
E>Ну если под безграмотностью ты понимаешь неумение читать, то да, не надо.
E>Кста, в С++ нет проблем задавать строку в виде списка. Мало того, stl::basic_string не обязана хранить строку в массиве... Просто таких реализаций stl нет, я думаю потому, что они не нужны...

Потому что в C++ они неэффективны\небезопасны

G>>...строки ассоциируются не с массивами, а с immutable списками. Ты же смотришь на строки только как на массивы байт.
E>Да нет, я вообще не вижу разницы между списком и массивом. Если тебе список букв милее, пусть будет список. Любой контейнер для хранения ПОСЛЕДОВАТЕЛЬНОСТИ элементов годится. Мы же о семантике говорим вроде, а не о чём-то ещё? Какая тогда разница, как именно это реализовано?
Ну правильно. Семантика такова что с массивом символов приходится очень редко иметь дело.

E>Итак, нужно ли требовать иммутабельности от любой последовательности букв? Если да, то почему не требуют? Если нет, то чем строка так отличается от последовательности букв?
Семантикой. См выше.

S>>Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.
E>Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ... А что, смогли что ли?
Еще раз повторяю.
От строк редко требуется семантика массива символов. При другой семантике реализация через изменяемый массив неэффективна.


E>Кста, по поводу того, что про сценарии со строками мы знаем намного больше чем про сценариями с последовательностями букв -- хотелось бы поконкретнее этот тезис чтобы был развёрнут! А то как-то не понятно что мы такое знаем про строки, чего про последовательности букв не знаем... ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?
Сам понял что сказал?

E>>>Если нет, то в чём принципиальная разница между массивом букв и строкой?
G>>Огромная разница.
S>>от этого есть реальная польза. И во фреймворках, разработанных после С++, такое разделение уже существует пятнадцать лет.

E>Как-то вы ребята исключительно неконкретны...
E>Если gandjustas хотя бы попробовал привести пару доводов от чего иммутабельную строку якобы нельзя создать на С++, то второй собеседник ограничивается исключительно декларациями и отсылками к весьма бессмысленным, IMHO, документам.
E>Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?
Да, особенно пример с числами приведи, когда выражение с числом меняет само число, а не создает новое.
Чтобы было прмерно так: int i; i someOp param; и число i после этого изменилось.


E>Вы можете таки ответить конкретно:
E>Преимущества такие: раз, два, три.
E>Отличие по семантике от последовательности букв (списка, массива, верёвки, очереди и т. д.) состоит в том-то и том-то, из чего следует нужда в иммутабельности.
E>Отличие по сеантике значения от чисел такие: раз, два, три...
Неизменяемая семантика строк позволяет передавать строку куда угодно (в том числе и в другие потоки) и не беспокоиться о том что её может кто-то поменять.
Причем это не "дохленький" const в C++, а реальные гарантии, которые позволяют более оптимально строки использовать.
Например при выделении подстроки не копировать, а создавать строку с со сдвинутыми указателями на внутренний буфер.
Также immutable семантика позволяет быстро сравнивать сроки, так как хеш строки можно закеширвать, а используя что-то вроде Intern Pool можно вообще ограничиться ссылочным сравнением.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Игoрь, Вы писали:

И>>Можно чуть короче, явно не делать проверку на NULL:

И>>

И>>int* p = NULL;
И>>int a = 1, c = 10;

И>>int b = (p? *p : c) / 100;
И>>

C>То есть ради такой єлементарщины надо вводить доп. переменную?
Так это для наглядности. На самом деле вместо указателя можно изпользовать address-of operator — & для конкретной переменной. Просто такой код не имееет смысла в С++, поскольку адресс переменной не бывает нулевой. Я вообще-то склонен согласиться с Игорем что кода вида

int* n = null

вполне достаточно , а бустовые затыки типа nullable нужны для решения проблем с использованием умных указателей( которые могут принимать нулевое значение) в контейнерах. Я бы в таких случаях вместо затык порекомендовал бы пересмотреть дизайн.
Давайте посмотрим на nullable с другой точки зрения, я думаю что nullable в С# это как вы говорите, "костыль", из-за того что в C# нет типа указатель на что-то, а в плюсах есть (даже со своей адресной арифметикой), следовательно в плюсах nullable не особенно нужен. Обойдемся как нибудь проверкой указателя на null.

Здравствуйте, Sinclair, Вы писали:

.

E>>IMHO, разделение на два класса происходит именно оттуда...
S>Разделение на два класса происходит из глубокого понимания окружающей действительности. Равно как и, к примеру, отделение кодировки от строки.
Только вот к сожалению, окружающая среда про это ничего не знает Иногда в программе бывает очень полезно удобно и самое главное — эффективно использовать разные типы строк (wstring, string, bstr — разные и т.п, в том числе и самописные строки) именноо из-за разнообразия окружающей среды.

Здравствуйте, alexey_ma, Вы писали:
_>Только вот к сожалению, окружающая среда про это ничего не знает Иногда в программе бывает очень полезно удобно и самое главное — эффективно использовать разные типы строк (wstring, string, bstr — разные и т.п, в том числе и самописные строки) именноо из-за разнообразия окружающей среды.
Все эти типы строк, которые кажутся вам разными, отличаются в незначительных аспектах представления. Поведение строк сводится всего к двум контрактам, для которых в дотнете и предусмотрены разные типы.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)
WH>Надо.

Меня не интересуют вообще маргинальные направления. Если есть язык/средство/инструмент/и т.д, которое хотя бы 10% рынка имеет — велкам, будем обсуждать. Если же это пусть сколь угодно интересная поделка, реально не применяющаяся, обсуждай не со мной.

PD>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).
PD>>ПО с серьезными расчетами.
WH>Ничему из этого нативность не нужна.
WH>Вообще не нужна.
WH>Тут дело лишь в качестве оптимизатора и ни в чем больше.

Тут дело в том, что в настоящее время эти программы пишутся в основном на нативном коде. Я не хочу заново начинать дискусию, почему это так и может ли это когда-нибудь быть иначе. Может, в светлом будущем, когда память будет терабайтовой , а оптимизация в управляемой среде дойдет до недосягаемых вершин, это и будет иначе. А пока что факт есть факт — такое ПО пишут либо на С++, либо вообще на С.

Здравствуйте, Sinclair, Вы писали:

S>сделать мало-мальски полезные иммутабельные строки в плюсах не получится.
А можно как нибудь подтвердить реальными фактами это утверждение?
Или "мало-мальски полезные иммутабельные строки" это 1:1 как в шарпе и никак иначе?

Здравствуйте, Sinclair, Вы писали:

S>Да, совершенно верно. Что такое "константная строка"???
S>Вот я отдал в другой тред указатель на строку. Ну, то есть понятно, что выполнять полное копирование — слишком дорого. Если у этого указателя семантика реф-типа, то необходимо обеспечить механизмы блокировки. Чтобы два треда не поменяли содержимое строки.
Так отдавай туда const char * — и ежу понятно что менять сие без хака низя.

А если авторы кода, куда ты передаешь строку, внутрях снимают константность, то тебе в этом случае вообще никакие иммутабельные строки не помогут. Если уж тут сняли константность то в случае иммутабельной строки — полезут напрямую в память и поменяют буфер "иммутабельной" строки.
Это С++!!! (СПАРТААААА!!!!)
Это не C# — тут суровые бородатые викинги с топорами.

S> В иммутабл строках никаких блокировок не нужно — если указатель указывал на Hello World, то он всегда будет указывать на Hello World.
Если есть в руках индуса указатели — тебя ничего не спасёт.
В шарпе отобрали возможность делать что угодно с любой областью памяти — поэтому там можно надеяться на "гарантии иммутабельности". Впрочем все равно можно дёрнуть native код и поковыряться указателем в памяти. И тогда все надежды гарантии пойдут лесом, как и в С++ случае.
Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому.

Здравствуйте, gandjustas, Вы писали:

G>>>До SQL Server дойдет нескоро.

До Office, BackOffice, IIS,... тоже нескоро

G>>>Другие вендоры вряд ли решаться выкинуть существующий codebase.

G>Преимущества заметны при разработке с нуля. Старые проекты переписывать невыгодно, независимо от того на что переписывать.

Вот с этим хочу поспорить.

Переписывание переписыванию рознь. Зависит о того, что с помощью этого переписывания можно получить.

Мозилла/Netscape в свое время полностью переписала свой броузер и mail клиент. Модифицируя и модифицируя свой старый Netscape Navigator от 2.0 к 4.x, она довела его до полной невменяемости, выбросила наконец и переписала заново. Многие оценили этот шаг как самоубийственный, но теперь-то всем ясно, что это было правильное решение.

Если есть серьезные причины для переписывания — перепишут, будьте спокойны. Как в свое время переписали программы с DOS на Win16, а потом с Win16 на Win32. Необходимость и того и другого была совершенно очевидна, а выгоды от такого переписывания тоже достаточно ясны. Проще сказать, надо было. И сделали.

И если Win64 пойдет всерьез — перепишут под Win64. Но не все, а только то, для чего профит от такого переписывания будет. Остальным жить под WOW64.

А переписывать на .Net — не надо. Потому что никакого серьезного профита от этого не получится. Поэтому и не переписывают.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, alexey_ma, Вы писали:
_>>Только вот к сожалению, окружающая среда про это ничего не знает Иногда в программе бывает очень полезно удобно и самое главное — эффективно использовать разные типы строк (wstring, string, bstr — разные и т.п, в том числе и самописные строки) именноо из-за разнообразия окружающей среды.
S>Все эти типы строк, которые кажутся вам разными, отличаются в незначительных аспектах представления. Поведение строк сводится всего к двум контрактам, для которых в дотнете и предусмотрены разные типы.
Вон оказывается оно как Только причем здесь окружающая среда? Замечательно если вы сами можете определять контракты и аспекты представления, ну а если Вам нужно взаимодествовать с какой-то legacy аппликацией написанной 20 лет назад и использующей свой собственный извращенный стринг, что делать то? Впрочем спорить не буду, возможно в 95% процентах случаев дотнетовский стринг вполне удобен, используйте и радуйтесь. Меня же радует в С++ многообразие стрингов из разных библиотек и возможность выбора наиболее подходящего и эффективного для каждого конкретного случая.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Erop, Вы писали:
E>>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать?
S>В C# char* запрещён.

Хм. А в MSDN я вот такое увидел

fixed (char* p = str) ... // equivalent to p = &str[0]

Мне вообще-то как-то больно узнать, что он запрещен. Дело в том, что в моей программе на C# используется правда не char*, а sbyte* сплошь и рядом. Как мне иначе-то делать, если программа — интерфейс к неуправляемой DLL, написанной на презренном C++, которая только и знает экспортировать всякие char*, и char** ( в смысле C/C++, то есть однобайтовые).

Здравствуйте, WolfHound, Вы писали:

И>>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.
WH>Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.

А до них Sun в Java тоже не освоила, так ? Не осваивается оно...

a> Вон оказывается оно как Только причем здесь окружающая среда? Замечательно если вы сами можете определять контракты и аспекты представления, ну а если Вам нужно взаимодествовать с какой-то legacy аппликацией написанной 20 лет назад и использующей свой собственный извращенный стринг, что делать то? Впрочем спорить не буду, возможно в 95% процентах случаев дотнетовский стринг вполне удобен, используйте и радуйтесь. Меня же радует в С++ многообразие стрингов из разных библиотек и возможность выбора наиболее подходящего и эффективного для каждого конкретного случая.

Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом