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

E>>А как у System.String с Shift-JIT, например?
S>А что с ней не так?
А рзве она в Юникод укладывается?

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


C>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.
E>Ты не поймёшь.
Ну если Вы поняли, то любой поймет.
E>Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...
Посмотрю когда СString станет immutable.

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

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


CC>>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
CC>>Интрузивный счетчик в буфере строки.
C>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.
Ты точно на С или С++ писал? Или как работать с памятью и указателями уже забыл?
На пальцах: на хипе вместо массива под строку аллоцируется структура переменной длины:

struct StringBuffer
{
 int m_refCounter;
 int m_stringLength;
 char m_stringBody[]; // отсюда собственно тело строки и начинается
};

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

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

C>>>Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.
CC>>Не, ну это уже оголтелый фанатизм, иначе уже и не назовешь.

C>Ну покажите мне хоть один современный язык, где ситуация со строками хуже или такая же плохая, как в С++.
Ты до сих пор не доказал что она плохая.
В С++ можно заимплементить какие угодно строки.
То, что в STL есть какая то обобщенная реализация строки имеет отношение к библиотеке STL а не к языку С++.
Благо STL в компилер не встроен, тьфу тьфу тьфу.

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

S>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка.
Это конечно очень утешает, особенно если ты разрабатываешь программы, которые продаются реально WW...


S>В строках С++ сделано сразу несколько принципиальных ошибок:
S>0. Они не immutable.
Ну и что? Зачем это вообще надо? Для того, чтобы удобно было switch по строкам писать? Это же редкая очень нужда! На кой нужно обеспечивать уникальность каждой из строк? Ну нужно тебе в каких-то алгоритмах, ну пользуйся такими строками в тех местах, хотя, IMHO, логичнее было бы сделать какую-то в обобщённом смысле аддитивную хэш-функцию и хранить хфши кусков строки, а не искать те же строки среди всех существующих в памяти...

S>1. Они слишком сильно сосредоточены на бинарном представлении.
Да ладно тебе. Чем это std::basic_string<wchar_t> -- не цепочка юнкодов?
Просто весь STL "слишком сосредоточен на подробностях реализации", и при этом ещё умудряется почти ничего из их не гарантировать Ну да это вопросы к авторам и приверженцам STL, а не к кому-то или чему-то ещё...
Есть куча менее кудрявых библиотек та же QT, например...

S>Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.
Тема того, что перечисленные обстоятельства -- недостатки не нраскрыта. А вот то, что в std::basic_string можно хранить не только юникод -- это, IMHO, РЕАЛЬНЫЙ ПЛЮС...

Здравствуйте, criosray, Вы писали:
C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).
Нет. Более того, в последних версиях даже принудительный вызов Intern() не приводит к желаемым результатам.

Здравствуйте, CreatorCray, Вы писали:
CC>Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?
Нет, не будут. По очевидным причинам: заниматься ерундой типа проверки уникальности при каждой операции получения строки — тратить перформанс непонятно на что.

Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.

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


C>>>>Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.
CC>>>Не, ну это уже оголтелый фанатизм, иначе уже и не назовешь.

C>>Ну покажите мне хоть один современный язык, где ситуация со строками хуже или такая же плохая, как в С++.
CC>Ты до сих пор не доказал что она плохая.
CC>В С++ можно заимплементить какие угодно строки.
CC>То, что в STL есть какая то обобщенная реализация строки имеет отношение к библиотеке STL а не к языку С++.
CC>Благо STL в компилер не встроен, тьфу тьфу тьфу.

Так и есть — в С++ зоопарк глючных, несовместимых реализаций строк. А в исходниках каша из std::wstring, CWSTRPTR (spelling), CString, QString, wchar и десятков аллиасов.

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

S>Здравствуйте, criosray, Вы писали:
C>>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).
S>Нет. Более того, в последних версиях даже принудительный вызов Intern() не приводит к желаемым результатам.

Принято.
Но
var a = "str";
var b = "str";

Точно ref equal.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Если это так, то время появления нового объекта (строки) должно зависеть от количества существующих объектов (строк) в программе.
А если это не так (что скорее всего) то тогда получается что уже в качестве ключей их использовать упс... И память они уже не экономят...

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

C>>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.
E>>Ты не поймёшь.
C>Ну если Вы поняли, то любой поймет.
Ну ты ж вот никак не можешь понять

E>>Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...
C>Посмотрю когда СString станет immutable.
Мне что, написать для тебя immutable СString чтоб ты наконец понял как это делаетcя?
Ты ж вроде как программист — сам соображать должен. Что такое COW тоже вроде знаешь. А раз про shared_ptr приплел то явно тебя только этот момент смущал.

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

