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

C>>А примеры? Как такой крутой перец и гуру не наваял нам с десяток красивых примеров.
WH>Исходники буста почитай... Там вся "красота" С++ в полный рост.
Там в полный рост зоопарк компиляторов.
Это можно записать в недостатки С++ как платформы, но не С++ как языка.

C>>И вот тут я хочу остановиться на книге "Exceptional C++" в двух томах, где описывается как молодой девелопер может сделать криво, а как после прочтения это можно сделать шедеврально.
WH> Молодой "девелопер" может сделать только криво. Тем более на С++. Тем более после того как начитается.
+1

WH>В прочем жаба сама по себе один сплошной обрубок.
+1

C>>Тогда решили сделать множественное наследование, и разрешить наследовать от одного класса, и одного и более недо-класса, который не мог бы вызвать испражнения из кучерявых пальцев говнокодеров, те никаких имплементаций, которые могут вызвать двоиственность сущностей, только описание метода, или словами микрософта — Pure Virtual Function.
WH>Интерфейс это чистый контракт.
WH>Тем он собственно и хорош.
WH>Ибо SRP никто не отменял. А нарушать такие вещи в дизайне языка это совсем не хорошо.
Имхо, это совершенно некритично, и никто не мешает к этому чистому контракту привернуть пару невиртуальных функций — это никак на чистоте контракта не скажется, так как то, что было чисто виртуальным, им и останется.

WH>Так вот билдер сдох по тому что во первых был жутко глючный. Просто не реальное количество багов везде.
+1. Мертворожденное дитя.

WH>Нормальным людям нужно решать задачу, а не контролы в каждом новом проекте выпиливать.
+1. Но это спор не о языках, а о библиотеках.

WH>Вот это макросы.
WH>А то что в С++ это полное угрЁбище.
+1. Макросы Немерле было бы очень здорово поиметь в плюсах. Много проблем бы сразу ушло. А древний примитивный сишный препроцессор (тут С++ ничего не добавил) — это, безусловно, полный привет.
Единственное его достоинство — простота реализации, но программерам от этого ни холодно, ни жарко, им нужен нормальный мощный и гибкий инструмент.

WH>Ява просто не правильный язык.
WH>C# объективно лучше. Но тоже не фонтан.
+1

You will always get what you always got
  If you always do  what you always did

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

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

C>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
CC>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
Посмотрите QString из QT, вроде неплохо работает, да еще и cross-platform . А "дикий оверхед", обычно появляется в результате неумелого и непродуманного использования библиотечных классов как в С++ так в С#.

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

C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:

C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>Надеюсь в этот раз я вас не запутал и привёл нормальные доводы.
Проблемы с логикой. Из того, что интерфейс — не более чем контракт, никак не следует, что и контракт — не более чем интерфейс.

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


C>>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
CC>>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
_>Посмотрите QString из QT, вроде неплохо работает, да еще и cross-platform . А "дикий оверхед", обычно появляется в результате неумелого и непродуманного использования библиотечных классов как в С++ так в С#.
Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?

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

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

И>>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:
И>>

И>>const std::string &str = string(src);
И>>

И>>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.
S>Не стоит мерить дотнет мерками C++.
S>String и StringBuilder имеют принципиально разное поведение, которое не сводится к запрету вызова неконстантных мемберов. В частности, у них разная трактовка идентичности.
S>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
Например, и почему эти алгоритмы нельзя сделать эффективно на С++?

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

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

C>>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
CC>>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
CC>>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
C>>Конечно никакой — ведь std::string не могут использовать общий буффер, как это делается в дотнет.
CC>Какая в этом выгода?
CC>Не, ну если у тебя в проге есть куча одинаковых строк, раскиданных по всему коду то да, на спичках сэкономить можно.
CC>А так смысла особого не видно.
Вот и пришли наконец от "В С++ нет оверхеда!!!11111" (с) уж и не помню кто из местных "гуру" к "зачем экономить на спичках".
CC>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?
Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).

C>>Вот так они будут ссылаться на один и тот же буфер. Тем самым будет использовано всего 6 байт под буфер вместо 12, как это было бы в С++
CC>В С++ для кода:
CC>

CC>const char* str = "abc";
CC>const char* str2 = "abc";
CC>

CC>в случае включения опции Enable string pooling тоже будет str == str2
Потому что это константы.

CC>А вообще, как-то тут давно пробегала мессага, в которой кто-то сорвал покровы почему в шарпе строки сделаны через стрингбилдер. Там была какая то техническая причина, вроде как связанная с особенностями аллокации в .NET. Не упомню уже.
Что значит "строки сделаны через стрингбилдер"? Что это еще за чушь? StringBuilder это чисто вспомогательный класс, позволяющий очень быстро перемалывать списки символов. Зачем он нужен понятно всякому, кто понимает что значит immutable природа типа string. К тому же, как я уже упоминал специфика использования StringBuilder такова, что оверхед по памяти для него абсолютно не релевантен, что позволяет оптимизировать его максимум на скорость выполнения операций вставки/удаления/поиска и т.д.

Будет время напишу синтетический тест с молотилками больших объемов текста средствами std::string и StringBuilder для сравнения.

CC>Кроме того, сталкивался с реализацией STL в которых basic_string сделан через COW с подсчетом ссылок.

C>> (впрочем, std::string даже не юникодный, так что там было бы 3+3).
CC>Базовой реализации строк в STL на это вообще пофигу — хоть UTF32 на них реализуй.

И что у Вас std::string UTF32? Что за STL у Вас такой можно поинтересоваться?

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

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

Забудь вообще про shared_ptr — он кривой изначально.

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

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

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

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

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

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

Ну покажите мне хоть один современный язык, где ситуация со строками хуже или такая же плохая, как в С++.

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


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

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

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


C>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?
Я полагаю что вы хотели получить пример этого :

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

В QT это есть( и не только для строк кстати).

Many C++ classes in Qt use implicit data sharing to maximize resource usage and minimize copying. Implicitly shared classes are both safe and efficient when passed as arguments, because only a pointer to the data is passed around, and the data is copied only if and when a function writes to it, i.e., copy-on-write.

здесь

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

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

C>>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?
_>Я полагаю что вы хотели получить пример этого :
_>

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

_>В QT это есть( и не только для строк кстати).
Понятно. Спасибо.

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

CC>>Какая в этом выгода?
CC>>Не, ну если у тебя в проге есть куча одинаковых строк, раскиданных по всему коду то да, на спичках сэкономить можно.
CC>>А так смысла особого не видно.
C>Вот и пришли наконец от "В С++ нет оверхеда!!!11111" (с) уж и не помню кто из местных "гуру" к "зачем экономить на спичках".
Угу. Именно нет оверхеда, да.
Потому как у меня нет одной единственной реализации строки, объявленной самой кошерной.
Там где мне надо иметь кучку константных строк с которыми у меня идут частые сравнения на равенство — у меня отдельный класс строки, который ровно под это заточен.
Остальные же строки в программе у меня на 99% различны — нет никакого смысла для них городить огород.
И я "не плачу" за то, что мне не нужно.

CC>>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?
C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).
И как оно это делает?

C>Будет время напишу синтетический тест с молотилками больших объемов текста средствами std::string и StringBuilder для сравнения.
И потом как тут было с ганжустасовым тестом аллокации его порвет наколенный шаблон MySimpleString?

CC>>Кроме того, сталкивался с реализацией STL в которых basic_string сделан через COW с подсчетом ссылок.

C>>> (впрочем, std::string даже не юникодный, так что там было бы 3+3).
CC>>Базовой реализации строк в STL на это вообще пофигу — хоть UTF32 на них реализуй.

C>И что у Вас std::string UTF32? Что за STL у Вас такой можно поинтересоваться?
Например typedef std::basic_string<DWORD, char_traits<DWORD>, allocator<DWORD>> UTF32string;
на *никс системах по-дефолту wchar_t вообще 32битный. Там даже wstring UTF32 потянет.

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

C>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?
Это у тебя они все immutable. А реальный мир прекрасно живет и с mutable и c immutable строками.

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

CC>>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?
C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).

а как оно узнаёт, что строки таки одинаковые? Зависит ли эффективность этого поиска от того, сколько строк одновременно хранится в программе или в системе?

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

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

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

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

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

C>Ну покажите мне хоть один современный язык, где ситуация со строками хуже или такая же плохая, как в С++.

FORTRAN 99 -- это современный?