C>>>>http://research.microsoft.com/en-us/projects/contracts/
C>>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?
ГВ>>Прикольный постинг по этому поводу: API Design Myth: Interface as Contract

C>А никто и не утверждал, что интерфейс является полным контрактом класса.

Цитату из твоего постинга тебе уже тут не раз привели, так что, повторяться не буду. Значит, ты настолько неудачно сформулировал свою мысль, что читатели тебя с лёгкостью поняли не правильно. Что, в общем, не удивительно, фразу: "интерфейс это чисто контракт" можно понять и так и эдак — и что интерфейс является частью контракта, и что интерфейс эквивалентен контракту, и даже так, что контракт является частью интерфейса. Этим же грешат и другие твои постинги.

C>Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе точно так же как и code сontracts в конкретной реализации интерфейса — в классе, описывают пред- и пост- условия в методе или еще более специфичные соглашения, как тут вчера приводили о порядке вызовов методов, т.п. — это тоже контракты КЛАССА. У классов естественно может быть целое множество контрактов, которое в совокупности составляет полный контракт этого класса.

В общем, согласен. Хотя и здесь у тебя не обошлось без путаницы: "множество интерфейсов и каждый из них является контрактом сам по себе". Интерфейс не является контрактом — такой оборот не больше, чем эвфемизм.

C>Вы же пытаетесь смешивать теплое с мягким, грубейше нарушая принцип single responsibility, когда добавляете КОД в интерфейс. О чем Вам, кстати, и господин WolfHound твердил.

Это снова зависит от определений терминов.

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

C>>>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.
E>>>Ты не поймёшь.
C>>Ну если Вы поняли, то любой поймет.
CC>Ну ты ж вот никак не можешь понять
Что я не могу понять?

E>>>Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...
C>>Посмотрю когда СString станет immutable.
CC>Мне что, написать для тебя immutable СString чтоб ты наконец понял как это делаетcя?
Я не сомневаюсь, что можно, но между можно и есть очень большая разница.

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

C>var a = "str";
C>var b = "str";

C>Точно ref equal.
Принято.

Кстати еще интересно, это не на этапе компиляции случайно происходит?

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

CC>>Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?
S>Нет, не будут. По очевидным причинам: заниматься ерундой типа проверки уникальности при каждой операции получения строки — тратить перформанс непонятно на что.
В общем то так и ожидалось.

S>Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.
Ну наконец то спокойный ответ с полезной ссылкой без фанатских причитаний.
Thx, полез читать.

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

C>Так и есть — в С++ зоопарк глючных, несовместимых реализаций строк. А в исходниках каша из std::wstring, CWSTRPTR (spelling), CString, QString, wchar и десятков аллиасов.
Это скорее проблемы человеческой неорганизованности нежели языка.
Почему то такие проблемы есть далеко не у всех.

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

S>Здравствуйте, Игoрь, Вы писали:
S>>>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>>Например, и почему эти алгоритмы нельзя сделать эффективно на С++?
S>Например потому, что придется делать по две версии алгоритмов — на случай передачи в них константной строки, и неконстантной строки.

Есть очень большая вероятность того, что писать две версии не придется, т.к. алгоритмам (внешним) все равно с какими типами итераторов работать, а внутренние (находящихся в std::basic_string) просто представляют собой вызовы обобщенных.

А вот, например, эффективную конкатенацию строк можно сделать (и сделано в одной из реализаций) с помощью expression templates, но к иммутабельности это не особо относится. Если копнуть глубже — в стандарте нет явного (хотя есть пару дефектов по этому поводу) требования хранить строки одним непрерывным куском.

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

S>Здравствуйте, Игoрь, Вы писали:
S>>>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>>Например, и почему эти алгоритмы нельзя сделать эффективно на С++?
S>Например потому, что придется делать по две версии алгоритмов — на случай передачи в них константной строки, и неконстантной строки.
Опять начинается путаница. Если мы говорим в пониманиии константности С++, то это неверно. Алгоритм требующий константности объекта, априори будет работать и для неконстантного объекта, просто из-за того, что константность более жесткое ограничение.
С другой стороны, если мы в понятие константности строки включаем еще и фиксированное размещение ее в памяти или в каком-то сторадже. Ну да, там можно использовать какие-то оптимизации в виде хэш == адрес. Но таких алгоритмов раз два и обчелся, а кроме того ведь в таком подходе C# есть и недостатки. Например, если идет относительно активная работа с текстом, включая его изменения, то почему я должен на каждый чих создавать копию строки? Опять эффективность, но уже в другую сторону.

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

C>На МакОСи, например, не пишут почти на С++. У них есть Objective-C, которого как оказывается тоже на многое хватает.

Ага-ага. И что, офис или БД какая там на Objective-C? Или ядро OS может на Objective-C?
На Objective-C там морда вроде...

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

S>Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.
Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.